awslabs/mcp: AWS MCP servers, what ships in the repo and how to wire one into Claude Code

What awslabs/mcp actually is, and the problem it removes

The repository is a suite of specialized MCP servers, not one program. Each server wraps a slice of AWS (documentation lookup, cost analysis, a specific database, a container platform) and exposes it through the Model Context Protocol, so an AI client can call AWS operations the same way it calls any other MCP tool.

The problem it removes is glue code. Without a shared protocol, every assistant that wanted to read AWS documentation or query a service needed a bespoke integration. MCP standardizes the connection: one client, many servers, each speaking the same protocol. The README describes MCP as "an open protocol that enables seamless integration between LLM applications and external data sources and tools," quoting the protocol's own README.

The audience is narrow and specific: people using agentic coding assistants or chat clients that already support MCP, and who want AWS context inside those tools. If your client has no MCP support, nothing here applies to you.

Clients, transports, and the SSE removal

MCP hosts run MCP clients, and each client keeps a 1:1 connection with a server. The README names Kiro, Cline, Cursor, Windsurf, VS Code, Claude Code, and Claude Desktop as clients, and gives a separate configuration walkthrough for each. That list matters more than it looks: the repo's value depends on your editor or chat app being on it.

On transport, the README has a section titled "Server Sent Events Support Removal." That is a real constraint for anyone who built against an older SSE-based setup. The README does not spell out the replacement, so treat the transport question as something to confirm against the server you intend to run rather than assuming the old wiring still works.

The README also splits local from remote MCP servers and explains when each fits. Local servers run on your machine and can reach local data sources; remote servers are reachable over the network. Which one you want depends on whether the tool needs your filesystem or just AWS APIs.

Installing an AWS MCP server and adding it to Claude Code

There is no single install command for the whole suite. You pick a server, then register it with your client. The README's installation section splits macOS/Linux from Windows, and each server has its own package name and README under src/.

The README's Claude Code path uses a .mcp.json file at the project root. The shape below follows that convention: an mcpServers object keyed by server name, with the command to launch it. Replace the server entry with the one from the specific server's README, since the package name and arguments differ per server.

{
  "mcpServers": {
    "aws-documentation": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"]
    }
  }
}

After saving the file, restart or reload Claude Code so it picks up the new server. If the server starts, it appears in the client's MCP server list; if it fails, the client reports a launch error, which usually means the package name or the runtime is wrong.

For clients that read a user-level config instead, the paths differ: Kiro uses ~/.kiro/settings/mcp.json, Windsurf uses ~/.codeium/windsurf/mcp_config.json, Cursor uses .cursor/mcp.json, and VS Code uses .vscode/mcp.json. The contents follow the same mcpServers pattern.

Credentials are the part the README does not resolve for you. Servers that call AWS APIs need working AWS credentials in the environment the client launches them from, and the top-level README does not enumerate which servers need what. Check the individual server's README before assuming a server is unauthenticated.

The Lambda handler module, for people shipping servers rather than using them

Most of the repository is consumer-facing, but one piece is for builders: the MCP AWS Lambda Handler Module. It is a Python module for running an MCP server inside AWS Lambda, which changes the operational model from a process on your laptop to a function behind an endpoint.

This is the part that connects to the "remote MCP servers" discussion. A remote server has to live somewhere, and Lambda is one of the answers the repo provides. If you are writing your own MCP server for AWS and want it hosted rather than local, this module is the starting point.

It is also the least documented area in the repository. The README names the module and links it in the table of contents, but does not give deployment steps. Anyone going down this path should read the module's own documentation rather than extrapolating from the client-side setup instructions, which describe a different problem.

Where awslabs/mcp is the wrong choice

The README itself carries the strongest warning, and it is not buried. A tip near the top states that the Agent Toolkit for AWS is the successor to the MCP servers, plugins, and skills on AWS Labs, and that AWS recommends it "if you're building production software using coding agents or building agents for your own customers." The tip lists what the successor adds: IAM condition keys to distinguish agent actions from human ones, CloudWatch and CloudTrail visibility, and skills evaluated for accuracy and effectiveness.

Read that as a scope boundary. This repo continues to work and accept contributions, and the README says the most useful projects here will move into the Agent Toolkit over time. But if your requirement is distinguishing an agent's API calls from a person's in IAM, or getting agent activity into CloudTrail, the README points you elsewhere.

A second limitation is structural: this is a suite with uneven documentation. The top-level README is a directory organized by what you are building and how you are working, with dozens of servers across infrastructure, AI/ML, data, developer tools, integration, cost, and healthcare categories. Breadth here means the top-level page cannot tell you the credentials, arguments, or failure modes of any individual server. You will be reading per-server READMEs.

Alternatives and how they differ

The obvious alternative is the Agent Toolkit for AWS, and the difference is not cosmetic. awslabs/mcp is a set of servers you register with an existing MCP client; the Agent Toolkit is positioned by the README as the successor for production agent work, with IAM condition keys, CloudWatch and CloudTrail visibility, and evaluated skills built in. If you need an audit trail of what an agent did, that distinction decides the choice for you.

A second comparison is within the repo itself: local versus remote servers. A local server runs as a process on your machine, which suits filesystem access and interactive development. A remote server is hosted, which suits shared use and removes the need for every developer to install and authenticate locally. The README frames this as a choice, and it is a genuine architectural fork rather than a preference.

A third option is writing your own MCP server. The protocol is open, the repo is Apache-2.0, and the Lambda handler module exists precisely to host custom servers. If your need is one narrow AWS capability and the suite has no server for it, building on the protocol directly is a legitimate path.

Licence, maintenance, and what upgrading costs you

The repository is Apache-2.0, with a NOTICE file alongside the LICENSE. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations, and the NOTICE file is part of that. The README ends with a Disclaimer section. This is a description of the licence terms, not legal advice; if you are redistributing or embedding the servers, have counsel read the LICENSE and NOTICE.

The last push to the default branch was on 2026-09-10, and releases are frequent: 2026.09.20260908143235 on 2026-09-08, 2026.09.20260901224839 on 2026-09-02, and 2026.08.20260831234710 on 2026-09-01. Those version strings are timestamp-derived, which tells you the release cadence is automated rather than curated. Pinning to @latest, as the client config examples do, means you absorb whatever shipped most recently.

That cadence is the upgrade cost. A suite that releases weekly will occasionally move a tool's arguments or behavior, and because each server is a separate package, breakage arrives one server at a time. Pinning a specific version in your mcp.json is the mechanism you have for controlling that, and the README's own examples do not do it. The repository also carries .pre-commit-config.yaml, .ruff.toml, and trivy.yaml, so contributions are expected to pass lint and security scanning, which is a signal about contribution quality rather than a guarantee about any given release.

Editorial conclusion

Adopt awslabs/mcp if you are prototyping with an MCP client and want AWS documentation, cost, or service-specific tooling inside the assistant, because each server installs on its own with uvx and a host config file. Skip it for production agent products: the README states the Agent Toolkit for AWS is the successor and is what AWS recommends for agents built for customers or production coding agents. Before wiring anything up, check the individual server's own README for its package name and required AWS credentials, since the top-level README is a directory rather than a full install guide.

Frequently asked questions

Official sources

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