An Amazon team has described how it built a serverless Model Context Protocol server on Amazon ECS with AWS Fargate to let AI agents query an enterprise data lake. The headline design choice: exposing a new dataset requires only a JSON metadata file, with no per-dataset integration code. The AWS Machine Learning blog post comes from the team supporting Amazon's North America Sort Center network, where planning teams rely on operational data for capacity, labor and package flow.
TL;DR: the design in one table
| Question | Answer from the AWS post |
|---|---|
| What problem does it solve? | Every agent rebuilt its own SQL generation, schema knowledge and access control |
| How is a dataset added? | One metadata JSON file, discovered on the next pipeline sync |
| Which clients work? | Any MCP-compatible client via the /mcp endpoint |
| Where is access enforced? | Centrally, at the MCP server layer |
| Can it write data? | No, Athena tools are SELECT-only |
| How fast? | 15 to 20 seconds end to end in the team's testing |
| Where does it run? | ECS Fargate, stateless tasks with state in DynamoDB |
The problem: every agent reinvents data access
The authors describe a common starting point: wire agents straight to databases and APIs with no shared gateway. Each new dataset needs custom code, and each agent reimplements access control. Their data lake holds thousands of datasets, and several teams built their own assistants. Each embedded its own SQL generation logic and connection handling, so a schema change meant patching every agent. There was no single audit point, and onboarding a table was typically a multi-day effort.
They set four goals: configuration-driven access, agent-agnostic tool interfaces, centralized permission enforcement, and elastic infrastructure for bursty AI workloads. If you have read our explainer on MCP, this is the standard argument for a protocol gateway applied to enterprise data.
The architecture: four layers
- Client layer. A request goes through Amazon Route 53 to an Application Load Balancer with HTTPS and AWS WAF. Amazon Cognito authenticates the user with JSON Web Tokens, and Amazon DynamoDB stores sessions. The client runs on ECS Fargate.
- MCP server layer. A separate Fargate cluster in a private subnet behind an internal load balancer. A Bedrock-powered agent orchestrates tools built with FastMCP, a Python framework for MCP servers. Tasks are stateless, with conversation state in DynamoDB, so they can be replaced or scaled without data loss.
- Tools layer. SQL query tools against Amazon Athena and Amazon Redshift, document and metadata search over Amazon Bedrock Knowledge Bases, and policy search over the same service.
- Knowledge-base refresh layer. Metadata files are embedded with Amazon Titan Text Embeddings and indexed so new tables become discoverable.
Agents sharing one workspace through a central MCP gateway to the data lake
The metadata file is the product
The notable idea is that the schema knowledge lives in data, not code. The example file in the post includes the database service, database and table names, a business description, column details, load type, refresh frequency, table size and timestamps. Two details stand out.
First, the business description carries engine-specific hints. The authors give one: in Athena SQL, always wrap string literals in date() when comparing against timestamp columns. That kind of hint reduces SQL validation failures.
Second, each column pairs name and type with a natural-language description and sample values. The post says sample values matter for accurate WHERE clauses, because the agent learns that a warehouse column holds codes like FC-EAST-07, not phrases like "East region facility."
An optional context mapping narrows search to named tables per business domain. If none is given, the agent searches all indexed tables. The authors say scoping reduces latency and improves SQL accuracy, and keeps interactions in the 15 to 20 second range in their testing.
What happens when someone asks a question
For a question such as "What were our top 10 highest-value orders last month?", the client first adds business context. The agent embeds the question, searches the metadata catalog, and picks the most relevant table with a lightweight LLM call. It then generates SQL from the schema, column descriptions and hints, validates and auto-corrects it for Athena compatibility, and runs it. Results come back as a natural-language answer. The same server can answer mixed questions, such as a Q4 return rate from Athena plus a product team's analysis from the knowledge base, in one turn.
Security: layers, not a single gate
According to the post:
- The MCP server sits in private subnets and is not internet-reachable. Only the client layer can route to it.
- Cognito validates identity at the client layer and only token-bearing requests go downstream.
- Athena tools reject non-SELECT statements before they reach the lake.
- Amazon Bedrock Guardrails applies to every model interaction, designed to filter harmful content, enforce grounding checks and help block prompt injection.
- Every tool invocation is logged to Amazon CloudWatch as structured JSON, giving security teams one audit point.
The authors note the architecture is available in Regions where Bedrock and Bedrock Knowledge Bases are available. For more on how AWS thinks about bounding agent actions, read our post on AWS trust in depth for agent autonomy.
Scaling and multi-tenancy
Client and server layers use ECS Service Auto Scaling, with a CPU threshold of 50 percent noted for the client. Athena and Bedrock scale as managed services. Because the /mcp endpoint accepts any compatible client regardless of model or orchestration framework, adding a new agent means pointing it at the endpoint. Our guide to the AWS Agent Registry covers a related approach for discovering tools at runtime.
Limits and open questions
The post is candid about next steps, which also reveal today's gaps:
- Column-level control. The authors plan finer-grained access, where table owners mark sensitive columns as restricted per permission group and the agent excludes them from generated SQL. That implies it is not there yet.
- Feedback loop. Failed or low-confidence queries do not yet automatically produce suggestions to improve descriptions or hints.
- Latency. Fifteen to twenty seconds suits planning questions but not interactive dashboards.
- No public code. The post shows configuration, not a repository.
- Accuracy numbers. It reports no text-to-SQL accuracy rate, so judge quality by testing on your own tables.
Questions teams will ask before building this
Why a separate MCP server instead of tools inside each agent? The authors' answer is drift. When each agent embeds its own SQL generation and access rules, a schema change or a permission change has to be made in every agent. A shared server turns that into one change. It also gives security a single place to audit, which the post names as a design goal.
Why metadata files and not a live schema crawl? A crawl gives column names and types but not meaning. The post's files carry business descriptions, engine-specific query hints and sample values, which are the facts a model needs to write correct SQL. Those facts come from people who own the data, so a file that table owners can edit and review fits that workflow.
Why Fargate? The workload is bursty and the tasks are stateless, with conversation state in DynamoDB. That suits a serverless container platform where tasks can be replaced or scaled without data loss and nobody manages EC2 instances.
What stops a bad query? Several things, at different layers: authentication at the client, a private network path to the server, SELECT-only enforcement in the Athena tools, SQL validation and auto-correction, and Bedrock Guardrails on model interactions. No single layer is trusted alone, which is the right instinct for any agent that can reach real data.
What would we test first? Accuracy on your own tables. The post reports latency but no accuracy figure, and text-to-SQL quality depends heavily on how well descriptions and sample values are written. Build a small set of questions with known answers, run them after each metadata change, and track failures the way you would track unit tests.
What about sensitive columns? The authors list column-level restrictions as future work. Until you have them, keep sensitive tables out of the indexed set or put them behind a separate server and permission scope.
What to copy for your own stack
- Put schema meaning in versioned metadata files, including sample values and engine hints.
- Keep agents thin and the tool layer shared, so data access outlives any one agent.
- Enforce read-only at the tool, not in the prompt.
- Scope searches with domain mappings before generating SQL.
- Log every tool call in one place.
For related AWS agent guides, see the Bedrock managed knowledge base with agentic retrieval and Claude Code remote sessions on Bedrock AgentCore. If you let agents touch data, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.
Related reading
- What is MCP: Model Context Protocol guide
- AWS trust in depth for agent autonomy
- AWS Agent Registry and runtime tool discovery
- Bedrock managed knowledge base with agentic retrieval
- Claude Code remote sessions on Bedrock AgentCore
- Model Context Protocol specification
Details are accurate as of November 6, 2026 and reflect the AWS post published that day.