DEV Community

Devanshu Biswas
Devanshu Biswas

Posted on

M N integrations collapse to M+N — the Model Context Protocol is USB-C for AI tools, and it's just JSON-RPC underneath

#agents #ai #llm #mcp

Before MCP, wiring an AI app to a tool was bespoke every single time. Every app hand-wrote its own connector for every tool it wanted to reach: M apps × N tools = M×N pieces of glue, none of it reusable. The Model Context Protocol — an open standard from Anthropic (2024) — collapses that mess to M+N. It's the USB-C-for-AI framing, and building a visualizer for the actual message flow is what made it concrete for me. Here's the shape of it.

Host, client, server

Three roles, and the naming trips people up, so pin it down:

  • Host — the AI app itself: Claude Desktop, an IDE, a custom agent. It holds the model.
  • Client — a connector inside the host that keeps a 1:1 connection to one server. One client per server.
  • Server — a separate process that exposes some capability (your filesystem, GitHub, a database) over a uniform protocol.

Write a server once and every MCP host can use it. Write a client once and it can talk to every server. That reuse — a server built for Claude Desktop working unchanged in an IDE and a bespoke agent — is the entire M+N payoff.

A server exposes three kinds of thing

Not just tools. An MCP server can advertise three capability types, and the distinction is about who controls each:

  • Tools — actions the model can invoke (write_file, run_query). Model-controlled.
  • Resources — read-only data addressed by URI (file:///path, a row). App-controlled.
  • Prompts — reusable templates the user can pick. User-controlled.

The client discovers them with tools/list, resources/list, prompts/list, and invokes them with tools/call or resources/read.

It's JSON-RPC on the wire

Every message is a plain JSON-RPC 2.0 envelope. A one-time lifecycle handshake (initialize) opens the connection; a discovery round (tools/list) tells the host what's available; then the use loop repeats whenever the model needs the tool:

1. initialize            host ↔ server handshake, capabilities exchanged   (once)
2. tools/list            client asks what the server offers                (once)
3. user asks a question
4. model decides to call a tool
5. tools/call            client → server, real code runs
6. result               server → client → model
7. model writes the answer
Enter fullscreen mode Exit fullscreen mode

Discovery happens once; after that the host just issues tools/call whenever the model decides to. The transport is stdio for a local server or HTTP for a remote one — same protocol either way.

It's built on function-calling, not instead of it

This is the point people miss. MCP does not replace plain function-calling. The model still emits a structured tool call, exactly as it always did. What MCP standardises is everything around that call: how the tool is discovered, how the request is transported, and how the result comes back. Function-calling is the model saying "call this with these args"; MCP is the interoperable plumbing that makes the same tool reachable from any app without rewriting glue. That's why one MCP server drops into Claude Desktop, an IDE, and your own agent alike — the tool definition is written once, and the protocol carries it everywhere.

Why the M+N math actually pays off

The collapse from M×N to M+N isn't just tidier arithmetic — it changes who does the work. Under the old model, if you built a new AI app you owed a connector to every tool your users wanted, and if you built a new tool you owed a connector to every app. Both sides scaled with the other side's growth. Under MCP, a tool author writes exactly one server and is done — every current and future host can reach it. An app author writes one client and inherits the whole existing catalogue of servers for free. The network effect runs the right way: each new server makes every host more capable, and each new host makes every server more valuable, with nobody rewriting glue to get there.

So the mental model is small: a host runs one client per connection, each client speaks JSON-RPC to a server that advertises tools, resources and prompts, discovery is */list and use is */call. Turn M×N bespoke connectors into M+N reusable ones and you get an ecosystem instead of a pile of one-off adapters. Pick a server and watch every JSON-RPC message cross the wire, step by step:

https://dev48v.infy.uk/ai/days/day51-model-context-protocol.html

Top comments (0)