Atlas talks to AWS through the managed AWS MCP Server, reading Lambda configs, CloudWatch logs, and IAM policies, then fixing the permission the logs are rejecting. Point Atlas at it with atlas mcp add aws --url https://aws-mcp.us-east-1.api.aws/mcp then atlas mcp auth aws. OAuth requires the AWSMCPSignInOAuthAccessPolicy IAM policy on your principal.
What Atlas can do with the managed AWS MCP Server
Atlas talks to AWS through the managed AWS MCP Server, reading Lambda configs, CloudWatch logs, and IAM policies. In 2026 that combination is what lets the terminal-native agent close a specific loop: read the CloudWatch error, find the IAM statement being denied, and fix it in your infrastructure code.
Most AWS debugging is a translation problem. CloudWatch tells you an operation was denied, the Lambda config tells you which role was in play, and the IAM policy tells you what that role is actually allowed to do. Three consoles, one bug. The managed AWS MCP Server hands all three to Atlas at once. Because Atlas is already running in your repository, it can go one step further than diagnosis: once it knows the denied action, it can edit the policy document that lives in your working tree rather than reading the answer back to you from a browser tab.
How to add the managed AWS MCP Server to Atlas
Two commands connect Atlas to AWS in 2026. Point Atlas at the managed AWS MCP Server with atlas mcp add aws --url https://aws-mcp.us-east-1.api.aws/mcp then run atlas mcp auth aws to complete the OAuth flow. The eu-central-1 region has its own endpoint at https://aws-mcp.eu-central-1.api.aws/mcp.
The managed AWS MCP Server is a remote endpoint, so there is no local process to keep alive. atlas mcp add aws registers the URL and atlas mcp auth aws walks the OAuth handshake. The handshake has a prerequisite that catches people out: OAuth requires the AWSMCPSignInOAuthAccessPolicy IAM policy on your principal. Without that policy attached, atlas mcp auth aws will not complete, and the failure looks like an authentication problem rather than a missing permission. Attach the policy first, then authenticate. If you work out of Europe, use the eu-central-1 endpoint rather than pointing at us-east-1 across the ocean.
Using SigV4 with Atlas instead of OAuth
If your organization does not use OAuth for AWS access, Atlas can reach the managed AWS MCP Server over SigV4 by bridging through stdio: atlas mcp add aws --env AWS_PROFILE=$AWS_PROFILE --env AWS_REGION=us-east-1 -- uvx mcp-proxy-for-aws https://aws-mcp.us-east-1.api.aws/mcp. The bridge signs requests with your existing AWS profile.
SigV4 is the path for teams whose AWS access is already governed by named profiles, SSO sessions, or assumed roles, and who do not want to attach AWSMCPSignInOAuthAccessPolicy to every developer. The mcp-proxy-for-aws bridge runs locally under uvx, takes AWS_PROFILE and AWS_REGION from the environment Atlas launches it with, and signs each call to the managed AWS MCP Server on your behalf. Atlas sees the same tools either way. The only difference is where the identity comes from: an OAuth token in one case, your existing AWS profile in the other.
Remove the older AWS MCP servers first
Before adding the managed AWS MCP Server, remove any older aws-api-mcp-server or aws-knowledge-mcp-server entries from Atlas. AWS says to replace them with the managed server, and leaving both connected in 2026 gives the agent two overlapping sets of AWS tools with different auth paths.
Duplicate MCP servers are a real source of confusion for an agent. If Atlas can see both aws-api-mcp-server and the managed AWS MCP Server, it has to pick, and its picks will not be consistent across a session. AWS's own guidance is to replace the earlier servers with the managed one, so treat this as a migration rather than an addition. Delete the aws-api-mcp-server and aws-knowledge-mcp-server entries, add the managed AWS MCP Server, authenticate once, and confirm Atlas resolves AWS calls through the single endpoint.
The daily workflow: from a denied Lambda call to a fixed IAM policy
The core Atlas and AWS loop in 2026 runs in one prompt. Ask Atlas to describe the Lambda's configuration, read its CloudWatch errors, and fix the IAM statement being denied. Atlas pulls all three through the managed AWS MCP Server and returns a policy diff you can read before it goes anywhere.
Start with the symptom, not the cause: the Lambda is failing. Atlas describes the function's configuration through the managed AWS MCP Server, which tells it the execution role. It reads the CloudWatch logs, which tell it the exact action that was denied and on what resource. Those two facts fully determine the missing IAM statement. Atlas then writes it, and because your policies live as code in the repository Atlas is already working in, the change lands as a reviewable diff rather than a console click nobody can trace six months from now.
Keeping Atlas from mutating an AWS account unattended
Set 'aws *' to ask under permission.bash so nothing mutates an AWS account without an explicit approval. In 2026 this is the single most important Atlas configuration for AWS work, because the managed AWS MCP Server plus a shell means the agent could otherwise run an aws CLI command on its own judgment.
Atlas has a bash tool, and the AWS CLI is on your PATH. That combination is powerful and needs a guardrail. Setting 'aws *' to ask under permission.bash means every aws invocation Atlas wants to make stops and waits for you to approve it. Reads through the managed AWS MCP Server stay fluid, which is where most of the value is, while anything that would change an account becomes a deliberate decision. Pair this with the diff review on your IAM policy files and Atlas never touches a live AWS account without you having said yes to the exact command.
Setup
- 01Attach the AWSMCPSignInOAuthAccessPolicy IAM policy to your principal, because the OAuth flow for the managed AWS MCP Server requires it.
- 02Point Atlas at the managed AWS MCP Server with atlas mcp add aws --url https://aws-mcp.us-east-1.api.aws/mcp then run atlas mcp auth aws
- 03If you are in Europe, use the regional endpoint https://aws-mcp.eu-central-1.api.aws/mcp instead of the us-east-1 URL.
- 04For SigV4 instead of OAuth, bridge over stdio: atlas mcp add aws --env AWS_PROFILE=$AWS_PROFILE --env AWS_REGION=us-east-1 -- uvx mcp-proxy-for-aws https://aws-mcp.us-east-1.api.aws/mcp
- 05Remove any older aws-api-mcp-server or aws-knowledge-mcp-server entries, since AWS says to replace them with the managed server.
- 06Set 'aws *' to ask under permission.bash so nothing mutates an account without an explicit approval.
- 07Ask Atlas to describe the Lambda's configuration, read its CloudWatch errors, and fix the IAM statement being denied.
Frequently asked questions
- how to connect atlas to the aws mcp server
- Run atlas mcp add aws --url https://aws-mcp.us-east-1.api.aws/mcp then atlas mcp auth aws. Attach the AWSMCPSignInOAuthAccessPolicy IAM policy to your principal before authenticating.
- aws mcp oauth not working what iam policy do i need
- OAuth requires the AWSMCPSignInOAuthAccessPolicy IAM policy on your principal. Without it attached, atlas mcp auth aws cannot complete the handshake.
- how to use sigv4 instead of oauth with the aws mcp server
- Bridge over stdio: atlas mcp add aws --env AWS_PROFILE=$AWS_PROFILE --env AWS_REGION=us-east-1 -- uvx mcp-proxy-for-aws https://aws-mcp.us-east-1.api.aws/mcp
- is there an eu region endpoint for the aws mcp server
- Yes. eu-central-1 has its own endpoint at https://aws-mcp.eu-central-1.api.aws/mcp. Use it instead of the us-east-1 URL if that is your region.
- should i still use aws-api-mcp-server with atlas
- No. Remove any older aws-api-mcp-server or aws-knowledge-mcp-server entries. AWS says to replace them with the managed AWS MCP Server.
- can atlas read cloudwatch logs and fix iam permissions
- Yes. Ask Atlas to describe the Lambda's configuration, read its CloudWatch errors, and fix the IAM statement being denied. All three come through the managed AWS MCP Server.
- how do i stop atlas from changing my aws account
- Set 'aws *' to ask under permission.bash. Every aws command Atlas wants to run then stops for an explicit approval before it executes.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Grok 4.20 (Non-Reasoning) in 2026: Fast, Predictable Edit Passes
Grok 4.20 (Non-Reasoning) bills no thinking tokens, so cost per turn is fully predictable at $1.25 / $2.5 per Mtok, with the same 1,000,000 token context as the reasoning variant.
Atlas with Llama 3.3 70B Instruct (Meta Llama API) in 2026
Llama 3.3 70B Instruct (Meta Llama API) in Atlas for 2026: 128,000 tokens of context, an OpenAI-compatible endpoint, and a 4,096 token output ceiling to plan around.
Atlas with GPT-5 Mini: Full 400K Context at One Fifth the Price in 2026
GPT-5 Mini in Atlas: $0.25 per Mtok input and $2 per Mtok output, 5x cheaper than GPT-5 on both sides, with no reduction to the 400K context window.
Atlas with Gemini 3.1 Pro: Setup, Cost, and Tradeoffs in 2026
Run Atlas on Gemini 3.1 Pro in 2026: a 1,048,576 token window at $2 / $12 per Mtok, with real setup steps, the 65,536 output ceiling, and when to switch models.
Atlas for Go in 2026
Atlas, the terminal-native AI coding agent, empowers Go developers in 2026 with intelligent code understanding, safe refactoring, and robust testing capabilities.
Atlas with Llama 3.1 70B (local via Ollama): A 43GB Private Agent in 2026
Llama 3.1 70B (local via Ollama) in Atlas for 2026: a 43GB pull for a 48GB GPU or 64GB Mac, Free (self-hosted), with 128,000 tokens of context on your own hardware.
Atlas vs OpenHands: Terminal AI Coding Agents in 2026
Atlas and OpenHands comparison for 2026. Explore terminal-native TUI, self-hosting, code indexing, change review, and pricing models for AI coding agents.
Atlas vs Magic.dev: Terminal AI Coding Agents in 2026
Compare Atlas, the terminal-native AI coding agent with permission-gated tools and diff review, against Magic.dev's research claims of 100 million token context models in 2026.