Claude Code Effort Levels, MCP Tools, and Why They Interact

1. What Effort Levels Actually Change

Effort level in Claude Code (and the underlying API when exposed) controls how much the model thinks before it answers. The three common levels are low, medium, and high, sometimes with additional tiers. The levels are not different models; they are different budgets of internal reasoning applied by the same model.

At low effort, the model produces an answer with minimal intermediate thought. Fast, cheap, fine for simple questions and trivial edits. It will miss subtle requirements and pick the first approach that comes to mind. For one-line fixes this is usually fine.

At medium effort, the model considers the problem more carefully, plans a little, and checks itself somewhat. This is the sweet spot for most real coding tasks: a multi-file refactor, a feature implementation, a careful debugging pass. Latency is higher, cost is higher, quality is substantially higher than low effort.

At high effort, the model runs a much longer thinking process. It explores alternatives, critiques its own plan, reconsiders. This is where you get the best shot at complex architectural work. It is also where costs jump and latency can become uncomfortable for interactive use.

The practical intuition: pick the level based on how much it matters if the model gets this wrong on the first try. A boilerplate edit can be low. A payment code change is high.

2. Why Medium Is the New Default

Medium defaulting is a reasonable product decision. High is expensive enough that setting it as the default would generate sticker shock for casual users. Low is fast but not good enough for the representative use case. Medium is the best guess at what a general audience wants.

For power users this matters because the default may not match the work you actually do. If your sessions are mostly complex refactors, you want high as your default and are willing to pay for it. If your sessions are mostly tiny tweaks while pairing with the model interactively, low is faster and costs less. Either way, check your default and set it deliberately.

The default also affects perceived quality. Users who remember Claude Code feeling smarter last year might be remembering a version that defaulted differently. "Is the model worse?" is sometimes really "is the default worse?" These are different questions with different fixes.

If you are running Claude Code in a CI or scripted environment, do not rely on the default at all. Set the effort level explicitly in every call. Defaults can and do change without notice.

3. How MCP Tools Change the Picture

MCP (Model Context Protocol) lets Claude Code call out to external tools: a filesystem server, a shell executor, a database query tool, a desktop automation agent. Each tool appears to the model as a callable function with a schema.

Adding MCP tools to a session does not change the effort level, but it does change how effort is spent. At low effort, the model might skip using tools that would help, preferring to guess. At medium and high effort, the model more reliably uses tools when they are available, and will iterate through multi-tool sequences.

More tools in context is not always better. Every connected MCP server adds tool definitions to the context, and those definitions cost tokens. A session with 40 tools defined burns more context per message than a session with 4. The model also has to consider which of the 40 tools to pick, which takes attention. The right move is to connect the tools a given session actually needs, not all tools globally.

Tool-heavy workflows benefit disproportionately from higher effort. A complex task that requires calling a filesystem read, a shell command, a desktop action, then another read, needs the model to plan across tool calls. That planning is exactly what effort levels buy. A low-effort session with many tools is the worst of both worlds: full token cost, shallow reasoning.

When in doubt, bump effort up for tool-heavy sessions. Bump it down for tool-light ones.

4. Effort Levels and Structured Output

Structured output (JSON mode, schemas, typed responses) interacts with effort levels in ways worth understanding. The short version: structured output costs a little quality everywhere, and the cost is more visible at lower effort levels.

At low effort with a strict schema, the model focuses heavily on producing valid JSON and less on producing correct content. You will see fields filled with plausible-looking garbage. This is usually worse than asking for unstructured output and parsing it yourself with a follow-up call.

At medium and high effort, the gap narrows. The model has enough budget to satisfy the schema and still reason about the content. For any workflow that needs structured output, medium is a reasonable floor.

Complex schemas (nested objects, arrays of objects, conditional fields) are especially sensitive to effort level. Keep schemas as flat as the use case allows. A flat schema is easier for the model at any effort level and survives better at low effort.

For tool-use responses (which are themselves structured), the same pattern holds. Low-effort tool calls are more likely to have malformed arguments. Medium and above is more reliable.

5. Pitfalls People Hit

A few recurring mistakes when working with effort levels.

Not setting the level explicitly. Running on the default is fine for casual use, risky for production. Defaults change. Pin the value in scripts and automation.

Using high effort for tasks that do not need it. High costs money and latency. For straightforward tasks, low or medium is genuinely faster and indistinguishable in quality. Save high for the hard work.

Leaving every MCP server connected for every session. Unused tools still eat context and attention. Curate per session.

Expecting low effort to do medium effort work. If low is missing details, raising effort is cheaper and more effective than spending an hour rewriting the prompt.

Comparing effort levels across models. Claude Opus at medium is not the same as Sonnet at medium. The levels are relative to the model. If you switch models, recalibrate.

Using structured output at low effort. Often the biggest culprit when people say "Claude Code is bad at JSON today." Bump effort before you blame the model.

6. MCP Servers That Pair With Desktop Agents

For workflows that reach outside the editor, a small set of MCP servers show up repeatedly in productive setups.

Filesystem. Essential. Lets Claude Code read and write arbitrary files, not just ones you pre-load. Use with care. Scope the root directory so the model cannot read files outside the project.

Shell / command execution. Lets the model run build, test, and utility commands. Pair with a narrow allow-list in production. Permissive shell access is a real security surface.

Git / GitHub. Useful for sessions that involve opening PRs, checking CI status, or browsing issues. Keep the token scoped.

Desktop automation. A desktop agent exposed as an MCP server lets Claude Code reach into macOS apps directly: open an app, click a button, fill a form, take a screenshot. Fazm exposes an MCP interface for exactly this use case. Other tools in the same category also work. The pairing lets Claude Code verify UI changes by actually exercising them, rather than hoping the tests covered the path.

Database. For data work, a direct MCP server to your development database (read-only, please) lets Claude Code run queries inline rather than asking you for table schemas.

Browser. A Playwright or similar MCP server lets Claude Code drive the web for research, scraping, or web-form work. Sometimes overlaps with desktop automation; pick the one that covers your target surface.

The guiding principle for MCP tool selection is the same as for effort levels: deliberate choice per session. Connect the tools the session needs, bump effort if the session is tool-heavy, and do not be shy about starting fresh when the combination of tools and context is not working.