Photo by Shamin Haky on Unsplash
The Integration Math That Started All of This
Nine connections. Then six. Then twenty-five versus ten. Then one hundred versus twenty. That escalating gap — not the demo videos, not the launch partners — is the entire argument for the Model Context Protocol, and it is the part most write-ups skip past in a sentence.
According to AI Fallback, whose reporting forms the basis for this analysis, Anthropic open-sourced MCP in November 2024 as a standard for connecting AI assistants to the systems where data actually lives: content repositories, business tools, development environments. The company's framing was blunt. Alex Albert, Anthropic's Head of Developer Relations, said at the time that MCP "provides a universal standard for connecting AI systems to data sources, eliminating the need for custom integrations for each provider."
Here is the non-obvious part. The protocol's own pitch is that integration complexity drops from N×M — every application wiring itself to every data source — to N+M, where apps and sources each implement MCP exactly once. Run that formula out and the curve gets ugly fast in the old world. Three apps against three sources is nine bespoke connectors versus six MCP implementations: a savings of three, which is nothing. Five against five is twenty-five versus ten. Ten against ten is one hundred versus twenty — an 80% reduction in things a team has to build, version, and page someone about at 3 a.m.
The lesson buried in that curve: MCP is worth almost nothing to a team with three integrations and worth enormously more to a platform with thirty. Adoption advice that ignores where you sit on that curve is advice worth ignoring.
Chart: Integration counts derived from the N×M → N+M claim in Anthropic's own MCP documentation. The savings are trivial at small scale and compound sharply past roughly five-by-five.
MCP vs LangChain: They Are Not Fighting Over the Same Job
The most common framing in developer forums — pick MCP or pick LangChain — is a category error, and it wastes real engineering hours.
MCP is a transport and capability-description standard. It defines how a client and a server talk, over stdio, HTTP with server-sent events, or WebSocket, using JSON-RPC 2.0 message framing. Per the published specification, it exposes exactly three primitives: Resources (data and content the model can read), Tools (functions the model can execute), and Prompts (templated interactions). That is the whole surface area. It has no opinion about chains, memory, routing, or retries.
LangChain and LlamaIndex live a layer up. They handle orchestration — what the agent does with a tool result, how many hops it takes, when it gives up. Both frameworks announced MCP compatibility layers in late 2024, which is the tell: a competitor does not ship an adapter for its rival's wire format. They are complements.
So who wins under which condition? If the problem is "my agent loop retries forever and burns tokens," MCP fixes none of that — that is orchestration, and a framework or hand-rolled control flow is the answer. If the problem is "every new data source costs us two weeks of connector work and a fresh auth story," MCP is directly on point. And if the problem is "we support one model and one database," the honest answer is that raw function calling — the approach OpenAI extended through its 2024 Assistant API updates — is less machinery for the same result.
Some technical reviewers push back harder than that, and the pushback deserves airtime: Anthropic markets MCP as enabling agentic AI, while critics note it is fundamentally a structured RPC protocol, not an agent architecture. That critique is correct on the technical merits. It is also somewhat beside the point, because the thing blocking most agents from production is not reasoning quality — it is that the agent cannot reach the data. This is the same gap Smart SaaS flagged in its look at Ema's $77M bet on agents displacing enterprise software: capability claims run well ahead of integration reality.
Implementation: An MCP Server Is Smaller Than You Think
Strip the marketing and an MCP server is a lightweight program that advertises a capability list and answers JSON-RPC calls against it. Nothing more. Anthropic shipped reference implementations on GitHub alongside the November 2024 announcement, with pre-built servers for Google Drive, Slack, GitHub, PostgreSQL, Puppeteer, and local filesystem access.
The practical build path, for a team starting today:
The PostgreSQL and filesystem servers in the official repo are the two clearest templates. Read how they declare Resources versus Tools — that boundary is where most first attempts go wrong. A read-only report is a Resource. A write that changes state is a Tool, and it needs to be treated like one.
stdio is the simplest and the default for local, single-user setups like a desktop client. HTTP with SSE is what you want for a remote server serving multiple clients. Choosing stdio and later retrofitting remote access is a rewrite, not a config change.
Tool descriptions are prompt surface. Vague ones produce tool-call loops where the model tries the same function three times with slightly different arguments. Eval-driven development applies here: build a fixed set of twenty representative requests and measure how often the model picks the right tool on the first attempt, before you ship.
SDKs exist in TypeScript and Python. Primary data from the MCP GitHub organization put the TypeScript SDK at roughly 2.8k stars and the Python SDK at roughly 1.1k as of December 2024 — about a 2.5-to-1 split. That ratio matters for a reason nobody advertises: the deeper ecosystem examples, and the faster bug fixes, have historically landed on the TypeScript side first. A Python-only shop should budget for thinner community reference material.
The Failure Modes That Never Appear in the Demo
Three of them, in rough order of how often they bite.
Context window blowups from over-eager Resources. An MCP server that exposes a 40,000-row table as a Resource will happily hand the model all of it. The protocol does not paginate for you. Teams that skip explicit result-size caps discover this on the first invoice, not the first test.
Auth that nobody scoped. An MCP server inherits whatever credentials it runs with. Connect one to a production PostgreSQL instance holding customer records or portfolio data for a financial planning product, and you have granted a language model the permissions of that database role. The protocol supports secure, auditable connections — it does not enforce least privilege on your behalf. Separate read-only roles per server are the minimum bar.
Standards fragmentation. TechCrunch, covering the launch in November 2024, described MCP as a potential "USB-C moment for AI" while flagging exactly this risk: the value collapses if OpenAI or Google ship competing standards. Notably, Microsoft and Google both sat out initial adoption, continuing with proprietary plugin systems for Copilot and Gemini. Launch partners skewed toward independents — Block, Apollo, Replit, Codeium, Sourcegraph — with client support in Claude Desktop and the Zed editor.
One caveat on all of the above: the adoption figures and partner lists in circulation trace back to late 2024. Anyone evaluating MCP as of September 30, 2026 should verify current SDK maturity, transport support, and vendor participation directly against the specification site and GitHub organization rather than trusting a two-year-old snapshot.
Bottom Line: Who Should Build on It Now
Our read is that the N+M curve, not the branding, should drive the decision. Teams running a handful of integrations get abstraction overhead with little payoff and should stay with direct function calling. Teams past roughly five apps against five data sources — where the custom-connector count hits 25 and climbs — capture real savings, and the case strengthens with every source added. Platform vendors and tool builders who want their data reachable by any compatible client have the strongest case of all, since one server implementation replaces a per-vendor integration backlog.
On balance, the more likely outcome is not a single universal standard but a durable split: a vendor-neutral protocol for the independent tooling layer, and proprietary plugin systems inside the largest vendors' own walled gardens. That still leaves MCP valuable — just less universal than the USB-C metaphor implies. Build against it for the integration math, not for the promise that everyone will eventually converge.
Frequently Asked Questions
What is the Model Context Protocol and how does it actually work?
MCP is an open-source standard Anthropic released in November 2024 for connecting AI applications to data sources and tools. It uses a client-server architecture over JSON-RPC 2.0, with servers exposing three primitives — Resources (readable data), Tools (executable functions), and Prompts (templated interactions) — to any compatible client.
How do I build an MCP server for my own data source?
Start from a reference implementation in the official GitHub organization, using the TypeScript or Python SDK. Declare your capabilities as Resources or Tools depending on whether they read or write, choose stdio for local use or HTTP with SSE for remote, and cap result sizes before connecting anything to a large table.
What is the difference between MCP and LangChain for AI agents?
They operate at different layers. MCP standardizes the transport and capability description between an AI client and a data source. LangChain and LlamaIndex handle higher-level orchestration — chaining, routing, memory. Both frameworks added MCP compatibility layers in late 2024, which makes them complements rather than alternatives.
Which AI assistants and editors support the Model Context Protocol?
At launch in November 2024, support included Claude Desktop, the Zed editor, Replit, Codeium, and Sourcegraph, with Block and Apollo among early partners. Microsoft and Google were notably absent from initial adoption, continuing with proprietary plugin approaches for Copilot and Gemini respectively.
Is MCP secure enough for enterprise data integration?
The protocol is designed for secure, auditable connections, but security depends entirely on how the server is deployed. An MCP server operates with whatever credentials it is given, so scoped read-only database roles, per-server credential separation, and explicit result-size limits are required. The protocol does not enforce least privilege automatically.
Disclaimer: This article is editorial commentary for informational and educational purposes only. It is based on publicly reported information and does not constitute implementation consulting, security advice, or financial advice. No independent product testing was performed. Research based on publicly available sources current as of September 30, 2026.