Smartsheet 构建远程 MCP Server 的案例，重点不只是“让模型调用几个工具”，而是如何把 MCP 服务纳入成熟的云基础设施：身份认证、权限治理、弹性扩缩、持续部署，以及面向 AI 工作负载的专门优化。远程 MCP 一旦连接企业数据和写操作，就应当按生产 API，而不是按实验性提示词组件来设计。
远程 MCP 的核心是受控的数据通路
一个典型的 AWS 部署可以把流量链路拆成几层：客户端通过 HTTPS 连接入口，入口完成 TLS、限流和基础防护；容器服务运行 MCP Server；服务再凭受限身份访问业务 API、数据库或消息系统。
可以这样实践一套参考架构。以下是通用设计示意，不代表 Smartsheet 的具体资源配置：
MCP Client / AI Agent
|
| HTTPS + OAuth access token
v
CloudFront or Application Load Balancer
|
+---- AWS WAF: rate limits and request filtering
|
v
ECS Fargate: remote MCP server
|
+---- Secrets Manager: downstream credentials
+---- CloudWatch: logs, metrics and alarms
+---- X-Ray / OpenTelemetry: request traces
|
v
Business APIs and governed data services
入口认证和工具授权需要分开处理。一个合法用户能够连接 MCP Server，并不意味着他可以调用全部工具。服务应把用户身份、租户、OAuth scope 和资源权限带到每一次工具调用中，避免用服务器的高权限角色替用户完成所有操作。
对于写入、删除或批量导出之类的高风险工具，还应增加明确的审批或确认机制。至少记录以下审计字段：
- 调用者和租户标识
- 工具名称及版本
- 经过脱敏的参数摘要
- 下游资源标识
- 执行结果、耗时和错误类型
- MCP 请求与下游请求的关联 ID
不要把访问令牌、完整提示词或敏感业务数据直接写入日志。结构化日志和字段级脱敏应当在应用层完成，而不是依赖运维人员事后清理。
扩缩容不能只盯着 CPU
远程 MCP Server 面对的是突发、并发且耗时差异很大的工具调用。只使用 CPU 利用率扩容，可能无法及时反映下游 API 等待、长连接数量或任务积压。
更有价值的指标包括：
- 活跃 MCP 会话数和并发工具调用数
- 每个工具的 P50、P95、P99 延迟
- 429、超时和下游依赖错误率
- 每个任务的内存与连接占用
- 请求队列深度或正在执行的异步任务数
如果服务运行在 ECS Fargate，可以先用 CPU 建立基础扩缩策略，再逐步接入 CloudWatch 自定义指标。下面的命令可直接改造使用。运行前需要替换集群名、服务名，并确认 AWS CLI 已登录目标账户：
#!/usr/bin/env bash
set -euo pipefail
CLUSTER="mcp-prod"
SERVICE="remote-mcp-server"
RESOURCE_ID="service/${CLUSTER}/${SERVICE}"
aws application-autoscaling register-scalable-target \
--service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id "${RESOURCE_ID}" \
--min-capacity 2 \
--max-capacity 20
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id "${RESOURCE_ID}" \
--policy-name mcp-cpu-target \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": 55.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ECSServiceAverageCPUUtilization"
},
"ScaleOutCooldown": 30,
"ScaleInCooldown": 180
}'
生产环境通常保留至少两个任务，并分布在不同可用区。扩容要快，缩容则应更谨慎，避免终止仍在处理工具调用或维持流式响应的任务。应用还需要捕获终止信号、停止接收新请求，并在宽限期内完成已有请求。
部署治理要覆盖工具本身
MCP Server 的变化不仅是代码变化。工具名称、输入模式、权限要求和返回结构都会影响 Agent 的决策，因此工具定义本身也应被版本化和测试。
一条稳妥的发布链路可以包含：
- 对工具 schema 做静态校验和兼容性检查。
- 使用固定输入运行契约测试，验证授权、超时与错误映射。
- 构建不可变容器镜像，并生成软件物料清单。
- 在隔离环境执行真实下游依赖的集成测试。
- 通过蓝绿或金丝雀发布逐步引流。
- 根据错误率、工具延迟和异常调用量自动回滚。
IAM 权限也应跟随代码审查。任务角色只获取运行时所需权限，部署角色负责更新服务，两者不要混用。不同环境使用独立的密钥和资源边界，避免测试 Agent 误触生产数据。
AI 工作负载需要额外的成本与可靠性控制
传统 API 往往返回面向人或程序的完整对象，但 MCP 工具结果最终会进入模型上下文。返回字段越多，令牌成本、延迟以及敏感信息暴露面就越大。
可以这样实践结果裁剪：允许调用者请求字段和分页大小，同时在服务端设置硬上限。对于大型列表，返回摘要、游标和稳定资源 ID，而不是一次塞入全部记录。工具错误也应转成简短、可行动的结构化结果，避免把下游堆栈或 HTML 错误页送给模型。
{
"items": [
{"id": "row-1042", "name": "Q3 plan", "status": "blocked"}
],
"next_cursor": "eyJvZmZzZXQiOjI1fQ==",
"truncated": true
}
还需要考虑 Agent 的自动重试行为。读取操作可以通过幂等设计和短期缓存降低压力；写操作应接受幂等键，防止模型、SDK 或网关重试造成重复提交。遇到下游限流时，应返回明确的可重试状态并采用带抖动的指数退避，同时设置每个租户和每个工具的并发上限。
上线前检查清单
远程 MCP 的价值来自开放工具能力，它的风险也来自同一件事。落地时可以沿着下面的顺序收紧边界：
- 认证用户，同时在每个工具调用中重新执行资源授权。
- 使用最小权限任务角色，并把密钥放入 Secrets Manager。
- 为危险工具增加确认、审批或默认只读模式。
- 对 schema、权限和错误行为建立契约测试。
- 同时监控基础设施指标和工具级指标。
- 验证断连、超时、限流、重试和优雅终止行为。
- 对结果做分页、裁剪和脱敏，控制令牌成本。
- 从小流量金丝雀开始，保留快速回滚能力。
Smartsheet 的案例说明，远程 MCP Server 已经进入标准云工程需要解决的范围。真正决定系统能否长期运行的，不是工具数量，而是身份能否贯穿链路、权限是否可审计、流量是否可控，以及模型触发异常行为时系统能否把影响限制在清晰的边界内。