Skip to main content
hc
Submit
rulesSource-backedReview first Safety ✓ Privacy ✓

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·
Claude Code
HarnessClaude Code
Review first — review before installing

Open the source and read safety notes before installing.

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
## 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

## References

- MCP authorization specification - https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
- OAuth 2.0 Resource Indicators - https://www.rfc-editor.org/rfc/rfc8707
- OAuth 2.0 Protected Resource Metadata - https://www.rfc-editor.org/rfc/rfc9728

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

References

#mcp#oauth#authorization#protected-resources#security

Source citations

Signals

Loading live community signals…

More like this, weekly

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