awslabs/mcp: AWS MCP Servers and the Arrival of the Agent Toolkit

The problem: every AI client needs its own AWS integration

An AI coding assistant that cannot see your AWS account can still write Terraform, but it writes it blind. It does not know which resources exist, what the current configuration is, or what the official documentation says about the API it is calling. The usual fix is a bespoke plugin per client, which multiplies work by the number of clients you support. The Model Context Protocol removes that multiplication. A host application runs an MCP client that keeps a 1:1 connection to an MCP server, and the server exposes capabilities in a standard shape. Write the server once, and any MCP-capable host can use it. awslabs/mcp is AWS's own collection of such servers, covering infrastructure, serverless, AI and machine learning, databases, search, caching, messaging, cost, and healthcare categories, plus a documentation server that the README lists first. The audience is developers working inside an MCP client who want AWS context in the loop, not teams building an agent framework from scratch.

Transport: stdio, streamable HTTP, and the removal of SSE

The README has a dedicated section on transport mechanisms and a subsection titled Server Sent Events Support Removal. That is the most consequential protocol detail in the repository. SSE was the earlier way to run a remote MCP server over HTTP, and it has been dropped. Anyone with an existing client configuration pointing at an SSE endpoint should treat that configuration as stale. What remains, per the README's own framing, is a split between local and remote servers. Local servers run as processes on your machine and are reached over stdio; remote servers are hosted and reached over the network. The README asks when to use each, which implies the choice is not automatic. A local server inherits your machine's credentials and network position. A remote server does not, and the trust boundary moves. The repository also exposes an MCP AWS Lambda Handler Module, which is the piece that matters if you want to host a server yourself rather than run it locally. The README does not spell out in the excerpted material how the Lambda handler negotiates transport, so verify that against the module's own documentation before designing around it.

Configuration is per client, and the paths differ

There is no single installer that wires every client. The README walks through each host separately, and the config file paths are the concrete part worth copying. Kiro reads ~/.kiro/settings/mcp.json. Cline, when paired with Amazon Bedrock, reads cline_mcp_settings.json. Cursor reads .cursor/mcp.json. Windsurf reads ~/.codeium/windsurf/mcp_config.json. VS Code reads .vscode/mcp.json. Claude Code reads .mcp.json. Note the split between user-level paths (Kiro, Windsurf) and project-level paths (Cursor, VS Code, Claude Code). A project-level file can be committed and shared with a team; a user-level file cannot. That distinction affects how you distribute an internal server configuration, and the README does not comment on it. Installation itself has separate instructions for macOS and Linux versus Windows, plus a section on running MCP servers in containers. The container path is the one to read if you want the server isolated from the host filesystem rather than running as a direct child process of your editor.

The succession notice changes the adoption calculation

The most important text in the README is a tip block near the top. It states that the Agent Toolkit for AWS is now live, that it is the successor to the MCP servers, plugins, and skills available on AWS Labs, and that it was informed by customer feedback. It goes further: if you are building production software with coding agents, or building agents for your own customers, the README recommends the Agent Toolkit. It lists what the successor adds, including IAM condition keys to distinguish agent actions from human ones, CloudWatch and CloudTrail visibility, and skills evaluated for accuracy and effectiveness. Then it sets the boundary for this repository: it continues to work and accept contributions, and over time the most useful projects here will move into the Agent Toolkit. That is a clear signal about where maintenance attention is heading. It is not an archive notice, and the repository is not archived, but a reader deciding where to invest should weigh a stated successor against an active codebase.

Release cadence and what it costs to stay current

The release tags are timestamped builds, not semantic versions: 2026.09.20260908143235, 2026.09.20260901224839, 2026.08.20260831234710. Three releases appear within roughly a week, which tells you the project ships continuously rather than on a versioned schedule. For a consumer, that has a practical consequence. You cannot pin to a meaningful version number and reason about compatibility from it, because the number carries a date and a time, not a compatibility promise. If you vendor a server or build against the Lambda handler module, plan to track the tag stream rather than sit on a release. The upside of the cadence is that fixes land quickly. The downside is that a configuration which works today may need revisiting after a transport or interface change, and the SSE removal is the proof that such changes happen. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve notices and state changes. That is a summary of the licence's general shape, not legal advice, and your counsel should review any redistribution.

Where this is the wrong tool

Two cases stand out. The first is production agent platforms, and the README itself makes the argument: it recommends the Agent Toolkit for AWS for teams building production software with coding agents or agents for their own customers, and points to IAM condition keys and CloudWatch and CloudTrail visibility as things the successor provides. If your requirement is distinguishing agent actions from human actions in IAM, or getting agent activity into CloudTrail, this repository's README does not claim to solve that. The second case is a team that needs one narrow, stable integration and no others. Pulling in a suite of servers to reach a single service adds surface area: each server is a process or an endpoint, each holds credentials, and each is a place where an AI client can act on your account. A hand-written tool with a scoped role may be less machinery than adopting the suite. The README's own framing of local versus remote servers is the right question to ask here, because it is a question about where credentials live and what the model can reach, not just about convenience.

The alternative, and where the difference actually lies

The named alternative is the Agent Toolkit for AWS, and the README describes the difference in governance rather than in raw capability. Both give an agent access to AWS. The Toolkit adds IAM condition keys so that an action taken by an agent can be distinguished from one taken by a human, CloudWatch and CloudTrail visibility so that agent activity is observable through the services you already use for audit, and skills that the README says were evaluated for accuracy and effectiveness. Those are the properties an operations or security reviewer asks about first. If your blocker is that nobody can tell, after the fact, which principal did what, the Toolkit's framing addresses it and this repository's README does not claim to. If your blocker is simply that your editor cannot see your AWS resources, the servers here are the smaller step. The honest summary is that the two overlap in function and diverge in accountability, and the README puts the production case on the Toolkit's side.

What to verify before you commit

Start with the server list. The README organizes servers by what you are building and by how you are working, and those two indexes do not necessarily contain the same entries, so confirm the specific server you want is present and not one of the projects that has already moved. Next, confirm the transport. Given the SSE removal, check whether the server you intend to use is local or remote and update any existing client configuration that assumes SSE. Then check the client path against your host: if you intend to share the configuration with a team, .cursor/mcp.json, .vscode/mcp.json and .mcp.json are project-scoped and can be committed, while ~/.kiro/settings/mcp.json and ~/.codeium/windsurf/mcp_config.json are not. Finally, read the Agent Toolkit announcement and decide which side of the README's own recommendation you fall on. The repository is Apache-2.0, not archived, and still accepting contributions, so it is a reasonable place to build a prototype. The README's tip block is the reason it is a harder case to defend as a long-term production foundation.

Editorial conclusion

Adopt awslabs/mcp if you are prototyping with an MCP client such as Kiro, Cline, Cursor, Windsurf, VS Code or Claude Code and want AWS service access without writing a server yourself. Do not adopt it as the foundation of a production agent platform: the README names the Agent Toolkit for AWS as the successor and recommends it for exactly that case. Before wiring anything in, check whether the specific server you need is still in this repository, which transport it uses now that SSE support has been removed, and how the Agent Toolkit covers the same service.

Official sources

1. awslabs/mcp on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases