MCP is eating point-to-point integrations — here's what that means for your stack
6 min read
By Rohini Sonawane
AIML
If you've built more than one "AI feature" into a product, you already know the real work was never the model call. It was the plumbing around it — the custom connector to your CRM, the bespoke wrapper around your internal search API, the auth dance for the ticketing system, repeated slightly differently for every tool and every model you tried. The Model Context Protocol (MCP) exists because that plumbing problem was universal enough to be worth solving once, properly, as a protocol instead of a pile of SDKs.
This post is a practical look at what MCP actually is, why the adoption curve over the last year has been unusually steep even by AI standards, where it genuinely helps a team like ours, and where — in the spirit of our own "Before Using an LLM, Ask: Do We Really Need One?" post — it's easy to over-apply.
What MCP actually is
MCP is an open protocol, originally released by Anthropic, that standardizes how an AI application talks to external tools, data sources, and services. It borrows a deliberately familiar shape from the Language Server Protocol that changed how editors talk to language tooling: instead of every IDE writing its own Python/Go/Rust support, editors implement one client interface, and every language implements one server. MCP does the same thing for AI agents and tools.
Three pieces make up the architecture:
- Host — the application the user actually talks to (Claude, an IDE, a custom agent).
- Client — lives inside the host, holds one connection to one server, speaks MCP.
- Server — a thin process (yours, or a vendor's) that exposes tools (actions the model can call), resources (data the model can read), and prompts (reusable templates) over a standard schema.
The point isn't that this is architecturally novel — RPC-over-a-schema is an old idea. The point is that before MCP, every AI vendor invented a slightly different flavor of "tool calling," so a server built for one model's function-calling format didn't transfer to another. MCP is model-agnostic: build the server once, and any MCP-aware client — Claude, GPT, Gemini, an internal agent — can use it.
Nov 2024 — MCP open-sourced by Anthropic
97M+ — monthly SDK downloads by March 2026
17,000+ — independently indexed MCP servers, Q1 2026
(Figures reported across independent 2026 adoption write-ups; sources at the end of this post.)
Why the timing actually matters
A lot of "why now" posts about AI infrastructure are hype dressed up as analysis. This one has a slightly more boring, more credible answer: three separate things converged.
Vendor consolidation happened fast. OpenAI, Google DeepMind, and Microsoft Copilot Studio all shipped MCP client support within about a year of launch, alongside developer tools like Cursor, Replit, and Zed. That's the part that matters for your team: when the protocol isn't tied to one vendor, building against it stops being a bet on a single company's roadmap.
Governance moved out from under Anthropic. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, turning it from a corporate spec into a vendor-neutral, community-governed standard — the same trust move that made protocols like Kubernetes or gRPC safe to build a company's infrastructure on.
The failure mode it fixes is extremely common. Enterprise AI pilots don't usually die because the model is weak. Reports put the stall-before-production rate at roughly 86%, and the recurring blocker cited across write-ups is fragmented, one-off integration work rather than model capability.
The bottleneck was never whether the model was smart enough. It was whether it could reliably see your data.
What a minimal MCP server looks like
To make this concrete rather than abstract: here's a stripped-down MCP server in Python exposing one tool — a lookup against a hypothetical internal service — using Anthropic's official SDK pattern.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("internal-tools")
@mcp.tool()
def get_project_status(project_id: str) -> dict:
"""Return current status, owner, and last update for an internal project."""
project = db.projects.find_one({"id": project_id})
if not project:
return {"error": f"No project found for id {project_id}"}
return {
"id": project["id"],
"status": project["status"],
"owner": project["owner"],
"last_updated": project["updated_at"].isoformat(),
}
if __name__ == "__main__":
mcp.run(transport="stdio")That's the whole server. No custom auth handshake per model, no bespoke function-calling schema to hand-write for each provider — FastMCP generates the tool schema from the function signature and docstring, and any MCP client can discover and call it. Point Claude, an internal agent, or a teammate's IDE at this server and get_project_status just works, the same way, everywhere.
Where it earns its place — and where it doesn't
We're wary of "just add MCP" as a reflex, for the same reason our engineering team is wary of reaching for an LLM before checking whether the problem actually needs one. MCP solves a specific, structural problem: N models needing to talk to M tools. It is not a substitute for good API design, and it's not free — every server you stand up is another process to run, secure, and monitor.
A reasonable filter before adding an MCP server to your stack:
- More than one AI surface (chat assistant, agent, IDE plugin) needs the same tool — otherwise a direct function call is simpler and has less surface area.
- The tool involves real side effects (writing to a CRM, filing a ticket, triggering a deploy) where you need consistent auth, scoping, and audit logging in one place, not duplicated per integration.
- You expect the set of consuming models or agents to change over time — MCP's payoff compounds the more clients reuse the same server.
- You're willing to treat tool descriptions as a first-class interface. A vague docstring produces a model that calls your tool wrong just as often as a vague REST endpoint produces a confused frontend developer.
The parts that are still genuinely unresolved
None of this is a solved-problem victory lap. Three things are worth budgeting engineering time for before you commit:
- Auth and scoping. Giving an agent an MCP server with write access to production systems is a real permissions problem, not a config toggle. Treat every tool exposure the way you'd treat a new API key with production access, because functionally, that's what it is.
- Tool selection at scale. Models get measurably worse at picking the right tool once a server (or a stacked set of servers) exposes dozens of overlapping capabilities. Fewer, well-named, well-scoped tools beat a kitchen-sink server every time.
- Prompt injection through tool output. Any data returned from an MCP tool — a ticket description, a database row, a scraped page — is untrusted input to the model, exactly like any other retrieved context. Treat it that way in your threat model, not as a trusted internal source just because it came from your own server.
The short version
MCP didn't make models smarter. It made the boring 80% of building an AI feature — the connectors, the auth, the per-vendor tool-calling dialects — a solved, shared problem instead of a bespoke one every team reinvents. That's a genuinely useful kind of progress: unglamorous, plumbing-level, and exactly the sort of thing that quietly saves an engineering team weeks per integration once it's in place.
If you're deciding whether to build against it, the filter above is a reasonable starting point — and if the honest answer is "we have one model and one tool," you may not need MCP at all yet. That's fine. The protocol will still be there when you do.
