MCP Was Always Going to Be USB-C — A Practical Guide to the Model Context Protocol

When the MCP spec dropped last November, I left one line in our company Slack:

"It's USB-C."

That was, basically, my whole review. Six months of writing and rewriting tool adapters has not pulled me away from that one line. It has, however, given me more to say about why it matters.

What MCP was actually trying to fix

Letting LLM agents call external tools wasn't new. OpenAI's function calling, Anthropic's tool use, the whole tool abstraction in LangChain — all viable since 2023. They were all the same shape: the model emits some JSON and we run it.

The problem was that the abstraction was subtly different per model, per tool, and per client. A GitHub adapter we built for one agent didn't transfer to another. Our JIRA adapter was a different codebase. The same GitHub adapter for an OpenAI model wasn't quite the one Claude wanted.

Sixty percent of the code we shipped was adapters of adapters. The actual logic was the other forty.

What MCP did was simple. It put a common protocol between models and tools.

Before:                                After:

[Model A] ──── [Tool X adapter]        [Model A] ──┐
[Model A] ──── [Tool Y adapter]                    ├── [MCP client]
[Model B] ──── [Tool X adapter']                   │       │
[Model B] ──── [Tool Y adapter']       [Model B] ──┘       │
                                                           ▼
N models × M tools = N×M adapters     [MCP server: Tool X]
                                       [MCP server: Tool Y]

                                       N + M

The USB-C analogy holds because old phones had different chargers. Now you carry one cable.

The one-line definition

MCP (Model Context Protocol) is an open protocol standardizing how an LLM client (model or agent host) talks to external tools and data sources. Any tool server that speaks the protocol is reachable by any client without writing per-pair adapters.

The three load-bearing words: open, protocol, without per-pair adapters.

The traps that bit us

Trap 1 — "one tool" as a unit

Early on we made a separate tool per capability: create_issue, comment_on_issue, assign_issue, close_issue. We had about thirty tools before models started getting confused about which to pick.

The fix was coarser tools with the operation expressed in the input schema. One manage_issue tool, with action: "create" | "comment" | "assign" | "close". Thirty tools collapsed to one. Selection accuracy went up visibly.

Trap 2 — the spec is silent on authority

MCP defines the protocol. It does not define who can call what. That's by design — it's not the protocol's job. But if you don't solve that somewhere else, you will have an incident.

We solve it above the protocol, in our execution layer. The MCP server only exposes the surface. Authorization comes from roles and scopes on the graph. → What CollabOps means by execution layer

Trap 3 — tool descriptions burning context

Long descriptions eat context tokens. Expose 50 tools, your system prompt is now 8K tokens before any work starts. The agent has nowhere to think.

We write descriptions in two layers. A one-line summary the model sees while choosing tools, and a longer detail it only sees once it has committed to invoking that tool. Not in the spec — but the client can fake it.

Why MCP turned out to be decisive for DevOps agents

Three reasons.

Tool diversity. A DevOps agent in production touches git, CI, JIRA, Slack, Datadog, PagerDuty, Kubernetes — sometimes in one workflow. Writing N×M adapters does not scale operationally.

Per-customer tool mix. Our customers run different combinations: GitHub, GitLab, in-house git servers. MCP lets us swap the tool bundle per deployment without touching the agent host.

On-prem isolation. MCP servers ship inside the customer's perimeter. The model can run in our cloud while the actual tool calls terminate inside the customer. Nothing leaves their boundary. → Building CI/CD inside an air-gapped datacenter.

The third one mattered most. Public-sector and finance customers verify data boundaries down to the cert level. Without MCP we would have invented a similar isolation protocol — but it would have been our dialect, not a standard.

Two confusions worth clearing up

"MCP is another LLM framework." It's not. A framework is code. MCP is a protocol. You can use it without any framework.

"MCP replaces LangChain." Different layers. LangChain operates at the agent host layer. MCP is the host ↔ tool wire protocol. They compose.

MCP pays off fastest for teams whose LLM-agent codebase already feels heavy with adapter code. It's just as decisive if you're deploying agents into enterprise or on-prem environments, where tool calls terminating inside the customer's data boundary is often the deciding line in a security review.

If your team is new to LLMs, there's no rush. Get comfortable with the general shape of tool use first; MCP becomes more legible once you've felt the N×M pain.