Smartsheet 如何在 AWS 上构建远程 MCP 服务器

Smartsheet 是一个企业工作管理平台，数十万组织依赖它。随着企业团队采用 AI 代理，这些代理需要结构化访问 Smartsheet 等系统内部的数据，但大多数系统并非为此设计。为了弥补这一差距，Smartsheet 在 AWS 上构建了远程模型上下文协议（MCP）服务器，让 AI 客户端可以直接访问其数据和功能。Amazon Quick 和 Claude Desktop 等 AI 助手帮助用户通过自然语言使用 Smartsheet 的功能，包括分析项目数据、更新任务、创建表格、管理工作区等。

企业还在构建无需人工提示即可运行的定制 AI 代理。这些 AI 代理可以在各自角色中自主工作，通过 MCP 在 Smartsheet 中协作。例如捕获需求、领取任务、附加测试结果、起草文档。这些操作发生在人类同事使用的同一张表格里，将原本需要数周的工作流程压缩到几天甚至几小时。

该 MCP 服务器连接到 Smartsheet 现有的 API 和中央智能层，并在上层增加了一个 AI 优化接口，旨在最大限度地降低 token 成本、帮助防止幻觉，并帮助大语言模型（LLM）可靠地处理企业数据。自发布以来，根据内部遥测数据，Smartsheet 通过这些优化节省了超过 30 亿 token。

在本文中，我们将概览 Smartsheet 远程 MCP 架构，重点关注其背后的 AWS 基础设施，包括安全性、治理、扩展与部署，以及 Smartsheet 在 AWS 上构建的 AI 特定优化。

架构

一个 MCP 层同时服务内部和外部代理。Smartsheet 自己的 Smart Assist（产品内 AI 体验）和 Amazon Quick 等外部连接的 AI 客户端运行在同一基础设施上，使用相同的工具、优化和智能栈。这种对等性是有意的架构选择：Smartsheet 只需构建一次，每个代理客户端便能立即受益。

数据路径中架构上关键的 AWS 服务包括：

详细架构流程如下：

1. AI 客户端到 API 网关层再到 MCP 服务器：请求通过 API 网关层（AWS WAF、AWS Shield、AWS 应用负载均衡器及 OAuth 验证）后到达运行在 AWS Fargate 上的 MCP 服务器。
2. MCP 服务器到领域服务：MCP 服务器通过 API 调用 Smartsheet 的领域服务进行事务性操作。
3. MCP 服务器到智能层：MCP 服务器查询构建在 Amazon Neptune 和 Databricks 上的智能层，以获取跨项目的代理洞察。
4. 领域服务到智能层：变更事件通过 Amazon Kinesis 和 Apache Flink 流入由 Amazon S3 支撑的智能层。智能层遵循奖牌架构。

图 1：Smartsheet 在 AWS 上的 MCP 服务器架构

边缘保护、容器注册、可观测性、密钥等支撑服务详见下文相关章节。

部署与扩展

在扩展方面，AI 流量与传统请求模式不同。代理自主编排工具调用序列，在处理任务时一秒钟内发出多个请求，然后在模型推理时静默。这种突发性模式要求伸缩策略既能应对突然的峰值，也能应对持续的吞吐量。

为了处理并验证这种模式，Smartsheet 将 MCP 服务器构建为运行在 AWS Fargate for Amazon ECS 上。ECS 自动扩缩使用目标跟踪策略，结合流量量和计算利用率。计算感知伸缩在此很重要，因为每个请求都涉及服务端处理，例如面向 LLM 优化的序列化，而不仅仅是代理。在与生产环境类似的流量模式下进行的大量负载测试验证了基础设施能够在无性能下降的情况下吸收代理突发流量。

在部署方面，在不中断活跃代理会话的情况下推出更新同样关键。容器镜像存储在 Amazon Elastic Container Registry（Amazon ECR）中，并由持续集成和持续交付（CI/CD）流水线通过分层安全网进行发布。ECS 部署断路器在发布过程中检测失败的容器，并自动回滚到上一个稳定版本。无需手动干预，避免了对客户的影响。

部署首先发布到最小的区域，遵循 AWS Well-Architected 减少影响范围的原理。每个区域发布后，自动化端到端测试会基于生产环境验证工具行为。金丝雀测试每 15 分钟运行一次，通过完整的身份验证和网关路径执行多步骤 MCP 工作流。结果汇入监控栈，从而在客户报告之前暴露性能退化。ECS Fargate 搭配 ALB 的模式记录在 AWS 部署 MCP 服务器指南中。

治理与可观测性

对于企业客户而言，治理是采用 AI 的门控因素。Smartsheet 将其内建在工具框架中：访问控制、错误处理和审计跟踪默认随每个工具提供。

访问按组织分级：管理员可以全局启用 AI 访问、限制为仅非破坏性操作，或开放完全的写入和破坏性功能，让每个组织能够控制自己的采用曲线。工具携带 MCP 协议注解，如 readOnlyHint 和 destructiveHint，以便 AI 客户端自动应用适当的确认流程。

服务器在整个请求生命周期中发出 OpenTelemetry 信号（日志、跟踪和指标）。每次工具调用在隐私约束下捕获尽可能多的上下文：用户、组织、工具名称、结果等。这为使用洞察和合规审计提供了基础。

代理流量比传统 API 流量更难观测。单个用户请求可能产生一连串工具调用，故障往往需要回溯多个步骤。Smartsheet 正在通过代理优先的身份和跟踪扩展其可观测性，在工具链之间关联上下文。日志通过 Amazon Kinesis 流式传输到 Amazon OpenSearch Service，遵循 AWS 可观测性最佳实践模式，基础设施指标通过 Amazon CloudWatch 展示。Datadog 提供每个工具的应用性能监测（APM）可见性，PagerDuty 处理事件路由。

每次调用还通过 Amazon Simple Queue Service（Amazon SQS）发出结构化分析事件到智能层。这形成了反馈闭环：生产使用数据指引优先处理哪些工具，以及优化策略在真实工作负载中的表现。

安全 AI 代理流量

MCP 服务器运行在与 Smartsheet 生产 API 相同的安全基础设施之后。AWS WAF 和 AWS Shield 位于边缘，私有子网位于虚拟私有云（VPC）内，服务间调用使用双向 TLS（mTLS），OAuth2 代理会拒绝未经验证的请求，防止其到达计算层。MCP 服务器遵循 AWS 部署 MCP 服务器指南中的纵深防御模型。API 网关层处理身份验证和权限范围验证。领域服务处理细粒度权限。如果用户通过 UI 无法访问某个表格，那么通过 MCP 也无法访问。

AI 流量带来了独特的速率限制挑战。单个用户问题可能在几秒内触发多个工具调用。许多企业用户位于共享的企业代理之后，使基于 IP 的速率限制不可靠。

为解决这一问题，Smartsheet 通过 AWS WAF 实现了分层速率限制。三层协同工作：外围的全面防护、使用基于身份头的自定义聚合密钥的按用户计量，以及针对昂贵操作的路径特定控制。按用户计量意味着会话单独计量，而不是按 IP 汇集。分层速率限制遵循 三个最重要的 AWS WAF 基于速率的规则模式。

测试非确定性 AI 工作流

Smartsheet 维护着标准的测试层次：单元测试、集成测试、工具级验证。然而，MCP 服务器引入了传统 API 服务不曾面临的测试挑战。传统 API 响应由 UI 确定性地呈现。而 MCP 工具响应首先经过 LLM。模型对其进行解释、推理，并生成用户最终看到的内容。这一层非确定性改变了测试中“正确”的定义。

Smartsheet 大量投资于包含 LLM 的端到端工作流测试。这些测试模拟真实的业务场景：创建工作区、写入数据、查询结果，并验证模型的解释对最终用户是否有意义。这些测试在 CI/CD 流水线（GitLab CI 搭配托管在 AWS 上的运行器）中运行，并作为金丝雀测试持续针对每个生产 AWS 区域执行。

优化 AI 消费

随着企业扩展 AI 代理部署，token 消耗成为真正的成本驱动因素。每个工具响应都会在 LLM 处产生费用，并争夺上下文窗口容量。目前大多数 MCP 工具调用在没有子代理编排的情况下运行。代理直接调用工具，每次一个，在各步骤之间进行推理。如果没有智能工具设计，这很快就会变得缓慢、昂贵且容易出错。每次工具调用都必须自包含且高效，这就是 Smartsheet 在三个层面进行优化的原因：

1. 渐进式披露，限制每次响应的 token 消耗。
2. 强类型的工具模式，有助于防止幻觉参数和浪费的调用。
3. 专有的序列化格式，在数据密集型响应上将 token 数量减少 35–47%。

渐进式披露

每个工具响应都有 token 预算。服务器根据列数和数据密度动态计算可以容纳多少行。例如，一个包含五列的表格比包含十五列的可以返回更多行，但总数保持在预算内。无论表格有 50 行还是 50,000 行，响应大小都保持边界。模型看到足够的信息以进行定位，然后根据用户实际询问的内容通过过滤器缩小范围。

元数据字段准确告知模型发生了什么：is_sampled 表示数据是否被截断，rows_in_sheet 给出完整计数，rows_actual 显示返回了多少行，filters_applied 描述活跃的过滤器。模型利用这些信息判断自己是否拥有完整画面，或者需要利用过滤器缩小查询范围。渐进式披露是服务端的决策。MCP 服务器负责预算和采样，而其返回的元数据为 AI 客户端自行编排后续查询提供信号。

图 2：渐进式披露实战：AI 客户端接收带元数据的采样数据，然后进行有针对性的后续请求

对 LLM 进行根基化至关重要。没有约束，模型会幻觉参数名称、发明操作符，并在失败的调用上浪费 token。每个工具通过 MCP 的工具发现发布严格的 JSON Schema，由 Pydantic 模型生成。参数约束为有效枚举值，列名在执行前与实际表格进行验证，不匹配时返回包含有效选项的结构化错误，而不是静默失败。模式验证在边界处捕获幻觉，并确保代理能够可靠地浏览工具目录，而无需反复试错。

节省 token 的序列化

JSON 的结构开销（大括号、引号、重复的键）通常占响应 token 数的 15–25%。对于返回包含数千行电子表格数据的服务器，开销迅速累积。

Smartsheet 构建了一种专有序列化格式来缓解这一开销。键名只出现一次，而不是每行重复，结构语法被 token 化效率更高的分隔符替代。在一次代表性的 33 项过滤查询中，优化后的响应约 3,900 token，而等效 JSON 约超过 6,000 token，相同的信息少用了约 35% 的 token。在 1,000 行时，差距进一步扩大，因为 JSON 在每个对象上重复键名，而优化后的格式只需声明一次。

Smartsheet 的下一步

AI 代理集成到 S

Smartsheet is an enterprise work management platform that hundreds of thousands of organizations rely on. As enterprise teams adopt AI agents, those agents need structured access to the data inside systems like Smartsheet, but most systems aren’t built for that. To bridge this gap, Smartsheet built a remote Model Context Protocol (MCP) server on AWS that gives AI clients direct access to its data and capabilities. AI assistants like Amazon Quick and Claude Desktop help users interact with Smartsheet’s capabilities through natural language, analyzing project data, updating tasks, creating sheets, managing workspaces, and more.

Enterprises are also building custom AI agents for workloads that run without human prompting. These AI agents can work autonomously in their roles, coordinating through Smartsheet using MCP. A few examples are capturing requirements, picking up tasks, attaching test results, drafting documentation. These happen in the same sheets their human counterparts use, compressing workflows that took weeks into days or hours.

The MCP server connects to Smartsheet’s existing APIs and central intelligence layer. It also adds an AI-optimized interface on top, designed to minimize token cost, help prevent hallucination, and help large language models (LLMs) work reliably with enterprise data. Since launch, Smartsheet saved over 3 billion tokens, based on internal telemetry, through these optimizations.

In this post, we cover a high-level view of the Smartsheet remote MCP architecture, with a focus on the AWS infrastructure behind it. This includes security, governance, scaling and deployment, and the AI-specific optimizations Smartsheet built on AWS.

Architecture

One MCP layer serves both internal and external agents. Smartsheet’s own Smart Assist (the in-product AI experience) and externally connected AI clients like Amazon Quick run on the same infrastructure, with the same tools, optimizations, and intelligence stack. This parity is a deliberate architectural choice: Smartsheet builds once and every agentic client benefits immediately.

The architecturally critical AWS services in the data path are:

The detailed architecture flow is as follows:

1. AI clients to API gateway layer to MCP Server : Requests pass through an API gateway layer (AWS WAF, AWS Shield, AWS Application Load Balancer, and OAuth validation) before reaching the MCP server on AWS Fargate.
2. MCP Server to Domain Services : The MCP server calls Smartsheet’s domain services through their APIs for transactional operations.
3. MCP Server to Intelligence Layer : The MCP server queries the Intelligence Layer built on Amazon Neptune and Databricks for cross-project agentic insights.
4. Domain Services to Intelligence Layer : Change events stream through Amazon Kinesis and Apache Flink into the Amazon S3-backed intelligence layer. The Intelligence Layer follows the medallion architecture.

Figure 1: Smartsheet MCP Server architecture on AWS.

Supporting services such as edge protection, container registry, observability, secrets appear in the relevant sections in the following sections.

Deployment and scaling

On the scaling side, AI traffic differs from conventional request patterns. Agents autonomously orchestrate sequences of tool calls, firing several requests in a second as they work through a task, then going quiet while the model reasons. This bursty pattern demands a scaling strategy that responds to both sudden spikes and sustained throughput.

To handle and validate this pattern, Smartsheet built the MCP server to run on AWS Fargate for Amazon ECS. ECS Auto Scaling uses target-tracking policies, combining traffic volume with compute utilization. Compute-aware scaling matters here because each request involves server-side processing like LLM-optimized serialization, not only proxying. Extensive load testing under production-like traffic patterns validated that the infrastructure absorbs agent bursts without degradation.

On the deployment side, shipping updates without disrupting active agent sessions is equally critical. Container images are stored in Amazon Elastic Container Registry (Amazon ECR) and rolled out by the continuous integration and continuous delivery (CI/CD) pipeline through a layered safety net. ECS deployment circuit breakers detect failing containers during rollout and automatically revert to the last stable version. Manual intervention is not needed, and customer impact is avoided.

Deployments roll out to the smallest region first, following the AWS Well-Architected principle of reducing impact radius. After each region, automated end-to-end tests validate tool behavior against the live environment. Canary tests run every 15 minutes, executing a multi-step MCP workflow through the full authentication and gateway path. Results feed into the monitoring stack so degradation surfaces before customer reports. The ECS Fargate with ALB pattern is documented in the AWS Guidance for Deploying MCP Servers.

Governance and observability

For enterprise customers, governance is the gating factor for AI adoption. Smartsheet built it into the tool framework itself: access control, error handling, and audit trails ship with every tool by default.

Access is tiered per organization: administrators can turn on AI access globally, restrict to non-destructive operations only, or open up full write and destructive capabilities, giving each organization control over their adoption curve. Tools carry MCP protocol annotations like readOnlyHint and destructiveHint so AI clients apply appropriate confirmation flows automatically.

The server emits OpenTelemetry signals (logs, traces, and metrics) across the full request lifecycle. Every tool invocation captures the maximum context possible within privacy constraints: user, organization, tool name, outcome, and more. This provides the foundation for usage insights and compliance auditing.

Agent traffic is harder to observe than traditional API traffic. A single user request can produce a chain of tool calls, and failures often trace back several steps. Smartsheet is extending its observability with agent-first identity and tracing, correlating context across tool chains. Logs stream through Amazon Kinesis into Amazon OpenSearch Service following the AWS Observability Best Practices pattern, with infrastructure metrics surfaced through Amazon CloudWatch. Datadog provides per-tool application performance monitoring (APM) visibility, and PagerDuty handles incident routing.

Every invocation also emits a structured analytics event through Amazon Simple Queue Service (Amazon SQS) into the Intelligence Layer. This closes the feedback loop: production usage data informs which tools to prioritize and how optimization strategies perform across real workloads.

Securing AI agent traffic

The MCP server runs behind the same security infrastructure as Smartsheet’s production APIs. AWS WAF and AWS Shield are at the edge, with private subnets in a virtual private cloud (VPC), mutual TLS (mTLS) for service-to-service calls, and an OAuth2 proxy that rejects unauthenticated requests before they reach compute. The MCP server follows the defense-in-depth model in the AWS Guidance for Deploying MCP Servers. The API gateway layer handles authentication and scope validation. Domain services handle fine-grained permissions. If a user can’t access a sheet through the UI, they can’t access it through MCP either.

AI traffic adds a distinctive rate-limiting challenge. A single user question can trigger several tool calls in seconds. Many enterprise users sit behind shared corporate proxies making IP-based rate limiting unreliable.

To address this, Smartsheet implemented layered rate limiting through AWS WAF. Three layers work together: blanket protection at the outer edge, per-user metering using custom aggregation keys on an identity header, and path-specific controls for expensive operations. Per-user metering means sessions are metered individually rather than pooled by IP. The layered rate limiting follows the three most important AWS WAF rate-based rules pattern.

Testing non-deterministic AI workflows

Smartsheet maintains the standard testing layers: unit tests, integration tests, tool-level validation. The MCP server, however, introduces a testing challenge that traditional API services don’t face. A conventional API response gets rendered deterministically by the UI. An MCP tool response passes through an LLM first. The model interprets it, reasons over it, and generates what the user actually sees. That layer of non-determinism changes what “correct” means for testing.

Smartsheet invests heavily in end-to-end workflow tests that include the LLM in the loop. These tests simulate realistic business scenarios: creating workspaces, writing data, querying results, and verifying that the model’s interpretation makes sense to the end user. These tests run in the CI/CD pipeline (GitLab CI with runners hosted on AWS) and continuously as canary tests against each production AWS Region.

Optimizing for AI consumption

As enterprises scale AI agent deployments, token consumption becomes a real cost driver. Every tool response costs money at the LLM and competes for context window capacity. Most MCP tool calls today run without sub-agent orchestration. The agent calls tools directly, one at a time, reasoning between each step. Without intelligent tool design, this gets slow, expensive, and error-prone fast. Each tool call must be self-contained and efficient on its own, which is why Smartsheet optimizes at three levels:

1. Progressive disclosure that caps token consumption per response.
2. Strongly typed tool schemas that help prevent hallucinated parameters and wasted calls.
3. A proprietary serialization format that reduces token count by 35–47 percent on data-heavy responses.

Progressive disclosure

Each tool response targets a token budget. The server dynamically calculates how many rows fit based on column count and data density. For example, a sheet with five columns can return more rows than one with 15 columns, but the total stays within budget. Whether a sheet has 50 rows or 50,000, the response size stays bounded. The model sees enough to orient, then narrows with filters based on what the user is actually asking about.

Metadata fields tell the model exactly what happened: is_sampled indicates whether data was truncated, rows_in_sheet gives the full count, rows_actual shows how many were returned, and filters_applied describes active filters. The model uses this to decide whether it has the full picture or needs to narrow its query with filters. Progressive disclosure is a server-side decision. The MCP server handles budgeting and sampling, while the metadata it returns gives the AI client the signals to orchestrate follow-up queries on its own.

Figure 2: Progressive disclosure in action: the AI client receives sampled data with metadata, then makes targeted follow-up requests.

Grounding the LLM is critical. Without constraints, models hallucinate parameter names, invent operators, and waste tokens on failed calls. Each tool publishes a strict JSON Schema through MCP’s tool discovery, generated from Pydantic models. Parameters are constrained to valid enums, column names are validated against the actual sheet before execution, and mismatches return structured errors with valid options instead of failing silently. Schema validation catches hallucinations at the boundary and means agents navigate the tool catalog reliably without trial and error.

Token-efficient serialization

JSON’s structural overhead (braces, quotes, repeated keys) typically consumes 15–25 percent of a response’s token count. For a server returning spreadsheet data with thousands of rows, the overhead adds up fast.

Smartsheet built a proprietary serialization format that alleviates this overhead. Key names appear once instead of repeating per row, and structural syntax is replaced by delimiters that tokenize more efficiently. On a representative 33-item filtered query, the optimized response is approximately 3,900 tokens versus approximately over 6,000 tokens for the equivalent JSON, roughly 35 percent fewer tokens carrying the same information. At 1,000 rows the gap widens further, because JSON repeats key names on every object while the optimized format declares them once.

What’s next for Smartsheet

AI agents integrate with Smartsheet through MCP today. In the first four weeks after general availability (GA), Smartsheet saw over 87 percent week-over-week user growth.

MCP is the distribution layer. What comes next is intelligence at the connection point itself. One example is resources that shape themselves to the person, team, and organizations using them. Another is agents that run autonomously on workflows, and a routing layer that lets specialists hand off reasoning to each other rather than starting cold on every step. Same MCP connection, different intelligence per customer, with no deployment required.

AWS is evolving its infrastructure to meet these emerging agentic requirements. Amazon Bedrock AgentCore provides runtime execution, discovery, personalization, and governance by default. Smartsheet continues to adopt and shape these capabilities with AWS.

The MCP protocol itself continues to evolve. Elicitations allow human-in-the-loop confirmation before destructive actions. MCP Apps bring interactive UI directly into AI conversations. Tasks support asynchronous, long-running operations. Smartsheet is evaluating these as they mature.

AI moves fast. Building on AWS gives us the infrastructure to keep pace whether that means new protocols, new models, or entirely new agent architectures.

To connect to Smartsheet’s MCP server, visit the AWS Marketplace listing, or see the Smartsheet MCP documentation.

---

About the authors

Vasil Kosturski

Vasil is a Principal Engineer at Smartsheet, where he leads the squad that built Smartsheet’s remote MCP server from concept through GA. He drove the system design, AWS architecture, and the AI-specific optimizations covered in this post. More broadly, he works across Smartsheet’s developer ecosystem and shapes its public API platform. Before Smartsheet he spent over a decade in distributed systems and real-time data, most recently as Lead Developer at Sportradar building large-volume Kafka-based event-processing pipelines. He is based in Plovdiv, Bulgaria.

Galina Jordanowa

Galina translates complex AI and product capabilities into clear, strategic market narratives and GTM motions. With 26+ years in B2B SaaS marketing and a dev background that means she actually gets how builders think, she’s spent her career connecting technical depth with business impact and stays genuinely energized by what’s next in AI and the new ways it’s reshaping how teams build and work.

Pyone Thant Win

Pyone is a Partner Solutions Architect at AWS, where she supports strategic ISV partners to bring AI-powered solutions to customers. She works at the intersection of cloud infrastructure and partner networks, helping partners leverage AWS services from AI/ML capabilities to data integration patterns to build deeper, more intelligent product experiences. Her work bridges hands-on technical partnership and go-to-market strategy, delivering joint solutions and industry offerings that reach shared customers.

Rony Blum

Rony is a Senior Solutions Architect at AWS based in Seattle, working with ISV customers to design and implement advanced cloud architectures, specializing in SaaS solutions, multi-tenant systems, and Generative AI applications. Outside of work, Rony enjoys exploring the Pacific Northwest trails on foot and hitting the slopes during ski season.