MCP: A Revolution in AI or Just Another Step Forward?

The introduction of Model Context Protocol (MCP) has sparked intense debate in the AI community. Is it truly revolutionary, or is it just another incremental advancement in the ever-evolving landscape of artificial intelligence? Let's explore this question by drawing parallels with historical AI developments.

MCP became part of many agentic applications like a glue interface between large totally different services. Developers simply configure another integration layer in their agent host. The protocol standardizes how models talk to tools, but it has not yet rewritten project structure, hiring, or the tools most teams reach for by default. That gap between "useful plumbing" and "industry reshaping" is worth keeping in mind.

Practical example: context window cost

Consider a common agent task: "Summarize open pull requests on my repo and flag anything blocked on CI."

Two ways to give the model access to GitHub:

Option A — MCP server with upfront tool definitions

You wire up a GitHub MCP server. Before the user sends a single message, the host injects every tool the server exposes — often 15–30 operations — each with a name, description, and JSON schema:

{
  "name": "list_pull_requests",
  "description": "List pull requests in a repository. Supports state filters...",
  "inputSchema": {
    "type": "object",
    "properties": {
      "owner": { "type": "string", "description": "Repository owner" },
      "repo": { "type": "string", "description": "Repository name" },
      "state": { "enum": ["open", "closed", "all"] }
    },
    "required": ["owner", "repo"]
  }
}

Multiply that snippet by every tool on the server, then again for each additional MCP server you enable (Slack, Linear, Sentry, filesystem, …). A realistic multi-server setup can consume 5 000–15 000 tokens of context before the conversation starts. That is fixed overhead on every turn, regardless of whether the user ever asks about Slack or Sentry.

The upside is discoverability: the model sees a typed menu of capabilities and can pick the right tool immediately.

Option B — a neat CLI with progressive context disclosure

The same task with the gh CLI and no MCP. The system prompt only needs to know that a GitHub CLI exists and how to invoke it:

gh pr list --repo owner/repo --state open --json number,title,author,statusCheckRollup
gh pr checks 42 --repo owner/repo

The model discovers details on demand:

gh pr list --help        # ~150 tokens, only when needed
gh pr checks --help      # another ~100 tokens, only if checks matter

Total context for this single task might stay under 500 tokens. You pay for help text and command output only when the workflow requires it. The trade-off is extra round-trips: the agent may run --help, inspect a failed command, and retry — slower, but leaner on the context window.

Side-by-side

Neither approach wins everywhere. MCP front-loads structure at the cost of window space; a CLI defers detail until the moment it is needed.

Why MCP still makes sense for third-party integrations

The MCP ecosystem has grown quickly. Official and community servers now cover a wide surface:

• Developer tools — GitHub, GitLab, filesystem, git
• Observability — Sentry, Datadog, Grafana
• Productivity — Slack, Linear, Notion, Google Drive
• Data & cloud — Postgres, Snowflake, AWS, Azure (via Microsoft Learn and other servers)
• Custom backends — any team can expose internal APIs as an MCP server

That breadth is the real argument for MCP as an integration layer. Instead of teaching every agent host how to wrap Slack, Linear, and your internal ticketing API separately, each vendor (or your team) ships one MCP server. The host speaks a single protocol; new integrations plug in without bespoke prompt engineering for every service.

For third-party SaaS especially, MCP offers:

1. A shared contract — tool names, schemas, and error shapes are standardized.
2. Built-in auth flows — OAuth and token handoff patterns are part of the spec, not reinvented per integration.
3. Composability — enable only the servers you need, mix vendors in one session.

If your agent regularly orchestrates across many external systems, MCP reduces integration glue. The CLI-first approach shines when you control the environment and the task scope is narrow.

Cautions worth taking seriously

MCP is useful, not magic. A few risks to plan for:

Context explosion. Each enabled server adds permanent schema overhead. Enabling "everything" because it is available can silently eat half your context window. Curate servers per workflow; disable idle ones.

Security concerns. An MCP server can execute actions with the credentials you grant it — read repos, post messages, query production databases. Treat every server like installing a browser extension: verify the publisher, pin versions, and scope OAuth tokens to least privilege.

Not a replacement for good tool design. Dumping 40 thin wrappers around a REST API into MCP does not fix a confusing API — it just moves the confusion into your context window. Prefer fewer, well-described tools over exhaustive coverage.

Conclusion

I consider MCP is less a revolution than a pragmatic standardization bet: pay context upfront for structured, multi-vendor integration. For agents that juggle many third-party services, that trade is often worth it. For focused, context-constrained workflows - or environments you fully control - a well-known CLI with progressive disclosure remains hard to beat.

The sensible path is hybrid: MCP where the integration surface is broad and maintained by others; CLI (or direct SDK calls) where the task is narrow and every token counts.