Model Context Protocol (MCP): The USB-C Standard for AI and Why Developers Should Care

Why AI Tool Integrations Still Suck

Here's a problem I've lived through: I needed to pull data from five different ad platforms — Meta, Google, Bing, TikTok, and one I'd rather forget — into a single real-time dashboard. Each platform had its own auth flow, its own rate limits, its own pagination logic, its own way of describing a campaign. I wrote custom integrations for every single one. Then I had to normalize the data in Python, pipe it into Looker Studio, and pray nothing changed on the API side without warning.

That project cut my reporting time from four hours a week to near-zero, which was great. But the integration work itself took weeks. And when I wanted to swap Looker for a different visualization tool, I had to rewrite half the glue code.

This is the problem every developer hits when connecting AI models to external tools and data. Every connection is a one-off. Every integration is bespoke. And every time you change the model or the tool, you rewrite the integration.

Anthropic released the Model Context Protocol (MCP) in November 2024 to solve exactly this. They call it a USB-C port for AI applications — one standard connector that replaces a drawer full of proprietary cables. The analogy is strong, and I'll use it, but I want to be honest upfront: USB-C took years to reach critical adoption and still has cable confusion. MCP is early. The promise is real, the execution is promising, and the rough edges are real too.

What MCP Actually Is

MCP is an open-source protocol that gives AI applications a standardized way to connect to external data sources, tools, and APIs. Instead of writing a custom integration every time you want Claude to read your GitHub repos or query your database, you write (or install) an MCP server that exposes those capabilities through a single protocol. Any MCP-compatible AI client can then use that server without custom glue code.

The protocol is built on JSON-RPC 2.0 and uses a client-server architecture. Here's the mental model:

• MCP Client — lives inside the AI application (Claude Desktop, for example). It speaks the MCP protocol and discovers what tools are available.
• MCP Server — wraps your data source, tool, or API and exposes it through the MCP protocol. Each server advertises its capabilities: tools it can run, resources it can read, prompts it can provide.
• Transport — how client and server talk. Currently stdio (local process) or SSE (server-sent events over HTTP).

The spec is modular. The base protocol handles lifecycle management and capability negotiation. Authorization, specific server features, and utilities are optional layers. This means you can start minimal — a server that exposes one tool — and grow from there.

Anthropic provides SDKs for TypeScript and Python, reference server implementations (GitHub, filesystem, PostgreSQL, Slack, and more), and a developer tool called the MCP Inspector for testing servers during development. The current spec version I'm referencing is 2025-06-18.

MCP vs Function Calling: The Comparison Nobody Explains Honestly

This is where most content gets vague. Let me be specific.

Function calling (OpenAI) and tool use (Anthropic) let you define functions the model can invoke during a conversation. You describe the function schema, the model decides when to call it, and your code executes it and returns the result. It works. I've used it extensively.

But function calling is per-model, per-session. The function definitions live in your application code. If you want the same GitHub integration working across Claude, GPT, and some future model, you're rewriting the function definitions and execution logic for each one. The model providers don't share a standard for how tools are described or invoked.

MCP sits at a different layer. It's a protocol between the AI client and the tool server, not between your code and the model. The MCP server describes its own capabilities. The MCP client discovers them automatically. The model never sees MCP directly — it just sees tools available to it, same as function calling, but the integration is standardized and reusable.

Think of it this way:

• Function calling = you hand-wire a plug for every socket
• MCP = you install one standard outlet, and any compliant device can plug in

They're not competitors. MCP uses tool use / function calling under the hood. MCP is the composability layer on top. If you're building a single integration for a single model, function calling is fine. If you're building tools that should work across models and clients, MCP is the better abstraction.

The honest caveat: right now, MCP client support is strongest in Claude Desktop and the Claude ecosystem. Function calling is more broadly supported across providers. MCP is the better architecture; function calling has broader availability today. That gap will close, but it hasn't yet.

Building a Minimal MCP Server: Real Code

Enough theory. Here's a working MCP server in Python that exposes a single tool — it fetches the current weather for a city using a free API. This is the 50-line aha moment I wish existed when I started learning MCP.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("weather-server")

@mcp.tool()
async def get_weather(city: str) -> str:
    """Get current weather for a city."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            "https://wttr.in/" + city,
            params={"format": "3"}
        )
        return response.text.strip()

if __name__ == "__main__":
    mcp.run()

That's it. The FastMCP class handles the JSON-RPC 2.0 communication, capability negotiation, and tool registration. The @mcp.tool() decorator turns your function into an MCP tool with auto-generated schema from the type hints and docstring.

To run this server and connect it to Claude Desktop, you'd add this to your Claude Desktop config:

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["/path/to/weather_server.py"]
    }
  }
}

Claude Desktop starts the server process, discovers the get_weather tool via MCP, and makes it available to the model. No custom function definitions in your app code. No model-specific integration logic. The server describes itself.

Now imagine replacing weather API with internal analytics API or campaign performance database — the pattern is identical. Write once, any MCP client can use it.

Before MCP vs After MCP: A Real Developer Experience

Let me make this concrete with the ad platform dashboard I mentioned earlier.

Before MCP: I wrote separate Python modules for each ad platform's API. Each module handled OAuth, token refresh, pagination, error handling, and response parsing. Then I wrote a normalization layer to map each platform's schema to a common format. Then I wrote the pipeline that stitched everything together. If I wanted to switch from Claude to GPT as the AI layer on top of this data, I'd need to redefine all the tool schemas in OpenAI's format and rewrite the execution logic.

After MCP (and this is now real, not hypothetical): Each ad platform gets an MCP server. The Meta MCP server exposes tools like get_campaign_performance and update_budget. The Google Ads MCP server does the same with its own schema. My AI client discovers all available tools from all connected servers. If I switch from Claude Desktop to another MCP-compatible client, the servers don't change. The tools don't change. I just reconnect.

The composability gain is real — and the ad-tech ecosystem has now started arriving. Meta released an official MCP server for ads on April 29, 2026, exposing around 29 tools across performance reporting, campaign management, catalog management, and signal diagnostics. I wrote a separate deep-dive on what Meta Ads MCP actually lets you do, how to set it up safely, and why I'm not trusting it with live spend yet — the short version is that it's a genuine reporting accelerator, but the safety tooling around write operations is still thin enough that I treat it as read-only in production. Google Ads doesn't have an official MCP server yet, but the reference implementations from Anthropic (GitHub, filesystem, PostgreSQL, Slack) give you real starting points, not just hello world examples.

What's Real, What's Rough, What's Missing

I've been building with MCP enough to have opinions. Here's my honest assessment:

What's real

• The protocol spec is solid. JSON-RPC 2.0 is a proven foundation. The client-server model with capability negotiation is well-designed.
• The TypeScript and Python SDKs work. I built a working server in under an hour on my first try. The FastMCP helper makes it almost too easy.
• The MCP Inspector is genuinely useful for debugging. You can test your server's tools and responses without spinning up a full AI client.
• Reference servers (filesystem, GitHub, PostgreSQL, Slack, Brave Search) give you real starting points, not just hello world examples.

What's rough

• Authorization is still evolving. The spec defines an optional authorization layer, but it's not as mature as OAuth 2.0 flows you'd find in production APIs. Don't ship an MCP server that handles sensitive data without carefully reviewing the auth model.
• Transport limitations. The stdio transport means the client spawns your server as a local process. That's fine for desktop apps but awkward for web-based AI tools. SSE transport exists but is less battle-tested.
• Error handling and retries. The spec defines error codes, but robust retry logic, circuit breakers, and graceful degradation are on you. This is the same lesson I learned hitting OpenAI API quota limits mid-campaign: production AI systems need quota monitoring, fallback models, and cost controls from day one. MCP doesn't magically solve that.

What's missing

• Broad client support. Claude Desktop is the primary MCP client today. OpenAI has not adopted MCP. You cannot currently connect MCP servers directly to GPT. There are community projects building MCP-to-function-calling bridges, but they're not official or stable. This is the biggest gap, and it's the reason I can't honestly say MCP is a universal standard yet.
• Server discovery and registry. There's no npm or PyPI equivalent for MCP servers. You find them on GitHub or the official docs. A proper registry with versioning and trust signals would accelerate adoption.
• Production observability. If you're running MCP servers at scale, you need logging, metrics, and tracing. The protocol doesn't specify this. You'll be building it yourself.

Does MCP Work with GPT?

This is one of the most searched questions about MCP, and most answers are either vague or wrong, so let me be direct.

As of this writing, GPT does not natively support MCP. OpenAI has their own function calling and Assistants API with tool integrations. They have not announced MCP support. Anthropic created MCP, and while it's open-source and anyone can implement the client side, OpenAI hasn't.

You can build a bridge — an MCP server that translates between MCP and OpenAI's function calling format. Community projects exist for this. But it's glue code, and it undermines the write-once-run-anywhere promise. The whole point of a standard is that you don't need adapters.

Will OpenAI adopt MCP? I don't know. It would benefit the ecosystem, but it would also reduce lock-in to OpenAI's proprietary tool ecosystem. I'm not holding my breath, but I'm also not ruling it out. The industry trend toward open standards is real, even if the pace is slow.

Why MCP Matters Despite Being Early

I've been critical of MCP's current state because I think honest assessment beats hype. But I'm also genuinely excited about where this is going, and here's why:

1. The composability problem is real and unsolved. Every AI application that connects to external tools is reinventing the integration layer. MCP is the first credible attempt at standardizing it. Even if the current implementation is incomplete, the architecture is right.

2. The write-once-reuse-everywhere promise is powerful. When I built SimpleAIFolio, I wanted it to work with multiple AI providers without vendor lock-in. MCP would have made that easier — define your content management tools as MCP servers, and any compatible AI writing assistant can use them. I built it without MCP, and it works, but the integration layer is custom code I maintain alone.

3. Local-first development gets easier. With OpsConsole, I learned that local-first architecture beats cloud-first for developer tools. MCP's stdio transport fits this perfectly — your tools run locally, your data stays local, and the AI client connects through a standard protocol. No cloud dependency for the tool layer.

4. The ecosystem is growing, not shrinking. Anthropic is investing in SDKs, reference implementations, and developer tools. The community is building servers. Google Cloud published an MCP guide. Meta shipped an official ads MCP server. These are early signals of a protocol gaining traction, not losing it.

Should You Build with MCP Today?

Yes, with caveats.

If you're building internal tools, developer productivity features, or anything that connects AI to your existing APIs and data, start experimenting with MCP now. The SDKs are stable enough. The development experience is good. And when the ecosystem matures, you'll already have servers ready to connect.

If you're building a product that needs to work across multiple AI providers today, MCP alone won't get you there — you'll still need function calling integrations for non-Anthropic models. Use MCP for your Anthropic integrations and function calling for the rest, with an abstraction layer in between. It's not elegant, but it's honest.

If you're a marketer rather than a developer, the more relevant question is what MCP unlocks for ad operations. For that, read my practical walkthrough of Meta Ads MCP setup, safety, and production readiness — it covers what the protocol actually lets you do with live campaigns and where it still breaks down.

If you're just curious, build the weather server example above. It takes 15 minutes, and you'll understand the protocol better than reading any blog post (including this one).

The USB-C analogy works because it captures the aspiration: one connector, every device. USB-C took a decade to get there. MCP is moving faster, but it's still early. The developers who learn it now will be the ones building the ecosystem everyone else relies on later.

Related Reading

• Meta Ads MCP: Setup, Safety & Production Readiness — my deep-dive on Meta's official MCP server for ads, including what it exposes, how to configure it in Claude Desktop, and why I'm holding back on write access for live spend.
• Meta Advantage+ Campaigns in 2026: When Full AI Automation Works (and When It Burns Money) — how Meta's AI ad automation compares to MCP-driven conversational ad operations.
• Google Performance Max: How to Actually Control the AI Black Box — the control problem on Google's side, where MCP-style tooling doesn't yet exist.

References

• MCP Official Introduction — canonical definition and use cases
• MCP Architecture Overview — client-server model, core concepts
• MCP Specification (2025-06-18) — JSON-RPC 2.0 base protocol, modular components
• Anthropic MCP Announcement — origin and motivation
• Google Cloud: What is MCP? — industry perspective beyond Anthropic

Frequently Asked Questions

• How is MCP different from OpenAI function calling?

  Function calling defines tools inside your application code, per model, per session. MCP is a protocol between an AI client and a tool server — the server describes its own capabilities, and any MCP-compatible client can discover and use them. MCP actually uses function calling under the hood; it's a composability layer on top, not a replacement. Use function calling for single-model integrations; use MCP when you want tools to work across multiple AI clients.

• How do I set up an MCP server for Claude?

  Install the Python SDK with pip install mcp, create a server using FastMCP, decorate your functions with @mcp.tool(), and add the server to your Claude Desktop config JSON under mcpServers. Claude Desktop will start the server process, discover your tools via the MCP protocol, and make them available to the model. The minimal working example in this article takes about 15 minutes to build.

• Does MCP work with GPT or non-Anthropic models?

  As of this writing, no. OpenAI has not adopted MCP, and GPT does not natively support it. Community projects exist that bridge MCP to OpenAI's function calling format, but they're unofficial and add complexity. MCP is strongest in the Claude ecosystem today. Cross-provider support is the biggest gap in MCP's current state.

• Is MCP ready for production use?

  For internal tools and developer productivity features, yes — with caution. The SDKs are stable, the protocol spec is solid, and the development experience is good. But authorization is still maturing, there's no server registry for discovery, and production observability (logging, metrics, tracing) is on you. Don't expose MCP servers handling sensitive data to the internet without a thorough security review.

• What problems does MCP solve that custom integrations don't?

  Composability and reusability. With custom integrations, every AI-to-tool connection is bespoke — you rewrite it when you change models, change tools, or want to share integrations across projects. With MCP, you write a tool server once and any MCP-compatible client can use it. The server describes itself, so there's no manual schema definition in your app code. It's the difference between hand-wiring every plug and installing a standard outlet.

• Is there an official MCP server for Meta Ads?

  Yes. Meta released an official MCP server for ads on April 29, 2026. It exposes around 29 tools covering performance reporting, campaign management, catalog management, and signal diagnostics, and connects via OAuth rather than the traditional Marketing API app review. For setup steps and a frank safety assessment, see my Meta Ads MCP setup, safety, and production-readiness guide.