{"slug": "how-smartsheet-built-a-remote-mcp-server-on-aws", "title": "How Smartsheet built a remote MCP server on AWS", "summary": "Smartsheet built a remote Model Context Protocol (MCP) server on AWS that gives AI agents structured access to its enterprise work management platform, enabling natural language interactions through assistants like Amazon Quick and Claude Desktop. The server, which connects to Smartsheet's existing APIs and adds an AI-optimized interface, has saved over 3 billion tokens since launch through optimizations designed to minimize token cost and prevent hallucination. The architecture uses AWS Fargate, Amazon ECS, Amazon Kinesis Data Streams, Amazon Neptune, and Amazon Bedrock to serve both internal and external AI agents on the same infrastructure.", "body_md": "[Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# How Smartsheet built a remote MCP server on AWS\n\n[Smartsheet](https://www.smartsheet.com/) 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](https://developers.smartsheet.com/ai-mcp/smartsheet/mcp-server) on AWS that gives AI clients direct access to its data and capabilities. AI assistants like [Amazon Quick](https://aws.amazon.com/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.\n\nEnterprises 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.\n\nThe 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.\n\nIn 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.\n\n## Architecture\n\nOne 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.\n\nThe architecturally critical AWS services in the data path are:\n\nfor stateless server containers.[AWS Fargate](https://aws.amazon.com/fargate/)for[Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/)and**Amazon Kinesis Data Streams** for change-event ingestion into**Amazon Managed Service for Apache Flink**.** Amazon Simple Storage Service (Amazon S3)**and** Amazon Bedrock**for LLM inference and knowledge graph powering cross-project insights.** Amazon Neptune**\n\nThe detailed architecture flow is as follows:\n\n**AI clients to API gateway layer to MCP Server**: Requests pass through an API gateway layer ([AWS WAF](https://aws.amazon.com/waf/),[AWS Shield](https://aws.amazon.com/shield/), AWS Application Load Balancer, and OAuth validation) before reaching the MCP server on AWS Fargate.**MCP Server to Domain Services**: The MCP server calls Smartsheet’s domain services through their APIs for transactional operations.** MCP Server to Intelligence Layer**: The MCP server queries the Intelligence Layer built on Amazon Neptune and Databricks for cross-project agentic insights.**Domain Services to Intelligence Layer**: Change events stream through[Amazon Kinesis](https://aws.amazon.com/kinesis/)and Apache Flink into the Amazon S3-backed intelligence layer. The Intelligence Layer follows the medallion architecture.\n\n*Figure 1: Smartsheet MCP Server architecture on AWS.*\n\nSupporting services such as edge protection, container registry, observability, secrets appear in the relevant sections in the following sections.\n\n## Deployment and scaling\n\nOn 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.\n\nTo 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.\n\nOn the deployment side, shipping updates without disrupting active agent sessions is equally critical. Container images are stored in [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) (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.\n\nDeployments roll out to the smallest region first, following the [AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/oe-design-principles.html) 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](https://aws.amazon.com/solutions/guidance/deploying-model-context-protocol-servers-on-aws/).\n\n## Governance and observability\n\nFor 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.\n\nAccess 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`\n\nand `destructiveHint`\n\nso AI clients apply appropriate confirmation flows automatically.\n\nThe 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.\n\nAgent 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](https://aws-observability.github.io/observability-best-practices/guides/containers/aws-native/eks/log-aggregation/) pattern, with infrastructure metrics surfaced through Amazon CloudWatch. [Datadog](https://www.datadoghq.com/) provides per-tool application performance monitoring (APM) visibility, and [PagerDuty](https://www.pagerduty.com/) handles incident routing.\n\nEvery invocation also emits a structured analytics event through [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) (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.\n\n## Securing AI agent traffic\n\nThe 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](https://aws.amazon.com/solutions/guidance/deploying-model-context-protocol-servers-on-aws/). 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.\n\nAI 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.\n\nTo 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](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) pattern.\n\n## Testing non-deterministic AI workflows\n\nSmartsheet 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.\n\nSmartsheet 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.\n\n## Optimizing for AI consumption\n\nAs 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:\n\n[Progressive disclosure](https://en.wikipedia.org/wiki/Progressive_disclosure)that caps token consumption per response.- Strongly typed tool schemas that help prevent hallucinated parameters and wasted calls.\n- A proprietary serialization format that reduces token count by 35–47 percent on data-heavy responses.\n\n### Progressive disclosure\n\nEach 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.\n\nMetadata fields tell the model exactly what happened: `is_sampled`\n\nindicates whether data was truncated, `rows_in_sheet`\n\ngives the full count, `rows_actual`\n\nshows how many were returned, and `filters_applied`\n\ndescribes 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.\n\n*Figure 2: Progressive disclosure in action: the AI client receives sampled data with metadata, then makes targeted follow-up requests.*\n\n### Keeping LLMs grounded: Schema-driven tool contracts\n\nGrounding 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](https://docs.pydantic.dev/) 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.\n\n### Token-efficient serialization\n\nJSON’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.\n\nSmartsheet 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.\n\n## What’s next for Smartsheet\n\nAI 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.\n\nMCP 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.\n\nAWS is evolving its infrastructure to meet these emerging agentic requirements. [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) provides runtime execution, discovery, personalization, and governance by default. Smartsheet continues to adopt and shape these capabilities with AWS.\n\nThe MCP protocol itself continues to evolve. [Elicitations](https://modelcontextprotocol.io/specification/2025-06-18/client/elicitation) allow human-in-the-loop confirmation before destructive actions. [MCP Apps](https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/) bring interactive UI directly into AI conversations. [Tasks](https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks) support asynchronous, long-running operations. Smartsheet is evaluating these as they mature.\n\nAI moves fast. Building on AWS gives us the infrastructure to keep pace whether that means new protocols, new models, or entirely new agent architectures.\n\nTo connect to Smartsheet’s MCP server, visit the AWS Marketplace listing, or see the [Smartsheet MCP documentation](https://developers.smartsheet.com/ai-mcp/smartsheet/install-the-smartsheet-mcp-server/connect-amazon-quick).", "url": "https://wpnews.pro/news/how-smartsheet-built-a-remote-mcp-server-on-aws", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/how-smartsheet-built-a-remote-mcp-server-on-aws/", "published_at": "2026-07-17 16:32:06+00:00", "updated_at": "2026-07-20 17:01:07.868562+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "ai-tools"], "entities": ["Smartsheet", "AWS", "Amazon Bedrock", "Amazon Neptune", "Amazon Fargate", "Amazon ECS", "Amazon Kinesis", "Claude Desktop"], "alternates": {"html": "https://wpnews.pro/news/how-smartsheet-built-a-remote-mcp-server-on-aws", "markdown": "https://wpnews.pro/news/how-smartsheet-built-a-remote-mcp-server-on-aws.md", "text": "https://wpnews.pro/news/how-smartsheet-built-a-remote-mcp-server-on-aws.txt", "jsonld": "https://wpnews.pro/news/how-smartsheet-built-a-remote-mcp-server-on-aws.jsonld"}}