MCP Permission Review: A Step-by-Step Playbook for Scopes, Tools and Approvals

An MCP permission review checks what each connected MCP server is allowed to do: the scopes it holds, the tools it exposes and when the AI must ask before acting. It is usually run by IT or security with the owner of each connected system. MCP makes this review different from a normal app review because an AI model, not a person, chooses which tool to call and when.

This playbook complements the MCP access review, which asks who can connect. Here the question is what a connection can do once it exists.

What you need

• The list of approved servers and their owners. If you do not have one yet, start with the approved server list playbook.
• Each server's tool list. Get it from the vendor's docs, the client's connector page, or the MCP Inspector, which can list a server's tools from the command line.
• Client admin access. Claude shows per-connector Tool permissions in Customize > Connectors, per Claude's connector docs. ChatGPT admins set workspace and per-app permissions in the Admin Console, per OpenAI's admin controls article.
• Access to the connected apps' admin consoles to see and change OAuth grants and API key scopes.

The workflow

1. List the scopes. For each server, record the OAuth scopes or API key permissions it holds. The MCP security best practices list common mistakes, including "Publishing all possible scopes" and "Using wildcard or omnibus scopes (*, all, full-access)."
2. Classify every tool. Mark each tool as read, write, send or delete. Use the tool's description and the vendor docs. Treat annotations as hints: the MCP tools specification says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers."
3. Match tools to the job. For each team, list the tools its workflow actually needs. Anything else is a candidate to block.
4. Set Claude tool permissions. On each connector's page, choose Always allow, Needs approval or Blocked for each tool or group of tools. Block unused tools. Use Needs approval for writes.
5. Set ChatGPT permissions. OpenAI's permissions article lists Always ask, Allow read actions, Allow low-risk actions and Allow all actions, and says the last "carries elevated risk." OpenAI adds that the standard workspace-wide selector does not offer Allow all actions. For custom MCP apps, admins can deselect actions with Configure Actions when publishing.
6. Reduce scopes at the source. Where a vendor offers read-only keys, narrower OAuth scopes or per-project access, switch to them. Changing the AI client's settings does not reduce what the token itself can do.
7. Use gateway controls if you have them. Cloudflare's MCP server portals docs say turned-off tools "will not appear in the portal's tool list," and admins can set default_disabled so only listed tools are exposed.
8. Record and schedule. Save the tool classification, settings and scopes with the date. Re-review on any tool change.

A simple starting matrix

This is a sensible default to adjust per team, not a rule from any vendor:

Example prompts

Use these on exported tool lists, not on live admin consoles:

• "Here is the tool list for this server. Classify each tool as read, write, send or delete, and quote the words in its description that led you to that label."
• "Our sales team only needs to look up deals and add notes. From this tool list, which tools should be blocked?"
• "Compare these OAuth scopes with the tools we kept. Which scopes are not needed by any kept tool?"
• "List every tool set to Always allow that can change data."

Guardrails

• Review settings, do not let the AI change them. An AI can classify and compare. A person changes permissions.
• Avoid approval fatigue. Requiring approval for every read can train people to click yes without looking. Approve reads you trust and keep prompts for writes. See MCP approval fatigue.
• Mind the spec's intent. The tools specification says clients should "Prompt for user confirmation on sensitive operations" and show tool inputs before calling the server.
• Know the risk. OWASP's MCP Top 10 lists "Privilege Escalation via Scope Creep" as MCP02. Our page on excessive permissions explains how it happens.

What to measure

• The number of tools per server that are allowed, need approval or are blocked.
• Write, send and delete tools set to run without approval. Aim to justify each one.
• Scopes removed at the source in each review.
• Tool changes detected between reviews.
• Approval prompts denied, from logs, as a sign that tools are being called when they should not be.

Track these per server over time. A growing count of always-allowed write tools is a warning sign.

Next step

For a hands-on lesson on least privilege, see least privilege in the Learn MCP course. If you want an outside review of your scopes and approval settings, start with our MCP readiness audit. More guides are in the MCP playbooks hub.

Frequently asked questions