> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up AWS MCP Server

> Connect AWS's managed MCP Server to the TrueFoundry MCP Gateway using AWS Sign-In OAuth. Covers the non-interactive IAM token flow available today and the status of interactive OAuth.

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**](https://docs.aws.amazon.com/signin/latest/userguide/aws-mcp-server.html), 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.

<Note>
  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](/docs/ai-gateway/mcp/mcp-server-agentcore-sigv4).
</Note>

<Note>
  **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.
</Note>

## Authentication options

The AWS MCP Server accepts [AWS SigV4-signed requests](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html) as well as OAuth tokens from AWS Sign-In, which [supports two authorization models](https://aws.amazon.com/blogs/security/introducing-oauth-support-for-aws-mcp-server/):

| Model | How it works | Status in TrueFoundry |
| - | - | - |
| **AWS SigV4** (gateway-signed) | The Gateway signs every request to the AWS MCP Server with IAM credentials stored on the MCP server. | **Recommended.** The Gateway signs each request with AWS SigV4; no token to mint or refresh. |
| **Non-interactive OAuth** (client credentials + IAM) | Exchanges existing AWS SigV4 credentials for a short-lived OAuth access token. No browser redirect. | **Alternative.** Use when long-lived IAM access keys aren't permitted (e.g. IAM Identity Center–only environments). |
| **Interactive OAuth** (authorization code + PKCE, via DCR) | Agent self-registers via Dynamic Client Registration and redirects the user to AWS Sign-In to authenticate and consent. | **Not yet available.** Requires TrueFoundry to be an AWS-approved DCR client with a whitelisted redirect URI. See [Interactive OAuth](#interactive-oauth-status). |

The rest of this guide uses **AWS SigV4**. For how SigV4 works in the MCP Gateway, see [MCP Gateway authentication](/docs/ai-gateway/mcp/mcp-gateway-auth-security).

## 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](/docs/ai-gateway/mcp/mcp-server-agentcore-sigv4) 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](/docs/ai-gateway/mcp/mcp-server-agentcore-sigv4), 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](https://docs.aws.amazon.com/signin/latest/userguide/oauth-sign-in-overview.html).** 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_uri`s from a **fixed allowlist**. This is a security measure that stops anyone from registering a client with an attacker-controlled callback.

<Warning>
  **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.
</Warning>

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.

<Note>
  **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.
</Note>

## 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](/docs/ai-gateway/mcp/virtual-mcp-server) to expose only the AWS tools you want available to agents.
