Lesson 10: Permissions and Approvals

In this lesson you will:

• Learn what the MCP specification expects from apps when a tool is about to run.
• See the approval and permission controls documented by Claude, Claude Code, Cursor and VS Code.
• Write a simple allow, ask and deny policy for one server.

Connecting a server gives the AI new abilities. Permissions decide which of those abilities run on their own, which need your click, and which never run. Getting this right is how you keep a useful assistant from taking an action you did not want.

1. What the spec requires

The MCP specification (2026-07-28) lists three trust principles. Under user consent and control, users must "explicitly consent to and understand all data access and operations." Under tool safety, "hosts must obtain explicit user consent before invoking any tool."

The tools page adds practical detail. It says there SHOULD always be a human in the loop with the ability to deny tool invocations. It also says clients SHOULD:

• Prompt for user confirmation on sensitive operations
• Show tool inputs to the user before calling the server
• Log tool usage for audit purposes

The spec also admits a limit. MCP "cannot enforce these security principles at the protocol level." The apps you use are responsible for approvals. That is why the rest of this lesson is app by app.

2. Approvals in Claude (web and desktop)

Anthropic's custom connector guide says Claude can call a connector's tools to read, create, modify or delete data. It gives three rules:

• Review tool approval requests carefully.
• Use "Allow always" only for servers and tools you trust to run unsupervised.
• Disable irrelevant or unwanted tools in the "Search and tools" menu.

One detail is easy to miss. The same guide says Research can call connector tools without further approval. It advises disabling write-capable tools and watching request volume.

3. Approvals in Claude Code

Claude Code uses written permission rules. Its permissions docs give this syntax for MCP tools:

Rules are evaluated in this order: deny, then ask, then allow. A matching deny rule wins even if a narrower allow rule also matches. Allow globs only work after a literal mcp__<server>__ prefix, so an allow rule of mcp__* approves nothing.

Claude Code also has permission modes. They range from default, which prompts on first use of each tool, to bypassPermissions, which skips most prompts. Pick a mode deliberately.

Shared project servers get an extra check. The Claude Code MCP docs say it prompts for approval before using project-scoped servers from .mcp.json files in interactive sessions. You can reset those choices with claude mcp reset-project-choices.

4. Approvals in Cursor and VS Code

Cursor's MCP docs say Cursor asks you before using an MCP tool by default. You can expand the prompt to see the arguments. The docs say "MCP follows the same Run Modes as terminal commands." In Auto-review mode, allowlisted MCP tools run immediately and other calls go through a classifier.

The VS Code MCP docs are short on this point. They say to review startup, sign-in and tool approval requests and to "Approve only actions you understand." You can expand a tool call in the conversation to see which server it came from and what it returned.

Apps change often. Check your app's current docs, as of October 2026, before you rely on any setting. Our guide to AI apps that support MCP links each vendor's page.

5. Keep sign-in scopes small

Approvals control each call. Scopes control what a server can reach at all. When a remote server asks you to sign in, its consent screen lists the scopes it wants.

The spec's Security Best Practices page recommends a progressive, least-privilege model. Start with a minimal scope for low-risk read operations. Add higher privileges only when a task first needs them. It lists wildcard scopes such as * or full-access as a common mistake. Read excessive permissions in MCP servers for examples.

6. Avoid approval fatigue

If every call needs a click, people stop reading the prompts. They approve by habit, which defeats the point. Read more in approval fatigue.

A three-tier policy keeps prompts meaningful:

Base each tier on what the tool really does, not only on its annotations. Lesson 9, read a server before you trust it, explains why annotations are hints.

Try it

Pick one server you use, or imagine a GitHub server in Claude Code. Write a three-tier policy for it.

1. List the server's tools. In Claude Code, run /mcp and select the server.
2. Sort each tool into allow, ask or deny.
3. Translate the list into rules.

A sample answer for a GitHub server named github, using the Claude Code rule syntax. The tool names here are illustrative; use the names your server actually lists.

{
  "permissions": {
    "allow": ["mcp__github__get_*", "mcp__github__list_*"],
    "ask": ["mcp__github__create_*", "mcp__github__update_*"],
    "deny": ["mcp__github__delete_*"]
  }
}

Because deny is checked first, the delete rule wins even if someone later adds a broad allow rule. In Claude or Cursor, apply the same tiers through each app's tool toggles and approval prompts.

Recap

The MCP spec expects apps to get your consent before a tool runs and to keep a human able to say no. Each app implements this differently, so learn its controls. Sort tools into allow, ask and deny tiers, and keep sign-in scopes small. Fewer, clearer prompts protect you better than a stream of clicks. Lesson 11 takes this policy to a whole team.

Course navigation

Previous lesson: Lesson 9: Read a Server Before You Trust It.

Next lesson: Lesson 11: Rolling MCP Out to a Team.

Back to the Learn MCP course outline.

Frequently asked questions