Why MCP Tools Disappear: Editor Modes and Permission Gates

June 23, 2026 · AI Agent Internals: How Coding Agents Really Work (part 6)

▶ Watch on YouTube & subscribe to The Stack Underflow

You configured an MCP server, it worked yesterday, and today — same editor, same server, same model — it does nothing. The instinct is to blame the server. Restart it, re-read the docs, file a GitHub issue. Nine times out of ten, that is all wasted effort. The server is fine. What changed is which mode your editor is currently in, and that mode has a gate that decides which capabilities are even allowed to fire.

This is the finale of playlist two (“How Claude Actually Works”). It ties together tool calls, the MCP protocol, agent loops, and MCP apps into a single mental model: same tools, different gates.

The one-sentence version: Your MCP tools did not break — the editor mode you are in has a gate that prevents them from firing, and that gate is a deliberate design philosophy, not a bug.

The Three Modes Most AI Editors Ship With

Most AI-powered editors do not have one unified execution context. They expose three distinct permission levels inside the same product:

ModeCan Read CodeCan Edit FilesCan Run TerminalCan Call MCP Tools
AskYesNoNoNo
EditYesYes (with approval)NoNo
AgentYesYesYesYes

Ask mode is read-only. The model can look at your codebase, answer questions, and explain things — but almost every gate is closed. No edits, no terminal, no MCP tools.

Edit mode opens one more door. The model can propose file changes, but you must approve every diff individually. Terminal access is still off, and so are MCP tools.

Agent mode is where the gates open fully. Read, write, run terminal commands, call MCP tools — all of it is live. This is exactly why your GitHub MCP tool or your database MCP server “vanishes” when you drop back into Ask or Edit mode. The tool is still registered. The server is still running. The capability just is not permitted in that context.

Ask mode:   [READ] [    ] [      ] [    ]  <- almost everything gated
Edit mode:  [READ] [EDIT] [      ] [    ]  <- one more door open
Agent mode: [READ] [EDIT] [TERM  ] [MCP ]  <- all gates open

The moment you switch back to Agent mode, your MCP tools reappear. Nothing broke.

Why Different Editors Gate Differently

Here is where it gets interesting. The MCP protocol itself is universal — the same spec, the same tool definitions, the same JSON-RPC wire format — but editors make completely different choices about where to draw the permission line. That choice reveals each editor’s core philosophy.

VS Code: opt-in power. MCP tools are locked to Agent mode. You have to consciously switch into that mode to get access. The default is maximum safety, and you escalate deliberately. Good for teams where most work should not involve autonomous tool calls.

Cursor: power by default. MCP tools are exposed in all modes. The model decides when to invoke them. There is less friction, but you are placing more trust in the model’s judgment about when a tool call is appropriate.

Claude Code: supervised power. Tools are available broadly, but the agent must show you its plan before it executes. The gate is not the mode — it is the plan approval step. You get agent-level capability with an explicit review checkpoint before anything runs.

VS Code:    SAFE ←—[gate at mode switch]—→ POWER
Cursor:     SAFE ←—[gate at model judgment]—→ POWER
Claude Code: SAFE ←—[gate at plan approval]—→ POWER

Same underlying MCP layer. Three completely different answers to the question “at what point does a human need to confirm intent?”

Choosing the Right Tool for Your Workflow

The question to ask when picking a coding agent is not “which AI is smarter?” The model capabilities — and the MCP tooling available — are largely the same across editors. The real question is:

Where does this editor place the gate?

That single design decision determines what your day-to-day workflow actually feels like:

  • If you want to stay in control of every step, a mode-gated approach (VS Code-style) means you never accidentally invoke agent-level tools.
  • If you want maximum flow and minimal interruptions, always-on tools (Cursor-style) let the model handle more without switching contexts.
  • If you want power but with a natural review checkpoint before things run, plan-first approval (Claude Code-style) sits in the middle.

None of these is objectively correct. They represent different trade-offs between safety, trust, and friction.

The Full Mental Model from This Playlist

Six episodes, one mental model:

  1. Tool calls are text the model emits — structured JSON that the runtime intercepts and executes.
  2. MCP is the universal protocol that standardizes how tools are defined and called across any editor or runtime.
  3. Agent loops run when a single tool call is not enough — the model calls tools, reads results, and keeps going until the task is done.
  4. MCP apps return interfaces, not just data — the server decides what the client gets to see and do.
  5. Modes decide when any of it is allowed to fire.

The gate is not a limitation of the protocol. The gate is the philosophy.

Common Misconceptions

  • “My MCP server crashed.” This is the default assumption when tools stop responding, but it is almost always wrong. The server is running fine; you are in a mode that does not permit MCP calls. Check the mode first, then the server.
  • “Agent mode is always more dangerous.” Agent mode has more capability, but editors like Claude Code add a plan approval checkpoint that gives you supervision without forcing you into a lower-capability mode.
  • “The MCP protocol is editor-specific.” It is not. MCP is an open protocol. The gating of when MCP tools can fire is an editor-level decision layered on top of the universal protocol.
  • “A more powerful AI model will unlock my tools.” Swapping models does not change which modes expose MCP access. That is an editor configuration decision, not a model capability.

Frequently Asked Questions

Why do some editors hide MCP tools in certain modes instead of just showing them grayed out? It is a UX and safety choice. Showing the tool but disabling it could encourage users to think the tool should work and prompt them to debug it. Hiding it entirely reflects the mode’s actual capability surface — the tool genuinely does not exist in that context.

Can I configure VS Code to expose MCP tools outside of Agent mode? As of this writing, VS Code gates MCP to Agent mode by design. That is the intended behavior, not a config gap. If you need MCP tools without full agent permissions, Cursor or Claude Code may be a better fit for your workflow.

If MCP is universal, can I use the same MCP server across VS Code, Cursor, and Claude Code? Yes. A well-written MCP server is editor-agnostic. You point all three editors at the same server (usually via a config file specifying the server command), and they all connect using the same protocol. The difference is only in when each editor permits your code to call it.

Does switching modes mid-conversation reset the context? This depends on the editor, but generally the conversation context (the chat history) is preserved when you switch modes. What changes is the set of tools the model is allowed to invoke going forward. You do not lose your conversation; you just open or close capability gates.

Where This Fits in the Series

This episode is the finale of the “How Claude Actually Works” playlist — the second playlist in the AI Agent Internals: How Coding Agents Really Work course on The Stack Underflow. It closes the loop on the core execution model: tool calls, MCP, agent loops, and the mode-based gating that controls when all of it fires. The next playlist digs into the hidden costs of AI coding — tokens, context windows, and the limits that shape every decision the agent makes. Browse all tutorials to see where things are headed.

Found this useful? The deep version lives on YouTube — new breakdowns of how AI dev tools actually work, weekly.

Subscribe on YouTube →