A remote MCP server can expose tools backed by user accounts, tenant data, third-party APIs, or write-capable integrations., Block approval when a server accepts wrong-audience tokens, forwards incoming tokens, or cannot show protected resource metadata.
Privacy notes
OAuth metadata, redirect URLs, scopes, tenant IDs, token claims, and tool results may contain private account structure., Public reports should summarize authorization behavior without pasting tokens, claims, or internal identity-provider details.
Author
JSONbored
Submitted by
JSONbored
Claim status
unclaimed
Last verified
2026-06-05
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
63
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Needs review
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
No reviewed flag detected in metadata.
Pending
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
3 prerequisites to line up before setup. Have accounts and credentials ready first.
0/3 ready
Account & credentials2Permissions & scopes1
Safety & privacy surface
Safety & privacy surface
2 safety and 2 privacy notes across 2 risk areas. Review closely: credentials & tokens, network access.
2 areas
SafetyNetwork accessA remote MCP server can expose tools backed by user accounts, tenant data, third-party APIs, or write-capable integrations.
SafetyCredentials & tokensBlock approval when a server accepts wrong-audience tokens, forwards incoming tokens, or cannot show protected resource metadata.
PrivacyCredentials & tokensOAuth metadata, redirect URLs, scopes, tenant IDs, token claims, and tool results may contain private account structure.
PrivacyCredentials & tokensPublic reports should summarize authorization behavior without pasting tokens, claims, or internal identity-provider details.
Safety notes
A remote MCP server can expose tools backed by user accounts, tenant data, third-party APIs, or write-capable integrations.
Block approval when a server accepts wrong-audience tokens, forwards incoming tokens, or cannot show protected resource metadata.
Privacy notes
OAuth metadata, redirect URLs, scopes, tenant IDs, token claims, and tool results may contain private account structure.
Public reports should summarize authorization behavior without pasting tokens, claims, or internal identity-provider details.
Prerequisites
Remote MCP server URL, intended client, and expected authorization model.
Access to metadata responses, staging token-flow evidence, and scope documentation.
Permission to review private token claims only in a controlled environment.
You are an MCP Authorization Boundary Review Agent.
Review the remote MCP server against the official MCP authorization
specification, OAuth resource indicators, and protected resource metadata.
Workflow:
1. Identify the MCP server canonical resource URI and transport.
2. Confirm protected resource metadata discovery and authorization server metadata.
3. Verify that authorization and token requests include the intended resource.
4. Check token audience validation and wrong-audience rejection.
5. Look for token passthrough to downstream APIs.
6. Review scopes, redirect behavior, dynamic client registration, and error handling.
7. Separate public-safe findings from private token or tenant evidence.
Output:
- Boundary summary
- Evidence reviewed
- Release blockers
- Non-blocking improvements
- Privacy notes
- Decision: safe, safe with limits, or block
About this resource
Content
This agent is meant for reviewers who need to decide whether a remote MCP server
is safe to connect to a real account. It focuses on the authorization boundary,
not the product pitch. A server that can log in successfully can still be unsafe
if it accepts tokens for the wrong audience, omits protected resource metadata,
or forwards a user token to another API.
Review checklist
Protected resource metadata exists and points to the expected authorization server.
The client uses the MCP server URI as the OAuth resource indicator.
Wrong-audience tokens are rejected.
Incoming bearer tokens are not forwarded to downstream APIs.
Scopes are documented and can be restricted for read-only use.
401 and 403 errors do not leak tokens or private claims.
Public findings avoid raw token, tenant, and identity-provider evidence.
Show that MCP Authorization Boundary Review Agent is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/agents/mcp-authorization-boundary-review-agent)
How it compares
MCP Authorization Boundary Review Agent side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
✓A remote MCP server can expose tools backed by user accounts, tenant data, third-party APIs, or write-capable integrations.
Block approval when a server accepts wrong-audience tokens, forwards incoming tokens, or cannot show protected resource metadata.
✓This collection is a review workflow, not a guarantee that a remote MCP server is safe to connect to production accounts.
Run write-capable, billing-capable, or deletion-capable MCP tools only in sandboxed accounts until scopes and confirmations are reviewed.
Keep dynamic server inspection separate from source review; both can miss different failure modes.
✓Never send a production user token to an MCP server until the resource metadata and token audience have been verified.
Treat token passthrough, missing resource indicators, or acceptance of tokens issued for another resource as release-blocking.
Do not paste bearer tokens into prompts, PR comments, issue comments, screenshots, or public logs while debugging MCP auth.
✓These rules do not execute the MCP server; they define review requirements before a server is connected to a real account.
A server that accepts wrong-audience tokens, broad scopes, or forwarded user tokens should not be approved until the boundary is corrected.
Use separate runtime testing before trusting any OAuth-backed tool that can write, delete, bill, publish, or modify account data.
Privacy notes
✓OAuth metadata, redirect URLs, scopes, tenant IDs, token claims, and tool results may contain private account structure.
Public reports should summarize authorization behavior without pasting tokens, claims, or internal identity-provider details.
✓Authorization metadata, issuer URLs, scopes, endpoint domains, tool names, and inspection traces can expose account architecture.
Do not publish tokens, client secrets, refresh tokens, tenant identifiers, private endpoint URLs, or captured tool responses.
✓Authorization metadata can reveal tenant URLs, identity providers, scopes, client registration behavior, and internal endpoint names.
Verification traces may include redirect URLs, state parameters, token claims, account IDs, or workspace identifiers; redact them before public sharing.
✓Authorization metadata, resource identifiers, issuer URLs, scopes, and token-audience notes can reveal account architecture.
Do not paste access tokens, client secrets, refresh tokens, or internal tenant identifiers into public review comments.
Prerequisites
Remote MCP server URL, intended client, and expected authorization model.
Access to metadata responses, staging token-flow evidence, and scope documentation.
Permission to review private token claims only in a controlled environment.
Remote or local MCP server endpoint, transport, authorization mode, and source repository.
Scope map for account-backed tools and a list of write-capable operations.
Test account or sandbox environment for inspection when the server can mutate data.
Remote MCP server URL and expected canonical resource URI.
OAuth authorization server metadata or discovery endpoint.
Test account or staging credentials approved for metadata and token-flow checks.
Ability to inspect HTTP 401 responses, WWW-Authenticate headers, and token request parameters.
Remote MCP server URL, transport type, and authorization server metadata.
Protected resource metadata discovery path for the exact MCP endpoint.
Scope list, token audience expectations, and tool permission map.