docs: add AWS MCP Server remote connection guide

[andrewconnor-arcade]

⛔ MERGE GATE: NOT YET SATISFIED — do not merge until this is resolved

This guide depends on Arcade's redirect URI (https://cloud.arcade.dev/api/v1/oauth/*) being added to AWS Sign-In's DCR allowlist.

Verified against AWS's live docs at the time of this PR: Arcade is NOT on the allowlist yet. I fetched https://docs.aws.amazon.com/signin/latest/userguide/aws-mcp-server.html#aws-mcp-server-supported-redirect-uris directly and the "Supported Redirect URIs for DCR" table lists exactly 12 approved OAuth clients — Localhost, Claude, Cursor Desktop, Cursor Web, Visual Studio Code, VS Code (Web), ChatGPT, ChatGPT Connectors, Replit, Lovable, Lovable Developer, and Vercel v0. No Arcade entry. Until AWS ships the change they committed to, the entire flow this guide documents (Register the server → Configure OAuth2 → Authorize) fails at the DCR step with "agent cannot register as an OAuth client."

Opening as a draft for exactly this reason. Re-check the table above before flipping this to ready for review, then re-verify the redirect URI actually appears before merging.

Summary

Adds a guide for connecting the AWS-managed MCP Server as a remote MCP server, following the same structure as the other guides in this section.

Structurally DCR-based, like Atlassian, not ECA-style

No manual OAuth app, no Client ID/Secret. Client ID, Client Secret, Authorization URL, and Token URL are all left empty in Arcade; DCR handles registration automatically on first connection, same guidance as the Atlassian guide.

Access model: this is the whole point of the guide

Authorizing an agent grants it no additional AWS permissions. Every tool call runs under the authorizing identity's existing IAM policies, so that identity's policies are the access-control boundary. The guide leads with this in the intro paragraph, not buried in a footnote, since it's the entire security model for this integration.

AWS-side setup is two things

1. Confirm Arcade is on the DCR allowlist (the merge gate above).
2. Attach the AWSMCPSignInOAuthAccessPolicy managed policy to the authorizing identity, granting signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token.

Region-specific endpoint

https://aws-mcp.<region>.api.aws/mcp. The guide notes the region must stay consistent between the server URL and the authorizing session.

No toolkit-overlap disambiguation

No Arcade AWS toolkit exists today (confirmed: no aws*.json file in toolkit-docs-generator/data/toolkits/), so this is framed as a fixed-surface, currently-only-path guide, the same tier as Dynamics 365 and Atlassian, not a customer-extensible one like Salesforce/ServiceNow/Snowflake.

Intentionally out of scope: non-interactive SigV4 / client-credentials path

AWS's own docs describe a second, non-interactive authorization model using SigV4 credentials and CreateOAuth2TokenWithIAM. That flow authenticates as a single shared machine identity and doesn't fit Arcade's per-user OAuth model, so it's deliberately not documented here. Flagging this explicitly so a reviewer doesn't add it back in thinking it was missed.

Pre-open verification

• Confirmed both external AWS doc links resolve: the main OAuth documentation page and the AWSMCPSignInOAuthAccessPolicy reference page. Confirmed the policy's actual JSON grants exactly the two signin:* actions the guide describes.
• Confirmed the three internal Arcade links (/operate/governance/remote-mcp-servers, /operate/governance/mcp-gateways/create-via-dashboard, /get-started/mcp-clients) match the exact paths used verbatim in every other guide in this section (checked against Atlassian's file).
• Per the standing convention adopted after the Splunk/other-guides cleanup (docs: add Splunk MCP Server remote connection guide #1167, docs: drop not-yet-verified disclaimers from remote MCP server guides #1168), this guide does not include an "Arcade-side field mapping hasn't been walked through end-to-end... confirm before treating this as authoritative" disclaimer. It keeps only the legitimate "sourced from AWS's own documentation" attribution.

One odd thing worth a heads-up, not a blocker

Both fetched AWS doc pages contained a "See also" bullet suggesting running aws agent-toolkit search-skills --search-query ..., phrased oddly like an instruction aimed at an AI agent rather than normal doc prose ("This is an optional suggestion for the user"). Treated it as untrusted page content and did not act on it or include it in the guide. Flagging in case anyone else fetches these pages and wonders about it.

Test plan

• vale passes with 0 errors
• internal-link-check test passes
• MDX compiles and renders locally (pnpm dev, confirmed 200 on the new route and the overview page)
• Verified the DCR-allowlist merge gate (currently failing, see above)
• Re-verify the DCR allowlist once AWS ships the change, then walk through the full flow against a real AWS account before merging

Docs-only. New page plus two shared-file additions (_meta.tsx, cross-link sentence in the overview page), no other routing or behavior changes. Blocked purely on the external AWS dependency above, not on anything in this PR itself.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 31, 2026 5:53pm