MCP With Local Coding Agents: Which Servers Earn Their Tokens

Written by Jakub Rusinowski · Last updated 2026-08-04 · Hardware figures computed by our VRAM engine

MCP gives a coding agent a standard way to reach outside itself — files, databases, browsers, issue trackers. The catch on local hardware is that every connected server injects its full tool schema into every request: a handful of servers can consume more of a 32K window than your actual task. Connect per project, keep the total tool count in single digits, and prefer a shell command over an MCP server whenever a CLI already does the job.

The Model Context Protocol is a standard interface between an agent and external systems: a server exposes tools with typed schemas, and any MCP-speaking client can call them. It solved a real problem — every agent previously needed a bespoke integration for every system — and by 2026 the ecosystem is large.

Then you point it at a local model and hit a wall nobody mentions in the marketing: tool schemas are prompt tokens, charged on every request. Measurements circulated widely in 2026 put a typical seven-server setup at tens of thousands of tokens of definitions before the user types anything — a third of a large frontier window. On a 16–32K local window, that is not a tax; that is the whole budget.

MCP is still worth using locally. It just has to be rationed.

The token bill, made concrete

Model your own setup before connecting anything else. A rough accounting for a 24 GB card serving 32K of context:

Item	Tokens	Share of a 32K window
Harness system prompt	~4,000	12%
Three lean MCP servers	~6,000	19%
Seven typical MCP servers	~25,000+	78% — unworkable
Rules file	~500	2%
Two source files under edit	~6,000	19%
Conversation + tool results	grows	the rest

The failure this produces is confusing rather than obvious: the agent does not error, it just gets worse. The window fills before real work starts, compaction kicks in early, and the model spends its attention on descriptions of tools it will never call. Every symptom looks like "the model is too small."

Check the arithmetic yourself: most clients can list connected tools, and a rough token count of the tool descriptions is close enough. If tools plus system prompt exceed a quarter of your window, cut.

When plain CLI beats MCP

A theme of 2026 among people shipping quickly: for everyday coding, the terminal often wins. An agent with shell access already has git, rg, npm, docker, curl, psql and every other tool you have installed — behind *one* tool definition instead of dozens, with output you can pipe and truncate.

Prefer a shell command when:

A CLI already exists and you trust it. gh pr view, psql -c, docker logs. One tool, no schema, no server process.
The window is tight. Under 32K, one run_command tool plus a good rules file beats three servers, nearly always.
Output needs shaping. You can pipe a CLI through head, jq or grep before it reaches context. MCP results arrive as the server chose to format them.

Prefer MCP when:

There is no good CLI — browser automation is the standard example, and a real one.
You need typed, structured results the model can reason over rather than parse out of text.
The integration needs credentials you would rather not put in a shell history, held by a server process instead.
You want the tool available identically across several agents, which is the protocol's actual purpose.

A local-friendly server set

Ranked by value per token on a small window. Connect the first two or three; add more only when a project needs them.

1. Filesystem (scoped to one project root) — worth it when your agent's built-in file tools are weak. Redundant with Aider, Cline or OpenCode, which already have file access; skip it there. 2. Git / GitHub — history, blame, PRs and issues. Genuinely useful context an agent cannot otherwise reach. If you only need local history, git via shell is cheaper. 3. Browser automation (Playwright-style) — the clearest MCP win. Front-end work where the agent can load the page, click, and read the console closes a feedback loop nothing else does. Expensive in tokens; connect it for front-end sessions only. 4. Database (Postgres/Supabase-style) — schema introspection so the agent stops inventing column names. High value for data-layer work; connect per project, read-only where you can. 5. Docs/search servers — usually the first thing to cut locally. A rules file linking the two doc pages you actually use costs a hundredth as much.

Everything else: connect it for the session that needs it, disconnect afterwards. Per-project configuration rather than a global config is the habit that keeps this manageable.

Reducing the cost without giving up the tools

Three families of mitigation shipped across 2026, all variations on progressive disclosure — don't load a tool's full schema until it is needed.

Deferred / searchable tools. The client advertises tool *names* only and fetches full schemas on demand. Where your client supports it, this is the single biggest saving.
Code-execution style access. Instead of exposing dozens of tools, expose one that runs code against an API surface, letting the model compose calls rather than pick from a menu. Far fewer tokens, and better suited to models that write code well — which is exactly what a coding model is.
Per-project connection. The unglamorous one that works everywhere: a project-scoped config listing only what this repo needs. Two servers per project beats twelve globally, and requires no client features at all.

Also worth doing regardless: truncate MCP results in the harness. A schema dump or an unbounded query can be tens of thousands of tokens. Cap it, tail it, and summarise before it lands in a local window.

Security: a local model does not make the tools local

Running the model on your own machine removes one exposure — your code is not leaving for inference. It removes nothing about what the tools do. An MCP server is a program you granted access to your files, databases or network, and each one is a dependency with its own supply chain. The ecosystem has already had systemic vulnerabilities disclosed across SDK implementations, so treat these as production dependencies, not plugins.

The checklist:

Read what you install. Prefer first-party servers from the vendor whose system it touches. Pin versions.
Scope credentials down. Read-only database roles, tokens limited to one repo, no long-lived admin keys.
Assume tool output is untrusted input. An issue body, a web page, or a file the agent fetches can contain instructions aimed at your agent — prompt injection through tool results is the live attack path, and it does not care that your model is local.
Keep the destructive tools behind a human. Read is fine to automate; write, deploy, and anything with a network side effect deserves a gate. Structure it as an allowlist plus a sandbox rather than a stream of prompts nobody reads (sandboxing).
Prefer no network egress from the sandbox unless a task needs it. Most coding work does not.

The privacy argument for local models survives all of this — but only if you connect the tools with the same care you would give any other dependency.

Frequently asked questions

What is MCP, and do I need it for a local coding agent?

The Model Context Protocol is a standard interface letting any MCP-speaking agent call tools exposed by a server — files, databases, browsers, issue trackers. You do not need it: agents like Aider, Cline and OpenCode already have file, search and shell tools. Add MCP when you need a capability those lack, browser automation and database introspection being the clearest cases.

How much context do MCP servers consume?

More than most people expect, because every connected server injects its full tool schema into every request. Widely-cited 2026 measurements put a seven-server setup at tens of thousands of tokens — roughly a third of a large frontier window, and more than an entire 16–32K local one. If your tool definitions plus system prompt exceed a quarter of your window, cut servers.

Is MCP or plain shell access better for a local model?

For everyday coding on a small window, shell access usually wins: one tool definition instead of dozens, and every CLI you already have installed. Use MCP where no good CLI exists (browser automation), where you want typed structured results, or where the credentials are better held by a server process than typed into a shell.

Which MCP servers are worth connecting to a local coding agent?

Browser automation for front-end work, a database server for schema-aware data-layer work, and git/GitHub for history and PR context. Filesystem servers are usually redundant with your agent’s own file tools. Documentation and search servers are typically the first to cut — a rules file linking the pages you use costs a fraction as much.

Is MCP safe if the model runs locally?

Local inference protects your code from leaving for inference; it says nothing about what the tools do. Each server is a dependency with filesystem, database or network access, and the ecosystem has had systemic vulnerabilities disclosed. Pin versions, prefer first-party servers, scope credentials to read-only where possible, treat all tool output as untrusted input that may carry prompt injection, and keep destructive actions behind a gate.