MCP Isn't a Model Feature. It's a Power Outlet for Your Tools.

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

1. 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?
2. Does an official or community MCP server already exist for what I want to wire up?
3. 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.