主题
LlamaParse MCP 服务端把你这套部署的文档处理能力，作为任意兼容 MCP 的智能体都能调用的工具暴露出来。自托管部署运行自己的那份，因此文档与 API key 都留在你的网络内 —— 智能体连接你的 MCP 服务端，而它通过集群内部网络与你的 LlamaCloud 后端通信。
启用服务端
values.yaml
config:
mcp:
enabled: trueMCP 服务端由它自己的仓库发布，因此版本不跟随 chart。chart 已经替你钉好了一个已发布的 tag，通常无需设置。如果你把镜像同步到了自己的镜像仓库，或者要用比 chart 所钉更新的 MCP 版本，就覆盖它 —— 写在顶层的 mcp 键下，而不是 config.mcp：
mcp:
image: your-registry.example/llamacloud-mcp:<tag>Pod 报 ImagePullBackOff 几乎总是这个原因：集群连不上默认镜像仓库，而这里又没设置你自己同步过来的 tag。
默认情况下，服务端调用的是 LlamaCloud 后端在集群内的地址，因此它要访问 API 无需任何配置。只有在你需要它调用别的端点时才设 config.mcp.llamaCloudBaseUrl；那里若填公网地址，必须使用 https。
给它一个域名
MCP 需要属于自己的域名 —— 它在 Web 界面已经在用的路径上应答，因此无法共用主域名。把一个第二级的 DNS 名指向同一个 ingress，并把它设为公网 URL：
ingress:
enabled: true
host: cloud.your-company.example
tlsSecretName: llamacloud-tls
ingressClassName: nginx
config:
mcp:
enabled: true
publicUrl: https://mcp.your-company.examplechart 会添加一条 ingress 规则，把该域名转发到 MCP 服务。有两件事它没法替你做：
mcp.your-company.example必须与cloud.your-company.example解析到同一个 ingress。llamacloud-tls必须覆盖两个名字。一张证书同时服务两者，因此它需要为每个名字准备使用者备用名称，或者用通配符证书。
MCP 规则与 Web 界面共用同一个 Ingress 对象，所以 ingress.annotations 里的一切对它同样生效 —— 反过来也是。像 parseFile 这样的工具调用会把一个 HTTP 请求从头到尾为一个任务保持打开，而不是先返回一个任务 id，因此 ingress 控制器常规的 60 秒读超时会在任务仍在跑、credit 也照旧消耗的情况下把一次长的 Parse 掐断。所以当 chart 把 MCP 路由到它自己的域名时，它同时会在 Ingress 上设置 nginx.ingress.kubernetes.io/proxy-read-timeout: "600"。如果你的文档耗时更久，请把它调高：
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"在 ingress.annotations 里设置该键永远优先，包括显式设成 "" 以便在不读取该注解的控制器上去掉默认值。而且必须是 ingress.annotations —— commonAnnotations 会被默认值覆盖而不是压过它。
如果你自行路由 MCP，chart 什么都不设，那么请在你添加的规则上配上等价的超时。这是最容易撞上 60 秒掐断的一种配置，因为不会有任何告警。别假定你为界面设的 rewrite 或鉴权注解适合 MCP —— 用之前重读一遍。
publicUrl 要写成含协议的完整 URL，且不带路径 —— 客户端会自己追加（/mcp、/parse/mcp 等）。凡是由它推导路由的地方，缺协议的取值都会在渲染阶段被拒绝，而不是安静地生不出路由。一旦设置好，Web 界面就会开始提供现成的 MCP 客户端配置，因为它终于知道了一个你的用户所指智能体能够访问的 URL。
该规则由 publicUrl 推导而来，所以 chart 会为任何与 ingress.host 不同的 publicUrl 域名做路由。有两种形态不会触发它：publicUrl 就落在 ingress.host 上（这种 chart 从不路由，因为 MCP 应答的路径归 Web 界面所有），以及 ingress.enabled: false（此时根本不渲染 Ingress）。两种情况下，你路由过来的流量都要转发到 llamacloud-mcp 服务的 80 端口。
目前做不到的是：保留 chart 的 Ingress 启用、把 MCP 宣告在自己的域名上、同时又自行路由该域名 —— chart 会为它加上自己的规则，而两个 Ingress 争夺同一个域名时的生效顺序你无法控制。
身份认证
自托管的 MCP 服务端用 LlamaCloud 的 API key 做认证，由用户以 bearer token 的形式传入：
{
"mcpServers": {
"llamaparse": {
"url": "https://mcp.your-company.example/mcp",
"headers": { "Authorization": "Bearer ${LLAMA_CLOUD_API_KEY}" }
}
}
}因此有一个工具的行为不同。getUploadUrl 会返回一个用于上传本地文件的预签名 URL，而它对 API key 调用方不可用 —— 那会给任何访问到该 URL 的人留下一个长期有效的凭据。智能体应当改调 uploadFileByUrl，传一个服务端能够访问的 URL。其余工具行为不变。
文档托管在你的内网里
uploadFileByUrl 默认拒绝私有与链路本地地址，这能防止调用者借服务端去访问它不该访问的东西。如果你的用户提交的文档确实就在内网主机上，请显式放行：
config:
mcp:
allowPrivateUploadHosts: true只有当你确实能接受调用方指名内部地址时再开启它 —— 默认值防的正是这件事。
确认它在正常工作
终端窗口
kubectl -n <your-namespace> get ingress
kubectl -n <your-namespace> get pods -l app.kubernetes.io/name=llamacloud-mcp然后确认服务端在你配置的域名上可达：
终端窗口
curl -sS https://mcp.your-company.example/api/healthzPod 起来了、端点有响应，并不能证明客户端能用它 —— 要接一个智能体并真的调用一次工具。MCP 文档 覆盖了客户端配置与完整工具清单，把其中的 mcp.llamaindex.ai 换成你自己的域名，就同样适用于你的部署。