The problem
Customers started asking whether they could point an AI assistant at the platform: “which of my trucks have been sitting in a shop for more than a week?” is a question a service manager asks every morning, and answering it through the REST API takes several calls and some joining.
The Model Context Protocol (MCP) gives assistants a standard way to call tools. The naive approach is to generate one tool per REST endpoint. We tried that first. The assistant was given hundreds of tools, picked the wrong ones, paginated through everything and burned through both tokens and API quota to answer a simple question.
What I did
I built the MCP integration end to end, from AWS infrastructure and deployment to the server and the tools used by AI assistants. That work included the curated tool set, the authentication bridge to the existing OAuth 2.0 and permission model, the usage ledger and dashboards, and the infrastructure definitions. I also wrote the technical specification and target architecture that the team and stakeholders reviewed.
How I solved it
Curated tools instead of mirrored endpoints. A small number of tools answer the questions people actually ask: stalled cases for a customer, the overview of one case with its notes and line items, service history for an asset. Each tool makes several Gateway calls on the assistant’s behalf and returns a compact, shaped result. One curated call replaces a dozen raw ones and the assistant stops guessing.
Same identity, same permissions. The server does not have its own access model. The assistant authenticates with the platform’s OAuth, and every downstream call carries the user’s token, so the tools can only see what that person could see in the web app. Tool calls are tagged on the server span so they show up in tracing with the same attributes as any other API client.
Metering from day one. Every tool call is recorded with the number of Gateway requests it caused, so cost per call and per customer is a query, not a guess. Dashboards in Grafana and LogScale show live call cost, fan-out per tool and which partners are using it.
Infrastructure as code. IAM roles, storage and the container service were defined in Terraform alongside the rest of the platform, following the conventions the SRE team already used, so the service could move from a Lambda prototype to the container platform without a rewrite.
What was hard
Deciding what not to expose. Write operations through an assistant are a liability until the user-confirmation story is solid, so the first release is read-only. The second hard part was getting a clear picture of real usage: separating the assistant’s traffic from the rest of the API in logs required a dedicated client attribute all the way down the stack.
The result
A working MCP server in staging and production, demonstrated live to stakeholders with real customer data: three curated calls answer the “stalled trucks” question that previously took a dozen raw API requests. Usage and cost are visible per partner from the first call. The specification became the base for the product roadmap of the AI integration.
Where to see it
The server is a Decisiv product and its code is private. The architecture and the reasoning behind curated tools are described here; a diagram will be added once the public launch is announced.