Smartsheet bygde en ekstern MCP-server på AWS: slik gjorde de det

Etter hvert som bedrifter tar i bruk KI-agenter, trenger agentene strukturert tilgang til dataene i systemer som Smartsheet, men de færreste systemene er bygget for det. Smartsheet, en arbeidsstyringsplattform brukt av hundretusenvis av organisasjoner, løste det ved å bygge en ekstern Model Context Protocol-server på AWS, dokumentert i en gjennomgang på AWS Machine Learning Blog. Serveren lar KI-klienter som Claude Desktop og Amazon Quick lese og skrive ark, oppdatere oppgaver og styre arbeidsområder via naturlig språk.

Det arkitektoniske grepet er at én MCP-server betjener både Smartsheets egen innebygde assistent og eksterne agenter, med samme verktøy og optimaliseringer. Serveren kjører som statsløse containere på AWS Fargate for ECS, bak et API-gateway-lag med WAF, Shield, lastbalanserer og OAuth2-validering. Under der ligger domenetjenestene for transaksjoner og et intelligenslag på Amazon Neptune og Databricks for innsikt på tvers av prosjekter.

Den mest gjenbrukbare lærdommen for deg som bygger egen MCP-server ligger i token-økonomien. Hvert verktøysvar koster penger hos LLM-en og spiser av kontekstvinduet, så Smartsheet optimaliserer på tre nivåer: progressiv avsløring som setter et token-budsjett per svar og dynamisk beregner hvor mange rader som får plass, strengt typede JSON-skjemaer generert fra Pydantic-modeller som validerer kolonnenavn mot arket før kjøring, og et proprietært serialiseringsformat der nøkkelnavn oppgis én gang i stedet for å gjentas per rad.

«Vi bygger én gang, og hver eneste agent-klient får nytte av det umiddelbart» — Smartsheet, AWS Machine Learning Blog

For agent-trafikk skiller skaleringen seg fra vanlige API-mønstre: agenter fyrer av flere kall i sekundet mens de jobber, så blir stille mens modellen resonnerer. ECS-autoskalering kombinerer trafikkvolum med compute-utnyttelse for å absorbere burstene uten degradering. Rate-limiting måles per bruker via en identitetsheader i WAF, ikke per IP, fordi bedriftsbrukere ofte sitter bak delte proxyer der IP-basert måling blir upålitelig. Styring er bygget inn i hvert verktøy: readOnlyHint- og destructiveHint-annotasjoner lar klienten legge på bekreftelsesdialoger automatisk, og tilgang kan settes per organisasjon fra kun ikke-destruktive operasjoner til full skrivetilgang.

De fire første ukene etter lansering vokste brukertallet med over 87 prosent uke for uke, mens intern telemetri viser over 3 milliarder sparte tokens siden start.

Hva bør du gjøre?

1. Sett et token-budsjett per verktøysvar og returner metadata som is_sampled, rows_actual og filters_applied, så agenten selv kan be om mer presist.

1. Valider parametere mot faktiske data før kjøring med strenge JSON-skjemaer, så modellen ikke hallusinerer kolonnenavn og brenner tokens på feilkall.
2. Mål rate-limits per bruker, ikke per IP, hvis klientene dine kan sitte bak delte bedriftsproxyer.