AWS MCP Server Reaches General Availability: Secure AI Agent Access to AWS

AI agents and coding assistants have become powerful tools for developers, but they often struggle with giving these agents real, authenticated access to cloud services without compromising security. The AWS MCP Server, now generally available, solves this by providing a managed remote Model Context Protocol (MCP) server. It allows agents to interact with all AWS services through a small, fixed set of tools, using your existing IAM credentials. This means agents can perform thousands of AWS API operations safely, retrieve up-to-date documentation, and even run sandboxed Python scripts—all without handing over the keys to the kingdom. Below, we answer common questions about this new offering.

What is the AWS MCP Server and why was it created?

The AWS MCP Server is a managed implementation of the Model Context Protocol (MCP) that gives AI agents and coding assistants secure, authenticated access to AWS services. It’s part of the Agent Toolkit for AWS, which also includes skills and plugins to help agents build more effectively on AWS. The server was created to address a fundamental pain point: developers want to empower AI agents to work with AWS at depth, but fear granting excessive permissions or exposing credentials. Traditional approaches often result in agents using outdated documentation, reaching for the AWS CLI instead of modern tools like AWS CDK, or generating overly broad IAM policies. The AWS MCP Server provides a controlled, context-efficient way to give agents real power without compromising security, using a compact set of tools that doesn't consume your model's precious context window.

What problems do AI coding agents face when working with AWS?

AI coding agents are great for many tasks, but they run into real trouble when diving deep into AWS. Without current documentation, they rely on training data that might be months old—missing new services like Amazon S3 Vectors or Amazon Aurora DSQL. They also tend to default to the AWS CLI for infrastructure tasks instead of using AWS CDK or CloudFormation, which are better suited for production. Worse, they often generate IAM policies that are far too permissive, giving the agent—and potentially an attacker—more access than needed. The result? Infrastructure that works in a demo but fails in production. The AWS MCP Server solves these issues by providing real-time documentation retrieval and enforcing fine-grained permissions through standard IAM policies, so agents work with up-to-date best practices and only the access they need.

What tools does the AWS MCP Server provide?

The server exposes a minimal set of tools designed to handle the most common agent needs without bloating the context window. The primary tool is call_aws, which can execute any of the 15,000+ AWS API operations using your existing IAM credentials. This means as soon as AWS launches new APIs, they’re supported within days. Two other tools—search_documentation and read_documentation—fetch current AWS documentation and best practices at query time, ensuring the agent always works from the latest information. Finally, the run_script tool lets agents write and execute short Python scripts server-side in a sandboxed environment inherited from AWS internal infrastructure. This flexibility allows agents to perform complex workflows without hitting context limits or needing local file system access.

What new capabilities come with general availability?

The general availability release introduces several key enhancements. First, the MCP Server now supports IAM context keys, which means you no longer need a separate IAM permission just to use the server. You can express fine-grained access policies directly in standard IAM policies, making it easier to integrate with existing security controls. Documentation retrieval no longer requires authentication, simplifying setup for agents that just need to read docs. The token consumption per interaction has been reduced significantly—critical for complex, multi-step workflows where every token counts. The most impactful addition is the run_script tool, which allows agents to write short Python scripts that execute in a sandboxed, network-isolated environment. This sandbox inherits the agent's IAM permissions but has no network access, so agents can process data and chain API calls without exposing your local system.

How does the run_script tool work and what are its benefits?

The run_script tool lets an agent craft a short Python script that runs on the server side in a dedicated sandbox. The sandbox is completely isolated from the network and has no access to your local file system or a shell. It inherits the IAM permissions of the agent, so it can call AWS APIs exactly as the agent would—but without any extra attack surface. This design is a game-changer for efficiency. Before, if an agent needed to call multiple APIs and combine results, it would have to make separate calls, each consuming context and slowing down the workflow. With run_script, the agent can chain API calls, filter responses, and compute results in a single round-trip. This reduces latency, cuts down on token usage, and keeps the agent focused on the task rather than verbose step-by-step execution. It’s a secure, efficient way to give agents complex data-processing capabilities.

What is the transition from Agent SOPs to Skills?

With the general availability release, AWS is transitioning from what were called Agent SOPs (Standard Operating Procedures) to a new concept called Skills. These Skills provide curated guidance and best practices for tasks agents commonly perform on AWS. Unlike the earlier SOPs, Skills are designed to be more modular, reusable, and up-to-date. They include actionable steps, code examples, and security recommendations that agents can follow to build infrastructure or configure services correctly. This shift reflects AWS’s focus on making agents smarter and more reliable out of the box. Skills will be continuously updated as AWS services evolve, so agents can always leverage the latest best practices—whether they’re setting up a VPC, deploying a serverless app, or managing IAM policies with fine-grained permissions.