AWS reduced connecting a new dataset to an MCP server to a single JSON file

When a single AI assistant is connected directly to one database, the architecture looks simple. Problems begin once there are a dozen agents and hundreds of tables: each client maintains its own knowledge of the schemas, generates SQL according to its own rules, and checks permissions in its own way. A column change must be propagated across several applications, while the security team has no single place for auditing.

The team supporting Amazon's North American network of sortation centers described a different approach: a shared MCP server between agents and the corporate data lake. It runs on Amazon ECS Fargate, exposes the standard /mcp endpoint, and connects Athena, Redshift, and Bedrock Knowledge Bases as discoverable tools. The main practical promise is that a new dataset is added not through a new connector, but through a single JSON file containing metadata.

How one file replaces a separate integration

Consider an orders table. The JSON specifies the database and table name, the purpose of the data, column types and descriptions, the refresh frequency, and examples of real values. The examples are especially useful: the agent can see that a fulfillment-center identifier looks like FC-EAST-07, rather than an arbitrary region name. The same file can store guidance for a particular SQL engine—for example, how to compare a date stored as a string with a timestamp column.

After synchronization, the file becomes part of the Bedrock Knowledge Bases search catalog. When a user asks for the ten most expensive orders from the previous month, the agent first finds the relevant table and its description, then builds SQL, checks its compatibility with Athena, and only then executes the query. According to the authors, the full cycle took 15–20 seconds.

Individual applications can also have an additional context map. If a request comes from a workforce-planning tool, search can be restricted to workforce tables instead of scanning the entire catalog. This reduces noise and lowers the probability of selecting a similar but incorrect table. The same architecture can combine the result of a SQL query with a search across internal documents in a single step.

Where access control fits in

The MCP server is deployed in a private subnet behind an internal load balancer. The public client layer passes through AWS WAF and Cognito, while conversation state is stored in DynamoDB. The Athena tools accept only SELECT queries, and their calls are logged in CloudWatch. Bedrock Guardrails is applied to model interactions and helps filter harmful content, check whether answers are grounded in sources, and block some instruction-based attacks embedded in data.

But this is not a ready-made universal defense. Prohibiting write operations does not prevent access to unnecessary rows or columns if permissions are configured too broadly. Guardrails also cannot be treated as a guarantee against prompt injection. The team still needs row-level or column-level policies, query-cost limits, checks for data leakage through model responses, and tests for bypassing tenant isolation.

What to adopt in your own architecture

The value of the solution lies not in its long list of AWS services, but in its separation of responsibilities. The agent expresses intent, the catalog explains the data, the MCP gateway controls the tools, and the data store executes the query itself. Developers should start small: place one frequently used source behind a shared MCP interface, describe its schema in a machine-readable file, and measure table-selection accuracy, latency, and cost.

If that pilot works, the next step is centralized auditing and an explicit permission model. The JSON file itself speeds up table onboarding, but the quality of the entire system depends on who can read the data, how fresh the metadata is, and what happens when SQL is incorrect. Those checks are what turn an attractive demonstration into a production-ready enterprise gateway.