Wire up the aws-documentation MCP server so Claude answers from today's docs instead of last year's training data

The awslabs.aws-documentation-mcp-server is an MCP server published by AWS Labs that gives Claude four read-only tools against the live AWS documentation site: search_documentation for queries, read_documentation for whole pages, read_sections for specific headings on a page, and recommend for related content and recent additions to a service. It runs locally as a Python process, talks to the same docs you read in a browser, and returns the URL alongside the content so any claim Claude makes can be checked. For an SRE who spends real time on AWS, it is the smallest MCP install that changes the shape of every AWS-flavored conversation.

Why feature it on a Friday in late May 2026. Model training data has a cutoff — for the model writing this post, the end of May 2025 — and AWS ships features weekly. Without a doc connector, anything you ask about Bedrock, EKS auto-mode, S3 Vectors, or any quota that has changed in the last twelve months is at best stale and at worst wrong with confidence. With the doc server installed, the workflow flips: Claude searches first, fetches the relevant section, and quotes the page back. The answer carries a URL you can hand to a teammate without an apology.

Quotas, limits, and edge-case behavior. The first place this earns its install is in the boring questions that used to require a tab to docs.aws.amazon.com and ten minutes of scrolling. Ask "what's the current S3 multipart upload part-size range" or "how many concurrent executions does Lambda allow per region by default" or "can ALB target groups span VPCs in 2026 yet" and Claude will route through search_documentation, pull the right page, and answer with the section quoted. The wins are small individually but compound across a day — you stop trusting half-remembered quota numbers, and you stop interrupting yourself to verify them.

Service comparison and architecture review. When you are picking between two AWS services or writing an ADR, you want the actual SLA, the actual pricing model, and the actual feature matrix from each service's docs side by side. The doc server makes that one prompt: "compare DynamoDB on-demand vs provisioned for a workload with bursty 50k reads/sec peaks, and cite the limits page for each." Claude can fan out to two search_documentation calls, pull the relevant sections, and produce a comparison whose numbers you can verify in one click. This is where the read_sections tool matters — AWS pages are long, and reading the whole thing into context for a single number is expensive; reading one section is not.

Surfacing what shipped this week. The recommend tool is the one that doesn't have an obvious analog in a browser. Given a URL on a service's page, it returns related and newly-added content for that service. Point it at the EKS landing page and you get the recently-published What's New entries, the related service pages, and the cross-service guides — useful when you missed the re:Inforce announcements last week and need a one-prompt catch-up. Treat it as the "what changed for this service" probe before you spend a meeting designing around assumptions that just got obsoleted.

The trap to avoid is treating read_documentation like curl. AWS pages are often 30,000+ characters and chunked across sub-pages; pulling a whole page just to answer one question can blow tens of thousands of tokens on text you'll never use. The right default is search_documentation first to narrow the page, then read_sections with specific section titles from the result's TOC, and only fall back to read_documentation with pagination (start_index) when the section split isn't precise enough. The MCP server's own instructions say exactly this, and it is worth pinning to memory.

See the try-it block for the install and a single probe that confirms the server is wired in.