DEV Community

Nicolas Fainstein
Nicolas Fainstein

Posted on

Why MCP Is the TCP/IP of AI Agents

#webdev

TL;DR

  • TCP/IP solved the problem of incompatible networks. MCP solves the problem of incompatible AI tools.
  • Before MCP: every AI app reinvented tool calling from scratch.
  • After MCP: build a tool once, every AI agent can use it.
  • The parallel to TCP/IP reveals why MCP matters more than most developers realize.
  • And why the monetization layer that sits on top of MCP is more valuable than people expect.

In 1973, Vint Cerf and Bob Kahn published a paper describing a protocol for transmitting data between heterogeneous networks. The key insight wasn't technical — it was architectural. Instead of building a single universal network, they created a protocol that let any networks communicate.

TCP/IP was boring. It didn't do anything interesting on its own. It just defined how packets moved from A to B, regardless of what kind of network A and B were.

Fifty years later, that boring protocol underlies every text message, every video call, every purchase, every search, every AI API call.

The Model Context Protocol is the TCP/IP of AI agents. Here's why that analogy holds up technically — and why it matters for anyone building in this ecosystem.

The Problem MCP Solves

Before MCP, every AI application that needed to use external tools had to solve the same problems from scratch:

  1. How do I describe what tools are available to the AI?
  2. How do I pass tool call results back to the model?
  3. How do I handle errors, retries, and timeouts?
  4. How do I authenticate with tool providers?
  5. How do I stream results for long-running operations?

Every team building with Claude, GPT-4, or Gemini answered these questions differently. Anthropic's function calling format was incompatible with OpenAI's. OpenAI's tool call format evolved between GPT-3.5 and GPT-4. Companies building internal AI tools had to maintain custom integrations for every model they used.

This is exactly the problem TCP/IP solved for networks. In the early 1970s, ARPAnet, Ethernet, and packet radio networks couldn't talk to each other. Each had its own packet format, addressing scheme, and error handling. Connecting them required custom translation layers that were brittle and expensive.

TCP/IP didn't make any single network better. It created a common language that let all of them communicate.

What MCP Actually Specifies

MCP is a wire protocol. It specifies:

Transport layer: MCP runs over stdio (for local tools) or HTTP with Server-Sent Events (for remote tools). Both are standardized; you can switch between them without changing your tool logic.

Message format: JSON-RPC 2.0. Every message has a method, params, and id. Responses have a result or error. No surprises.

Capabilities negotiation: When an AI agent connects to an MCP server, they exchange capability lists. The server says "I have these tools, these resources, these prompts." The client says "I support these features." This prevents incompatibilities at the protocol level.

Tool schema: Tools are described with JSON Schema. The AI model reads the schema and knows exactly what parameters to pass, what types to use, and what the tool returns. No guessing.

Lifecycle management: MCP specifies initialization, shutdown, and error handling. A well-implemented MCP server never crashes an AI agent's session because of a bad tool call.

// What MCP tool registration looks like
server.tool(
  "search_web",
  "Search the web and return relevant results",
  {
    query: z.string().describe("Search query"),
    max_results: z.number().optional().default(10),
  },
  async ({ query, max_results }) => {
    const results = await webSearch(query, max_results);
    return {
      content: [{ type: "text", text: JSON.stringify(results) }],
    };
  }
);
Enter fullscreen mode Exit fullscreen mode

That's it. Any MCP-compatible client — Claude Desktop, Cursor, Windsurf, or your own implementation — can discover this tool and invoke it correctly.

The TCP/IP Parallel, In Detail

Abstraction Over Transport

TCP/IP abstracts over physical networks. You don't care if data travels over fiber optic, copper wire, or WiFi — TCP/IP handles the translation.

MCP abstracts over AI models. You don't care if the AI is Claude 3.5, GPT-4o, or Gemini Pro — MCP handles the translation. Write your tool once, every model can use it.

Network Effects

TCP/IP created network effects at the infrastructure level. Each new network that adopted TCP/IP became accessible to all existing TCP/IP networks. The value grew exponentially with adoption.

MCP is doing the same. Each new tool added to the MCP ecosystem becomes accessible to all MCP-compatible AI agents. Each new AI agent that adopts MCP can immediately use all 16,000+ existing tools.

At some point, not supporting MCP will feel like not supporting TCP/IP — unthinkable.

Layered Architecture

TCP/IP established a layered model. TCP handles connection management and error recovery. IP handles routing. Ethernet handles the physical link. Each layer does one thing and does it well.

MCP has a similar layered architecture:

  • Transport layer: stdio or HTTP+SSE
  • Protocol layer: JSON-RPC 2.0 with MCP semantics
  • Application layer: your tools, resources, and prompts
  • Business layer (emerging): monetization, auth, analytics

That last layer — the business layer sitting on top of MCP — is where the economic opportunity lives.

Standards Enable Ecosystems

HTTP sat on top of TCP/IP and created the web. SMTP created email. FTP created file sharing. These weren't innovations in the protocol itself — they were applications that the protocol made possible.

MCP's application layer is still being built. The tools are the HTTP of this stack. Monetization infrastructure is the e-commerce layer. What gets built on top of MCP over the next five years will be as surprising as what got built on top of TCP/IP.

Why This Matters More Than "Another API Standard"

The obvious critique: "MCP is just another API standard. We've had dozens of those. Why would this one matter?"

Fair. Most API standards don't achieve critical mass. They serve a niche and disappear.

MCP is different for three reasons:

1. Backing and distribution matter. Anthropic built MCP into Claude Desktop and the official SDK from day one. Cursor, Windsurf, and other AI-native IDEs added support quickly because their power users demanded it. Standards backed by strong ecosystem players reach critical mass differently than committee-designed standards.

2. Timing matters. MCP arrived at the moment when AI agents were becoming the primary interface for many developers. The tool-calling problem was acute and unsolved. There was a real vacuum.

3. Openness matters. The MCP spec is open. Anyone can implement a server or client. This is crucial for ecosystem growth. Closed standards create monopolies. Open standards create ecosystems.

The comparison to TCP/IP isn't hype — it's structural. Both solve the same category of problem (interoperability between heterogeneous systems) at a moment when the industry desperately needed the solution.

The Business Layer: What TCP/IP Didn't Have

Here's where the TCP/IP analogy breaks down in an interesting way.

TCP/IP was purely technical. It moved packets without understanding their business value. Google AdSense was invented 30 years after TCP/IP to monetize what TCP/IP enabled. The financial infrastructure layer (SSL for e-commerce, Stripe for payments, etc.) took decades to mature.

MCP has an opportunity to build the business layer faster. The ecosystem is young enough that monetization infrastructure can be designed into the foundation, not bolted on decades later.

This is what projects like agentic-ads are doing — building the AdSense layer for MCP. Contextual advertising that works through the AI agent protocol rather than around it. Developer-controlled, privacy-first, and integrated at the tool-response level where context is richest.

The developers who build tools now and establish monetization patterns early will have an enormous advantage. Not because of first-mover luck, but because they'll have data, users, and learned distribution strategies while latecomers are still figuring out the basics.

What to Build

If you're convinced MCP is the protocol layer for the AI era, the question is: what's the equivalent of HTTP, SMTP, or e-commerce built on TCP/IP?

High-value tool categories (the HTTP of MCP):

  • Financial data APIs (real-time market data, financial records)
  • Database interfaces (natural language SQL, query optimization)
  • Security tools (code scanning, vulnerability detection)
  • Compliance and legal tools (contract analysis, regulatory checking)

Infrastructure layers (the DNS, CDN of MCP):

  • Tool registries and discovery services
  • Authentication and authorization for MCP servers
  • Usage metering and billing infrastructure
  • Analytics and observability for tool calls

Application-layer products (the web apps of MCP):

  • Vertical AI agents powered by specialized MCP tools
  • Workflow orchestration across multiple MCP servers
  • Enterprise MCP tool management and governance

The protocol is in place. The ecosystem is forming. The business layer is early.

This is what TCP/IP looked like in 1985 — technically solid, commercially unexplored. The developers who understood what it enabled and built for it became the architects of the modern internet.

The Honest Caveats

TCP/IP analogies can be misleading. A few things that might not parallel:

MCP might not win. OpenAI's Realtime API and Google's Gemini tool-use could establish competing standards. If multiple standards survive with significant market share, the network effects fragment. TCP/IP won because the US government mandated it for ARPAnet in 1983 — MCP has no equivalent forcing function.

The AI agent market might not grow as fast. All of this assumes AI agents become pervasive. If the technology plateaus or the market is smaller than expected, MCP tooling remains a niche.

Open source cuts both ways. Open standards create ecosystems but also commoditize infrastructure. The companies that made money from TCP/IP were those who built applications, not the protocol itself. Same dynamic likely applies to MCP.

The Bet

The TCP/IP parallel is ultimately a bet: that AI agents become as pervasive as browsers, that MCP (or something like it) becomes the universal language of agent-tool interaction, and that building tools early creates durable advantages.

If you believe that bet, the implication is clear. The window to establish yourself in the MCP ecosystem — to build useful tools, understand monetization, develop distribution — is open and closing.

The protocols that matter are recognized in hindsight. In 1980, TCP/IP was a government research project. In 1990, it was infrastructure most companies didn't think about. In 2000, it was the foundation of a $1.5T internet economy.

We are somewhere in 1980 for MCP. Act accordingly.

Building MCP tools? The agentic-ads SDK adds contextual monetization to any MCP server in 20 lines of code. Open source, 70/30 revenue split, privacy-first.

Questions or disagreements? I want to hear them: GitHub Discussions

Top comments (0)