Connect the AWS MCP Server

AWS hosts a managed AWS Server that gives access to AWS APIs across thousands of operations, authorized through AWS Sign-In using the same identities, permissions, and governance model you already use with the AWS Management Console and CLI. This guide covers the Arcade-side setup for connecting it as a remote MCP server, plus the AWS settings that most commonly trip people up.

This guide is about connecting to the AWS Server, not an Arcade toolkit. Arcade doesn’t ship an AWS toolkit today, so this remote server is currently the only way to reach AWS APIs through Arcade. It’s a fixed, AWS-defined set, not something a customer can extend, so that advantage goes away if Arcade ships a native toolkit for it later.

The AWS-side steps below are sourced directly from AWS’s own OAuth documentation for this server.

AWS’s setup is structurally closer to Atlassian than to the other guides in this section: the AWS Server uses OAuth 2.1 with Dynamic Client Registration (DCR), so Arcade registers itself as a client automatically. There’s no manual OAuth app to create and no Client ID/Secret to copy. The administrative work is entirely about which IAM identity authorizes the connection and what that identity is permitted to do, because authorizing an grants it no additional AWS permissions. It acts strictly within the authorizing identity’s existing IAM policies.

Outcomes

Connect the AWS Server to Arcade and use its in gateways and SDKs.

You will Learn

Which IAM permissions the authorizing identity needs, and why access is governed entirely by IAM
Register the remote server in Arcade without manually configuring OAuth credentials
Diagnose the most common setup mistakes from their error messages

Prerequisites

An Arcade
An AWS , and an IAM identity ( or role) you’ll authorize the connection as
Permission to attach an IAM policy to that identity

Set up AWS

Because access runs entirely through the authorizing identity’s IAM permissions, setting up AWS mainly means granting that identity the permissions to complete the OAuth flow.

Grant the authorizing identity the OAuth permissions. Attach the AWS managed policy AWSMCPSignInOAuthAccessPolicy to the IAM or role you’ll sign in as:
PLAINTEXT
```
aws iam attach-role-policy \
  --role-name MyRole \
  --policy-arn arn:aws:iam::aws:policy/AWSMCPSignInOAuthAccessPolicy
```
This grants the two permissions the interactive OAuth flow needs: signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token. (If you authorize as the root , no extra IAM permissions are required, but a scoped role is the better practice.)
Understand what the authorized connection can actually do. These two permissions only let the identity complete the OAuth handshake. They don’t grant any AWS service access. Every tool call the AWS Server makes afterward runs under the authorizing identity’s own IAM policies. Whatever that identity can’t do in the Console or CLI, it can’t do through the either. Scope the authorizing role to exactly the AWS access you intend to have, since that role’s policies are the access-control boundary for everything Arcade does here.
Pick the region deliberately. The AWS Server endpoint and its OAuth resources are region-specific. Use the region where you intend to operate, and keep it consistent between the server URL and the authorizing session.

All OAuth activity (authorization requests, token issuance, introspection, revocation, along with the OAuth client, redirect URI, and originating sign-in session) is recorded in AWS CloudTrail, so administrators can correlate downstream AWS API calls back to the originating authorization. This is worth knowing for audit and incident response.

Configure the remote server in Arcade

Register the server

Go to the MCP servers dashboard , click Add Server, choose Remote , and enter a server ID and the AWS endpoint for your region:

PLAINTEXT


https://aws-mcp.<region>.api.aws/mcp

For example, https://aws-mcp.us-west-2.api.aws/mcp. The region in the URL should match the region of the identity and session you authorize with.

Configure OAuth2 authorization

Open Advanced settings → OAuth2 authorization and leave Client ID, Client Secret, Authorization URL, and Token URL empty. This is the same guidance as Atlassian, and the opposite of the ECA-style providers: the AWS Server supports Dynamic Client Registration, so Arcade registers a client and discovers the authorization server automatically on first connection. There’s nothing to create on the AWS side to populate these fields, and there’s no redirect URI to manually configure on an AWS OAuth app. The redirect URI is matched against AWS’s DCR allowlist, not a per- setting.

Authorize and confirm

Save the server to open the authorization prompt. Sign in through AWS Sign-In as the IAM identity you scoped above and approve the authorization request. AWS Sign-In issues an access token (valid up to one hour, auto-refreshed via a rotating single-use refresh token while your session lasts), and the connection lists the that identity is permitted to reach.

Troubleshooting

“ cannot register as an OAuth client” during connection: Arcade’s redirect URI isn’t on AWS Sign-In’s DCR allowlist for this. Confirm https://cloud.arcade.dev/api/v1/oauth/* appears in AWS’s Supported Redirect URIs table . This is resolved on AWS’s side, not through Arcade configuration.
“Permission denied” when connecting: the authorizing IAM identity is missing signin:AuthorizeOAuth2Access and/or signin:CreateOAuth2Token. Attach AWSMCPSignInOAuthAccessPolicy to that identity.
The connection authorizes, but specific calls fail with access-denied errors: the authorizing identity’s own IAM policies don’t permit that AWS action. This isn’t an or Arcade issue: authorizing the grants no permissions beyond what the identity already has. Broaden the role’s IAM policies (deliberately) or re-authorize as an identity with the needed access.
“Invalid target resource”: the endpoint region or resource is off. Confirm the server URL uses the https://aws-mcp.<region>.api.aws/mcp pattern with a supported region.
Access stops working after about an hour, and doesn’t recover: the refresh token has expired or been revoked. Re-authorize through the AWS Sign-In flow to obtain a fresh token.
You need to immediately cut off an authorized connection: revoking the refresh token stops new access tokens from being issued, but existing access tokens remain valid until they expire (up to an hour). For immediate containment, apply an IAM policy using the aws:SignInSessionArn condition key to deny requests tied to that sign-in session.

Next steps

Create an MCP Gateway to expose this server’s .
Connect to MCP clients.