Start with the official AWS Documentation MCP Server, which needs no production-resource authority. Pin the package, inspect its tools, and test a documentation query before considering a separate resource-access server. Any later AWS API connection must use a dedicated role whose complete permission boundary—not a short deny list—defines what the process can do.
ILAA reviewed the official MCP Servers for AWS documentation, the AWS Documentation MCP Server page, and the server source on 27 September 2026. PyPI reported package version 1.2.1 that day. Recheck the release and source before copying the pin.
Install one named server with a pinned package
Install uv from its official documentation, then add this server entry to your MCP host. The JSON shape below is the common command/arguments form; use the equivalent fields if your host names them differently.
{"mcpServers":{"aws-documentation":{"command":"uvx","args":["awslabs.aws-documentation-mcp-server==1.2.1"],"env":{"FASTMCP_LOG_LEVEL":"ERROR"}}}}This documentation server should not receive an AWS access key, production profile, or broad environment file. On first launch, retain the resolved package/version and verify that the executable came from the reviewed distribution.
Run exact documentation checks
- Open the host's MCP inspector and run
tools/list; retain the server identity and full tool list. - Call the documentation search tool with the exact query
Amazon S3 Block Public Access. - Call the documentation read/recommendation tool exposed by version 1.2.1 on one returned AWS documentation URL.
- Confirm every cited URL is on an AWS documentation domain and that no resource credential was requested.
- Disconnect the server and confirm those tools disappear from the host.
Pick one job before one server
| Job | Starting surface | Credential need | Initial risk |
|---|---|---|---|
| Read current AWS docs | Official documentation server | No production-resource authority | Low; returned text is still untrusted |
| Inventory a sandbox | Resource or API server | Dedicated read-only role | Medium; metadata is sensitive |
| Inspect costs | Cost and operations server | Narrow billing read | Medium; commercial exposure |
| Change infrastructure | Service-specific server | Task role with conditions | High; approval and rollback required |
Original asset: a reproducible inventory-role boundary
The next phase is optional and uses a separate AWS resource server. The policy below is a permissions boundary for a disposable inventory role. The role's identity policy must grant only the same four read actions; the boundary's NotAction deny blocks every other AWS action even if another identity policy is later attached. Organization SCPs and session policies can restrict it further.
{"Version":"2012-10-17","Statement":[
{"Sid":"AllowInventoryOnly","Effect":"Allow","Action":["sts:GetCallerIdentity","ec2:DescribeInstances","ec2:DescribeTags","ec2:DescribeRegions"],"Resource":"*"},
{"Sid":"DenyEverythingElse","Effect":"Deny","NotAction":["sts:GetCallerIdentity","ec2:DescribeInstances","ec2:DescribeTags","ec2:DescribeRegions"],"Resource":"*"}
]}Region semantics: set AWS_REGION=us-east-1 in the isolated server process and test the endpoint region separately. Do not claim that aws:RequestedRegion filters the regions returned by DescribeRegions; it constrains the endpoint receiving the API request, not the contents of the response.
The observe-before-act ledger
| Probe | Expected result | Evidence to retain |
|---|---|---|
sts:GetCallerIdentity | Disposable role ARN and expected account | Redacted response and timestamp |
ec2:DescribeRegions against the configured endpoint | Call succeeds; returned list is not represented as region-filtered | Tool, endpoint region, and redacted response |
ec2:DescribeInstances | Inventory succeeds without secret fields | Count and redacted IDs |
ec2:RunInstances with dry-run semantics where supported | Denied by DenyEverythingElse | Authorization failure and policy statement |
s3:ListAllMyBuckets | Denied even if another identity policy attempts to allow it | Authorization failure proving the boundary |
Score one point per expected result. Do not enable any write action below 5/5. A successful tool call proves only that call; it does not prove that every other action is safe.
Promotion checklist
- Pin and record the exact server artifact.
- Keep the documentation server credential-free.
- For any resource server, use a disposable role with a reviewed trust policy, identity policy, and permissions boundary.
- Capture the discovered tool list and exact tool arguments.
- Pass every read and denial row.
- Add one reversible write only after replacing the boundary with a separately reviewed task boundary and approval flow.
- Keep CloudTrail and MCP-host traces long enough to investigate failures.
Bottom line: first prove the named documentation server with no AWS resource credential. Treat inventory and mutation as separate promotions, each with a complete permission boundary and retained evidence.