Agents already use MCP via SDKs — that part is solved. The problems are deeper.
📊 Token inefficiency
Every MCP tool schema burns context window tokens on every turn — even tools the agent never calls. GitHub's own MCP server: 93 tool definitions, ~55,000 tokens before the agent writes a single line of code. The CLI equivalent: zero tokens upfront — the model already knows gh pr create from training data.
🚪 Adding friction, not removing it
WinDBG's MCP server requires launching the WinDBG UI app and interacting with it before the agent can use it. This is worse than the CLI path — cdb -c "!analyze -v" needs no UI, no human interaction.
🚫 Policy decisions that reduce value
The WinDBG MCP server refuses to debug Watson dumps — a conscious decision to make it less useful. Feature teams making policy decisions about what agents can and can't do leads to artificially crippled tools.
📦 Duplication → agent confusion
N teams each implement transport, error handling, auth, lifecycle — all slightly different. When two servers expose overlapping capabilities, agents can't disambiguate. Better: atomic, single-purpose tools that agents compose — like piping CLI commands.
🔓 Supply-chain attack surface
This week: an attacker injected a prompt into a GitHub issue
title. An AI triage bot read it, interpreted it as an instruction, and executed it — leaking an npm token. MCP servers that auto-execute from untrusted input inherit this risk.
268K views, March 2026.
📐 False standardization
Design guidelines without evals is agreeing on ritual, not efficacy. We can standardize naming conventions and still ship tools that agents can't use.