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 the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
63
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
No reviewed flag detected in metadata.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 24/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
No review metadata found; increase manual validation.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Missing required evidence: Metadata review. Risk score 31.
Source repository/provenance is listed.
Required in this preset
Review metadata is missing.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required gaps: Metadata review
Decision timeline
Blocking gaps: Check metadata review status. Risk 28.
triage
Source/provenance metadata is available.
triage
Review metadata is missing.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
Blockers: Check metadata review status
Prerequisite readiness
3 prerequisites to line up before setup. Have accounts and credentials ready first.
Safety & privacy surface
3 safety and 2 privacy notes across 4 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
## What this collection covers
This stack gives maintainers and AI coding agents a repeatable path for MCP
authorization review. It combines source-backed guides, a review agent, an audit
command, local access rules, hardening guidance, and an official inspection tool.
The collection is intentionally review-first. It does not say a server is safe
because it has OAuth. It asks whether the OAuth boundary is specific, narrow,
discoverable, and aligned with the MCP tools exposed to the user.
## Review order
1. Use the protected resource metadata guide to identify the MCP resource,
authorization server, and advertised metadata.
2. Apply the token audience checklist to confirm tokens are minted for the
expected MCP resource and not reused across unrelated services.
3. Ask the authorization boundary review agent for a concise accept, close, or
manual-review recommendation.
4. Run the MCP auth audit command against source, docs, and config snippets.
5. Apply local tool access rules to decide whether file, shell, browser, or
credential behavior is acceptable.
6. Use MCP server security hardening guidance for runtime isolation and least
privilege.
7. Inspect the server with MCP Inspector only in a sandboxed environment when
dynamic behavior needs confirmation.
## Good fit
- Remote MCP servers with OAuth-backed account access.
- Local MCP servers that proxy to third-party APIs.
- Tool surfaces that include write, publish, delete, billing, or admin actions.
- Review workflows where public source evidence and private credential details
need to stay separate.
## Not enough by itself
- Malware scanning, dependency review, or binary/package trust.
- Legal review of third-party data-processing terms.
- Production incident response for an already-connected MCP server.
- Approval of broad account scopes without sandbox testing.
## 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/rfc9728This stack gives maintainers and AI coding agents a repeatable path for MCP authorization review. It combines source-backed guides, a review agent, an audit command, local access rules, hardening guidance, and an official inspection tool.
The collection is intentionally review-first. It does not say a server is safe because it has OAuth. It asks whether the OAuth boundary is specific, narrow, discoverable, and aligned with the MCP tools exposed to the user.
Show that MCP Authorization Review Stack is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/collections/mcp-authorization-review-stack)MCP Authorization Review Stack 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 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 | 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 | 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 | 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 |
|---|---|---|---|---|
| Next stepsDiffers | ||||
| Trust | ||||
| Review status | Not reviewed | Not reviewed | Not reviewed | Not reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | JSONbored | JSONbored | JSONbored | JSONbored |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | — | — | — | — |
| Category | collections | guides | commands | rules |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | JSONbored | JSONbored | JSONbored | JSONbored |
| Added | 2026-06-05 | 2026-06-05 | 2026-06-05 | 2026-06-05 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓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. | ✓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. | ✓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, 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. | ✓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. | ✓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 |
|
|
|
|
| Install | — | — | | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Source-backed guides for putting this to work.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.