A tech lead pings you on Slack: "we should move our Claude integrations to MCP."
You ask what they have today. Four custom tools wired via function calling, running in production for the past eight months. You ask what's broken.
"Nothing. But MCP is the standard now."
Same trap as the Agent SDK. The phrase "it's the standard" hides the fact that nobody in the room has articulated what MCP is supposed to fix. And when you don't know what you're fixing, you migrate for nothing.
MCP doesn't replace function calling. It standardizes how your tools are exposed, not how they're called.
The metaphor that actually works
MCP isn't a new model. It isn't an orchestration framework. It isn't a function-calling 2.0.
MCP is a standardized power outlet for your tools.
An outlet is useless if you have one device and one wall. It pays off the moment you have multiple devices that need the same power.
Same with MCP. One Claude app calling two custom tools? You don't need a standard contract between them. You need a function and a return value.
The day three teams want to plug into the same data source from three different clients, you're either inventing your own protocol or adopting the one Anthropic put on the table.
The math under the hype
Before MCP, integration scaled at N×M. N clients, M tools, every pair needed its own wiring. Five clients, ten tools = fifty integrations to maintain.
With MCP, that becomes M+N. Each tool exposes one MCP server. Each client speaks MCP once. Done.
That math is the only honest reason to adopt MCP. Everything else ("it's modern", "it's what $BIG_TECH uses") is noise.
When MCP earns its keep
Three concrete scenarios.
One tool, multiple LLM clients. PMs on Claude Desktop. Devs on Claude Code. Support team on an internal app you built on the API. All three need to hit the same product database. Without MCP, you maintain three connectors and keep their schemas in sync forever. With MCP, you write one server.
Tapping into the ecosystem. Servers already exist for GitHub, Notion, Slack, Postgres, Linear, Stripe. You install, configure credentials, plug in. Coding those yourself for a weekend is fine. Maintaining them while upstream APIs evolve is a part-time job nobody on your team signed up for.
Decoupling tool teams from app teams. In a structured shop, the CRM team owns the CRM. The LLM app team owns the assistant. Raw function calling forces the app team to also own CRM schema, auth, rate limiting, error handling. With MCP, the CRM team ships a server. Clear contract, fewer cross-team pings.
When MCP is pure overhead
MCP isn't free. It adds a transport hop, a server to deploy, a spec to follow. Three cases where the math doesn't work:
- One app, two homemade tools. Adding MCP between code that shares a repo gives you network calls to debug for zero portability gain.
- Hyper-specific tools with no reuse path. A one-off integration with a legacy ERP nobody else runs your way. The standardization argument evaporates.
- Ultra-low-latency loops. Voice agents, trading, real-time control. The transport hop is invisible on most workloads. On these, it shows up in your p99.
The classic trap, both sides
Same anti-pattern as the Agent SDK, mirrored.
Side one: migrate everything to MCP because "it's the standard." Single-app teams suddenly grow a server fleet, a deployment pipeline, and an on-call rotation, all to rewrite tools that already worked. Months of effort for zero user-visible change.
Side two: refuse MCP and roll your own protocol. Six months later, you've reinvented MCP without the spec, the community, or the pre-built servers. Your new Claude Code license can't talk to anything you built.
A standard is the default when you expect multiple consumers. Not a religion.
Three questions before you migrate
- Will my tools or data sources be consumed by more than one LLM client (Claude Desktop, Claude Code, internal apps, IDE) in the next 12 months?
- Does an official or community MCP server already exist for what I want to wire up?
- Do I need to decouple the team building the tool from the team building the LLM app?
Two yes, MCP pays off. Otherwise raw function calling wins. Less infrastructure, less surface area, less to debug.
The full breakdown
This is the short version. The long-form post digs into the MCP / Agent SDK distinction (they sit on different layers, and most teams confuse them), the decision logic at SMB scale, and the cost of getting it wrong.
→ MCP Explained: Model Context Protocol for Tech Leaders
I'm Valentin, Data & AI consultant working specifically with Claude stacks. If you're stuck between "should we migrate" and "what would we actually gain", the long-form will save you a discovery call.
Top comments (8)
The outlet metaphor is good for the appliance side but the wiring (server side) is the more interesting question. In your client work do teams adopt MCP because it's plug-and-play or because they've already drawn lines around which tools belong to which domain and MCP just enforces that at the protocol layer? Asking because most of the MCP adoption stories I've heard land for the second reason and the metaphor underplays that part
Honestly the second, almost every time. Plug-and-play sells the first install, but the adoption that actually sticks is where the domain lines already existed and MCP just made them enforceable. When the boundaries aren't drawn yet, MCP doesn't create them, it exposes that nobody agreed on who owns what. Good catch that the metaphor underplays that side.
The N+M math underrates the solo case too. I'm a single developer and I still hit the multi-client problem: Claude Code in the terminal, Claude Desktop on the same machine, sometimes Cursor, all wanting to read the same Supabase schema for the same project. The Supabase MCP server gets installed once, configured once, and all three pick it up. Without MCP that's three separate connector configs to keep in sync forever, even though the "team" is one person. Your three-question framework holds, but question 1 is satisfied by tool diversity, not headcount.
Yeah, you reframed question 1 better than I wrote it. The trigger is the number of consumers, not the number of people. One dev with three clients hits N×M the same way three teams do, the wiring doesn't care who's behind the keyboard. Supabase server installed once is exactly the payoff.
It’s fascinating! hadn’t realized MCP has such a long history. I didn’t know the technology wasn’t a new concept after all.
Glad it landed Benjamin. The protocol itself is new, but you're right that the thing underneath isn't: wiring tools to whatever client wants them is as old as APIs. MCP just gave that old headache a standard shape.
I agree with you concerning MCP that it is new.
the 'decoupling tool teams from app teams' case is where the math actually pays off — agreed. but the hidden cost in that deal is who owns the auth boundary once it moves to the MCP layer.
we hit this building a Next.js MCP server: per user OAuth sounded clean until the tool team realized they now owned credential refresh, token scoping, and the "which user’s data does the agent mean" problem the API route was silently handling via session context.
worth a fourth question before you decouple: has anyone agreed who owns auth at the MCP server boundary?