Skip to main content
rulesSource-backed

MCP Remote Authorization Boundary Rules

Source-backed rules for reviewing remote MCP server authorization boundaries: protected resource metadata, OAuth resource indicators, token audience checks, least-privilege scopes, and cross-server token isolation.

by JSONbored·added 2026-06-05·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization, https://github.com/JSONbored/awesome-claude/blob/main/content/rules/mcp-remote-authorization-boundary-rules.mdx
Safety notes
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
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.
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.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

15 minutes

Adoption plan

Balanced adoption plan

Current risk score 24/100. Use staged verification before broader rollout.

Risk 24

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    No review metadata found; increase manual validation.

    Pending
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Missing required evidence: Metadata review. Risk score 31.

Risk 31

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Missing

Review metadata is missing.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required gaps: Metadata review

Decision timeline

Decision timeline · balanced

Blocking gaps: Check metadata review status. Risk 28.

Risk 28

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is missing.

Pending

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

Blockers: Check metadata review status

Prerequisite readiness

Prerequisite readiness

3 prerequisites to line up before setup. Have accounts and credentials ready first.

0/3 ready
Account & credentials1Configuration1Permissions & scopes115 minutes

Safety & privacy surface

Safety & privacy surface

3 safety and 2 privacy notes across 2 risk areas. Review closely: credentials & tokens.

2 areas
  • SafetyExecution & processesThese rules do not execute the MCP server; they define review requirements before a server is connected to a real account.
  • SafetyCredentials & tokensA server that accepts wrong-audience tokens, broad scopes, or forwarded user tokens should not be approved until the boundary is corrected.
  • SafetyCredentials & tokensUse separate runtime testing before trusting any OAuth-backed tool that can write, delete, bill, publish, or modify account data.
  • PrivacyCredentials & tokensAuthorization metadata, resource identifiers, issuer URLs, scopes, and token-audience notes can reveal account architecture.
  • PrivacyCredentials & tokensDo not paste access tokens, client secrets, refresh tokens, or internal tenant identifiers into public review comments.

Safety notes

  • 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

  • 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, 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.

Schema details

Install type
copy
Troubleshooting
No
Collection metadata
Estimated setup
15 minutes
Difficulty
intermediate
Full copyable content
Remote MCP authorization review rules:
1. Require protected resource metadata discovery for the MCP endpoint.
2. Require an OAuth resource indicator tied to the exact MCP resource.
3. Reject tokens accepted for the wrong audience or another MCP server.
4. Verify scopes are narrow enough for the advertised tools.
5. Block forwarding incoming user tokens across MCP servers or backend services.
6. Document revocation, refresh, storage, and user consent behavior.
7. Keep source evidence public and credential details private.

About this resource

Purpose

Remote MCP servers can expose account-scoped tools over HTTP transports. These rules keep review focused on the authorization boundary before the server is added to Claude or another MCP client. The goal is not to certify the whole service. The goal is to prevent obvious mistakes: wrong-audience tokens, missing protected resource metadata, broad scopes, unclear token forwarding, and unsafe account writes.

Required Evidence

Collect these items before approving the server.

  1. MCP resource URL and transport.
  2. Protected resource metadata URL or discovery path.
  3. Authorization server metadata and issuer.
  4. Required OAuth scopes and their mapped MCP tools.
  5. Expected resource indicator or audience value.
  6. Token storage, refresh, revocation, and logout behavior.
  7. Public source or documentation supporting the implementation.

If the contributor cannot provide the resource metadata, authorization server, scope map, or public source evidence, mark the submission as incomplete.

Blocking Rules

  • Reject a remote MCP server that accepts a token minted for another resource.
  • Reject a server that requires broad account scopes when narrower scopes exist.
  • Reject forwarding incoming user tokens across MCP servers or backend services; documentation of a trust boundary is not a substitute for token isolation.
  • Reject documentation that says "OAuth supported" without showing issuer, resource, scopes, and consent behavior.
  • Reject tools that can write account data without explicit safety and privacy notes.
  • Reject client setup instructions that ask users to paste tokens into public files, screenshots, transcripts, or PR comments.

Review Output

Return a concise decision with:

  • resource metadata status
  • authorization server status
  • resource indicator or audience status
  • scope-to-tool mapping status
  • token handling status
  • blocking gaps
  • safe public wording for any limitations

Authorization Error Status Codes

The specification requires servers to return appropriate HTTP status codes for authorization errors. Confirm the server maps these correctly during review.

Status Code Description Usage
401 Unauthorized Authorization required or token invalid
403 Forbidden Invalid scopes or insufficient permissions
400 Bad Request Malformed authorization request

A request without a token, or with an invalid or expired token, must receive an HTTP 401 with a WWW-Authenticate header pointing to the resource metadata URL. An authenticated request carries the token in the Authorization header, never in the URI query string:

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

References

Source citations

Add this badge to your README

Show that MCP Remote Authorization Boundary Rules is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/rules/mcp-remote-authorization-boundary-rules.svg)](https://heyclau.de/entry/rules/mcp-remote-authorization-boundary-rules)

How it compares

MCP Remote Authorization Boundary Rules side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Next steps differ across entries — use the actions in the table below to copy install commands and source links per resource.

Field

Source-backed rules for reviewing remote MCP server authorization boundaries: protected resource metadata, OAuth resource indicators, token audience checks, least-privilege scopes, and cross-server token isolation.

Open dossier

Practical guide for checking MCP protected resource metadata, authorization server discovery, resource indicators, token audience binding, and 401 challenge behavior before trusting a remote MCP server.

Open dossier

Source-backed collection for reviewing OAuth-backed and remote MCP servers: protected resource metadata, token audience checks, least-privilege scopes, config privacy, local tool access, and interactive server inspection.

Open dossier

Slash command for auditing a remote MCP server authorization setup, including protected resource metadata, authorization server discovery, OAuth resource indicators, token audience validation, scopes, and token passthrough risk.

Open dossier
Next stepsDiffers
Trust
Review statusNot reviewedNot reviewedNot reviewedNot reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
SubmitterJSONboredJSONboredJSONboredJSONbored
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
Brand
Categoryrulesguidescollectionscommands
SourceSource-backedSource-backedSource-backedSource-backed
AuthorJSONboredJSONboredJSONboredJSONbored
Added2026-06-052026-06-052026-06-052026-06-05
Platforms
Harness
Source repo
Safety notesThese 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.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.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.The command may ask the assistant to inspect authentication metadata and token-flow evidence; do not paste production bearer tokens into the prompt. Treat missing resource metadata, wrong-audience token acceptance, or token passthrough as blocking findings.
Privacy notesAuthorization 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.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, 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.Metadata and audit output can expose identity providers, scopes, tenant identifiers, redirect URLs, and private server URLs. Redact token claims and account identifiers before sharing command output publicly.
Prerequisites
  • 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.
  • 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 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.
  • Approved staging credentials or metadata-only access for authorization review.
  • Permission to inspect HTTP responses, authorization metadata, and token-flow evidence.
Install
/mcp-auth-audit <server-url>
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.