Skip to main content
AWS provides a managed AWS MCP Server at https://aws-mcp.<region>.api.aws/mcp, letting agents query and act on AWS using your existing AWS identities, permissions, and governance model. Authorization is handled by AWS Sign-In, which acts as the OAuth authorization server on top of your underlying AWS identity context (including IAM Identity Center and any federated IdP such as Microsoft Entra ID). Authorizing an agent does not grant it additional AWS permissions: every request is still evaluated against your IAM policies, SCPs, RCPs, and permission boundaries. This guide shows how to connect the AWS MCP Server to the TrueFoundry MCP Gateway.
This page covers the general AWS MCP Server. To connect an MCP server hosted on Amazon Bedrock AgentCore, see Register an AWS Bedrock AgentCore MCP Server.
Native support is coming. AWS MCP Server will soon be available as a TrueFoundry-managed MCP server, which will remove the manual token handling described below. TrueFoundry is already in active contact with AWS on first-class OAuth integration. Until that ships, use the non-interactive setup on this page.

​
Authentication options

The AWS MCP Server accepts AWS SigV4-signed requests as well as OAuth tokens from AWS Sign-In, which supports two authorization models: The rest of this guide uses AWS SigV4. For how SigV4 works in the MCP Gateway, see MCP Gateway authentication.

​
Prerequisites

  • An AWS account with the AWS MCP Server enabled in your region (for example, eu-central-1).
  • AWS credentials for the Gateway to sign with: an IAM access key or an IAM role the Gateway can assume. See Configure AWS credentials in the AgentCore SigV4 guide.
  • The MCP Server Manager role in TrueFoundry.

​
Grant IAM permissions

Attach an IAM policy granting the AWS MCP service actions to the IAM principal the Gateway signs as.

​
Register AWS MCP Server in TrueFoundry

Open MCP Gateway, click Add MCP Server, select Connect any Remote MCP Server, and set:
  • URL to https://aws-mcp.<region>.api.aws/mcp. Unlike AgentCore, no ARN encoding is needed.
  • Authentication to AWS SigV4, with AWS Region set to the same region as the URL.
  • Credential Type and credentials as described in Register the remote MCP server in TrueFoundry, which also has the equivalent YAML manifest.

​
Add collaborators and save

Assign the MCP Server Manager role to administrators and MCP Server User to consumers, then save the server.

​
Verify the connection

Open the server’s Tools section and confirm tool discovery succeeds and a test call returns. On the AWS side, you can confirm tokens are being issued by checking CloudTrail for CreateOAuth2Token events.

​
Interactive OAuth (status)

Many remote MCP servers in TrueFoundry are registered with the OAuth2 → Authorization Code flow, where TrueFoundry redirects the user to the provider to authenticate and consent. This flow is not yet available for the AWS MCP Server, for reasons specific to how AWS Sign-In works:
  • OAuth is discovery- and DCR-based. There is no issuer URL, scope list, or client ID that you provision by hand. A compliant client discovers the AWS Sign-In OAuth metadata (RFC 8414) and the MCP server’s protected-resource metadata (RFC 9728), then registers via Dynamic Client Registration (RFC 7591), at which point AWS Sign-In issues the client_id.

​
Approval-gated DCR

By default the MCP Gateway completes Dynamic Client Registration (DCR) for you. It registers itself as an OAuth client at runtime, so no manual OAuth app is needed. AWS gates this. It only lets approved agents register through DCR, and only accepts redirect_uris from a fixed allowlist. This is a security measure that stops anyone from registering a client with an attacker-controlled callback.
AWS DCR doesn’t work end-to-end yet. TrueFoundry’s callback URL (https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback) isn’t on AWS’s approved redirect-URI list. AWS rejects the callback before returning an authorization code, so the authorization-code flow can’t complete.
This isn’t a misconfiguration, and resetting tokens or reconnecting won’t fix it. There is no client ID or redirect URI you can configure on either side to make it work. AWS has to add TrueFoundry’s callback URL to its approved redirect-URI list and approve TrueFoundry as a registering agent; once that happens, the flow completes normally.
We’re working on it. TrueFoundry is already engaged with AWS to be registered as an approved MCP OAuth client (with our redirect URI whitelisted) and to offer AWS MCP Server as a TrueFoundry-managed MCP server. When that lands, per-user interactive OAuth and automatic token management will be supported out of the box, and this page will be updated.

​
Security notes

  • Both SigV4 and non-interactive OAuth are app-to-app: the Gateway signs or acts as a single IAM principal, so AWS sees that principal rather than the individual user. Per-user identity at the AWS end still requires interactive OAuth. All calls remain subject to your IAM policies, SCPs, and permission boundaries.
  • Store the IAM access key (or the token-minting identity’s credentials) securely and rotate them per your organization’s policy.
  • To immediately contain a compromised session, apply an IAM policy using the aws:SignInSessionArn global condition key to deny requests from the affected sign-in session. Revoking access takes effect for new tokens immediately; already-issued access tokens remain valid until they expire (up to one hour).
  • Use a Virtual MCP Server to expose only the AWS tools you want available to agents.