Why do some developers dislike MCP?

The common complaints are context bloat from many tool definitions, security risks from third-party servers and injected instructions, extra moving parts compared with calling an API directly, and a low-quality public server ecosystem. Most of these are fair descriptions of how MCP is often used, and most have practical mitigations rather than being flaws in the core idea.

The protocol does not make agents safe by itself. Security depends on which servers you install, what credentials they hold, and how the agent treats their output. Use trusted and pinned servers, narrow credentials, confirmation for destructive actions, and treat tool results as untrusted data that may contain injected instructions.

When should I not use MCP?

When a single agent needs to call a single, well-documented API and nothing else will reuse the integration, a direct call or a command-line tool is often simpler. MCP adds value when several clients share a capability, when credentials should stay out of the agent's reach, or when the server reshapes the raw API into task-level tools.

Will MCP be replaced?

Standards evolve, and the specification has already changed to address early gaps such as authentication. What matters more is the underlying pattern: a common interface between agents and systems. Whether through MCP or a successor, that pattern is likely to persist. Designing servers with small, task-shaped tools and narrow credentials protects you either way.

Is MCP a Bad Idea? The Criticisms That Hold, and the Ones That Do Not

MCP is not a bad idea, but several criticisms of it are fair. Loading many tool definitions bloats context, early security defaults were weak, and some servers wrap APIs an agent could call directly. The standard itself solves a real problem: one integration usable by every compatible agent. Most failures come from how servers are designed and deployed.

What MCP is for, briefly

Before MCP, connecting an agent to a system meant writing an integration for that specific agent framework. Ten agents and ten systems meant up to a hundred integrations. MCP defines one interface: a server exposes tools, resources, and prompts; any compatible client can use them. Write the connector once, and every client that speaks the protocol can use it.

That is the claim critics are responding to. The useful question is not whether MCP is good or bad in the abstract, but which criticisms describe the protocol and which describe how it is being used.

Criticism 1: it bloats the context window

The argument. Every connected server's tool definitions are sent to the model on every request. Connect a handful of servers and a large share of the context is tool descriptions, which costs tokens and degrades tool selection.

Verdict: valid. This is a real cost and it grows with every server. It is also a design problem with known fixes: fewer, task-shaped tools instead of one per endpoint, tighter descriptions, loading tool definitions on demand through tool search, and connecting only the servers a given task needs.

Criticism 2: it is a security problem

The argument. MCP servers run with real credentials and take instructions from a model that reads untrusted input. Tool descriptions from a malicious server can manipulate the agent. Results from a tool can carry injected instructions. Early specifications left authentication largely to implementers.

Verdict: valid and important. These risks are real, though most are not unique to MCP. Any agent with tools and untrusted input has them. MCP concentrates them by making it easy to connect many third-party servers quickly. The mitigations are the ordinary ones applied consistently: install servers from sources you trust, pin versions, use narrowly scoped credentials, require confirmation for destructive actions, and treat tool results as untrusted data.

Criticism 3: it should have just been an API

The argument. Models can already call HTTP APIs, and capable coding agents can read API documentation and write the calls. Wrapping an API in an MCP server adds a process, a protocol, and a maintenance burden for little gain.

Verdict: partly valid. For one agent calling one well-documented API, a direct call or a command-line tool can be simpler. MCP earns its overhead when the same capability is used by several clients, when the server holds credentials the agent should not see, or when the server adds something the raw API lacks, such as task-shaped operations, trimmed responses, or access to local resources.

Criticism 4: the ecosystem is low quality

The argument. Public server lists are full of abandoned, insecure, or trivially thin wrappers.

Verdict: valid, and normal. Every young package ecosystem looks like this. It is a reason to be selective, not a verdict on the protocol. Prefer servers maintained by the vendor of the underlying system, review what a server can do before connecting it, and build your own for anything sensitive.

What to take from the debate

Use MCP where a standard connector pays off: several clients, credentials that should stay out of the agent, or capabilities that benefit from task-shaped tools. Skip it where a direct call is simpler. Keep tool surfaces small, treat every result as untrusted, and connect only what a task needs.

And notice where MCP is being asked to do the wrong job. Many servers exist only to push documentation or reference knowledge into an agent through a tool. That is retrieval. An index searched on demand does it with less surface area and less context than a set of bespoke tools, and it serves every client at once without a separate server per knowledge source.

Frequently asked questions

Why do some developers dislike MCP?: The common complaints are context bloat from many tool definitions, security risks from third-party servers and injected instructions, extra moving parts compared with calling an API directly, and a low-quality public server ecosystem. Most of these are fair descriptions of how MCP is often used, and most have practical mitigations rather than being flaws in the core idea.
Is MCP secure?: The protocol does not make agents safe by itself. Security depends on which servers you install, what credentials they hold, and how the agent treats their output. Use trusted and pinned servers, narrow credentials, confirmation for destructive actions, and treat tool results as untrusted data that may contain injected instructions.
When should I not use MCP?: When a single agent needs to call a single, well-documented API and nothing else will reuse the integration, a direct call or a command-line tool is often simpler. MCP adds value when several clients share a capability, when credentials should stay out of the agent's reach, or when the server reshapes the raw API into task-level tools.
Will MCP be replaced?: Standards evolve, and the specification has already changed to address early gaps such as authentication. What matters more is the underlying pattern: a common interface between agents and systems. Whether through MCP or a successor, that pattern is likely to persist. Designing servers with small, task-shaped tools and narrow credentials protects you either way.