
Nutanix Prism Central
io.github.wyre-technology由 GitHub 账号 wyre-technology 发布v1.0.0更新于 Oct 24, 2026
Multitenant Streamable HTTP bridge over Nutanix's official v4 API MCP server (Prism Central).
概览
多租户 HTTP 桥接服务,将 Nutanix 官方 Prism Central v4 API MCP 服务器重新以 HTTP 提供,并按请求头转发各租户的 Nutanix 凭据。
- 可以做什么
- 通过 Streamable HTTP 暴露上游 Prism Central 工具面,tools/list 与 tools/call 转发到各租户的子会话
- 调用 20 个 Nutanix 命名空间的 execute 工具(aiops、clustermgmt、networking、storage、vmm、volumes 等)
- 使用发现类工具列出操作、获取操作 schema、生成代码示例或查询操作权限
- 按凭据组合惰性启动并复用上游 stdio 子进程,空闲超时后回收
- 提供健康检查端点,并同时支持旧版握手与新版信封式 MCP 客户端
- 适用场景
- 适用于运行多租户网关、需要按每次请求传入调用方 Prism Central 凭据来使用 Nutanix 只读 v4 API 工具的场景,而不是为每个用户单独跑一个单租户 stdio 进程。
- 运行要求
- 以本地容器或 Node.js 进程运行,同时需要固定版本的上游 nutanix-mcp 代码、其 Python 虚拟环境以及预构建的 API 规范产物。启动必须提供真实的 CONDUIT_S2S_SECRET;每个 /mcp 请求需带 X-Gateway-S2S 签名,以及 X-Nutanix-Pc-Host 和 X-Nutanix-Pc-Api-Key,或 X-Nutanix-Pc-Username 与 X-Nutanix-Pc-Password。只有执行类调用才需要访问 Prism Central 的网络。
安装
在 SourceWeft 中
- 打开 控制台中的 Nutanix Prism Central,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
nutanix-mcp
Multitenant Streamable HTTP bridge over nutanix/ntnx-api-mcp-server — Nutanix's official Prism Central v4 API MCP server — built so the WYRE conduit gateway can forward per-tenant Nutanix credentials as HTTP headers.
Upstream pin: Nutanix's server is a technical preview, pinned here at tag
v0.8(Apache-2.0). See Bumping the upstream pin.
Why
The upstream server is stdio-only (nutanix-mcp serve-stdio is its only serve mode) and reads its Prism Central credentials from environment variables at process startup — single-tenant per process. Our gateway is multi-tenant: every request carries the calling org's credentials as HTTP headers, and the vendor container has to translate those headers into something the upstream understands.
Because the upstream has no HTTP mode to proxy to, this bridge holds an MCP client session over stdio to each tenant child and re-serves it over Streamable HTTP:
- Listens on
:8080withPOST /mcpandGET /health. Startup requires a realCONDUIT_S2S_SECRET. Every/mcprequest must carry a validX-Gateway-S2Ssignature of that secret. - 401-gates every
/mcprequest on theX-Nutanix-Pc-*credential headers (below). Those headers are the only Prism Central credential source. - Lazily spawns one
nutanix-mcp serve-stdiochild per credential tuple (keyed by a hash), with the tenant'sPC_*env vars set, and connects an MCP client to it over stdio. - Serves both protocol eras on
/mcpvia the v2 SDK'screateMcpHandler(factory, { legacy: 'stateless' })— 2025-erainitialize-handshake clients (the conduit gateway today) and modern 2026-07-28 envelope clients.tools/listandtools/calldelegate to the tenant's child session. - Evicts idle children after 60 minutes (
IDLE_EVICT_MS).
Tool names pass through unchanged: the upstream's 24 tools — 20 {namespace}_execute tools (aiops, clustermgmt, datapolicies, dataprotection, files, iam, licensing, lifecycle, microseg, monitoring, multidomain, networking, objects, opsmgmt, prism, security, storage, tenancy, vmm, volumes) plus 4 discovery tools (listOperations, getOperationSchema, getCodeSample, getOperationPermissions).
Read-only in v1 — deliberate
Every child is spawned with READ_ONLY_MODE=true (also the upstream default): the upstream rejects all non-GET operations before they ever reach Prism Central. v1 of this bridge ships read-only as a deliberate fleet decision. Write support would be a reviewed, versioned change to credentialsToChildEnv() in src/credentials.ts — not a config flip.
Credential contract
The gateway forwards these headers on every /mcp request; the bridge maps them onto the upstream child's environment. conduit's vendor-config must match this table exactly.
Validity rule: pcHost present AND (apiKey present OR username+password present). Anything else → HTTP 401 with a JSON-RPC error body.
READ_ONLY_MODE=true is additionally forced on every child (see above).
API-spec artifacts (baked at build time)
The upstream builds its tool surface from YAML API-spec artifacts, not from the live PC. nutanix-mcp init downloads them — and without PC credentials it runs in latest_release mode against the public developers.nutanix.com namespace API (no PC access required; verified empirically: 20 namespaces). The Docker build runs init once and bakes the artifacts into the image at /opt/nutanix-mcp/artifacts, shared read-only by all tenant children. Consequences:
tools/listand the discovery tools work with no reachable PC — only{namespace}_executecalls touch Prism Central.- Artifact versions are the latest public release at image build time, not the tenant PC's exact versions (the upstream's
pc_compatiblemode would need live PC access at spawn). For the read-only v1 surface this is the right trade: shared artifacts, fast tenant spawns.
Configuration
Copy .env.example. Leave CONDUIT_S2S_SECRET empty in that file and set a real value only in the environment you run.
/health and /healthz stay unauthenticated and do not read credentials.
HTTP authentication
With CONDUIT_S2S_SECRET set, every /mcp request must include X-Gateway-S2S. The check is verifyS2sHeader in src/s2s-verify.ts: the header value is t=<unix seconds>,v1=<hex>, where the hex is HMAC-SHA256 of the literal string t=<unix seconds> keyed with CONDUIT_S2S_SECRET (64 lowercase hex characters). The timestamp must be within 300 seconds of the server clock. A missing or invalid header is HTTP 401, before Prism Central credentials are read.
Sign with the same CONDUIT_S2S_SECRET the server process is using. Local development exports that value in the shell; reuse it for this request instead of generating another one.
This bridge is gateway mode. /mcp also requires X-Nutanix-Pc-Host and either X-Nutanix-Pc-Api-Key or both X-Nutanix-Pc-Username and X-Nutanix-Pc-Password. Those headers are the only credential source for that request. PC_* values in the process environment are not used as a fallback.
Local development
Or build the image (it bakes everything, including a stdio smoke test that fails the build if serve-stdio can't answer tools/list). The image listens on 0.0.0.0 inside the container and still refuses to start without a real CONDUIT_S2S_SECRET. Publish the port on loopback. Prism Central credentials arrive on each request as X-Nutanix-Pc-* headers.
Compose refuses to start when CONDUIT_S2S_SECRET is unset. The gateway service publishes 127.0.0.1:8080:8080 and does not inject PC_HOST, PC_USERNAME, PC_PASSWORD, PC_API_KEY, or env_file. Use the exported secret so a later signing request matches the container:
Bumping the upstream pin
The upstream is pinned to the reviewed tag v0.8 in the Dockerfile (NUTANIX_MCP_REF) — never main (NSA MCP guidance / fleet security baseline). To bump:
- Review the upstream diff between the current pin and the new tag (tool surface, credential handling,
READ_ONLY_MODEsemantics). - Change
NUTANIX_MCP_REFin theDockerfileand the tag in this README. docker buildlocally — the build-time smoke tests assert the venv entrypoint runs and the stdio tool surface still answers (update the expected tool count if namespaces changed).- Land as a
feat:/fix:PR so semantic-release cuts a version.
License
Apache-2.0. The bundled ntnx-api-mcp-server is Apache-2.0 by Nutanix.
来源:README.md,提交 8a2e40d
工具
0版本历史
1- v1.0.0最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分