Amazon sort centers put one MCP server between AI agents and the data lake

A team that supports Amazon's North America Sort Center (NASC) network has described how it gave planning staff conversational access to operational data through a single Model Context Protocol (MCP) server. The write-up appeared on the AWS Machine Learning Blog on 6 November 2026. It is vendor-published, from the team that built the system, and it reports design choices rather than measured business results.

The problem it replaced

The authors say several teams each built their own AI assistant for the data lake, and each embedded its own SQL generation, schema knowledge and connection handling. A schema change meant patching every agent. Access control was fragmented, with no single audit point, and onboarding a dataset required custom tool code, query validation and redeployment, which the post calls typically a multi-day effort per table.

How the gateway works

A user's question arrives from a web chat, Slack, an IDE plugin or an external agent. According to the post, a client service on Amazon ECS Fargate authenticates the user with Amazon Cognito, keeps session state in Amazon DynamoDB and forwards the request to an MCP server running on a separate Fargate cluster in private subnets, built with the FastMCP Python framework.

The server exposes three kinds of tool: SQL queries against Amazon Athena and Amazon Redshift, semantic search over documents and table metadata, and policy search, the last two on Amazon Bedrock Knowledge Bases. The agent looks up the relevant schema in a metadata catalogue, generates SQL with a model on Amazon Bedrock, validates and auto-corrects it for Athena, runs it and writes the answer in plain language.

One JSON file per dataset

Each dataset is described by a metadata file holding the table's business description, column descriptions, sample values, refresh schedule and engine-specific query hints. The example in the post tells the agent to wrap string literals in date() when comparing against timestamp columns. The team says sample values matter because the agent learns that a warehouse column holds codes such as FC-EAST-07 rather than region names.

A pipeline embeds these files with Amazon Titan Text Embeddings and indexes them, after which every connected agent can find the table without a restart. An optional context mapping limits a business domain, such as package data or labour planning, to named tables. The authors say this scoping keeps end-to-end interaction time at 15 to 20 seconds in their testing.

Controls the post describes

• Network: the MCP server sits behind an internal load balancer and is not reachable from the internet; only the client layer, behind AWS WAF, can call it.
• Identity: Amazon Cognito validates the user and only token-bearing requests go downstream.
• Read-only: the Athena tools accept SELECT statements and reject writes before they reach the data lake.
• Guardrails: Amazon Bedrock Guardrails applies to model interactions, described as designed to filter harmful content, check grounding and help block prompt injection.
• Audit: every tool call is logged to Amazon CloudWatch as structured JSON.

What the post leaves out

It gives no figure for how often the generated SQL is correct, no cost per query, and no count of users or agents. It does not say how a user's own permissions reach the data: the controls described are authentication at the front door and a read-only rule, and the authors list column-level restrictions per permission group as a next step. They also plan to feed failed or low-confidence queries back into better column descriptions.

The transferable idea is the separation the authors name as their key decision: keep the tool layer apart from the agent layer, because agents change quickly and data access patterns should outlast them.