# Your AI doesn't need another API, it needs a toolbox
> Why Model Context Protocol matters less because of the protocol itself and more because it solves a problem every engineering organisation eventually encounters.
By Matthew D. Webb · 2026-01-17 · 8 min read
Canonical: https://mdwebb.io/articles/your-ai-doesnt-need-another-api/
AI involvement: Used to draft and revise this article, images, diagrams and the interactive demo included.
---
The software industry has a real gift for reinventing a familiar idea and then arguing for six months about whether it's a revolution.
Model Context Protocol, or MCP, has a touch of that about it. Depending on who you ask, it's either the future of AI integrations or just another protocol destined to become a colourful box on an architecture diagram. The truth, as usual, is a good deal less dramatic.
What makes MCP interesting isn't that it gives software a new way to talk to other software. Engineers cracked that one decades ago: APIs, message queues, RPC, event streams, take your pick. Nobody is suffering from a shortage of integration technologies.
The problem MCP is actually pointing at is a different one. AI systems are increasingly expected to *do things*, not just generate text. They need to reach repositories, docs platforms, ticketing systems, databases, observability tooling, internal services. The moment you move past a chatbot answering questions, the whole game becomes one of context and capability, and at that point the model itself is often the least interesting component in the room.
## The difference between knowing and doing
Large language models are remarkably good at producing a plausible response. What they are not good at is getting at information they were never trained on.
Take a deceptively simple question:
> What is the current deployment status of our checkout service?
A model cannot answer that from training data. The answer exists *somewhere* in your organisation: GitHub Actions, ArgoCD, Jenkins, Datadog, some bespoke internal platform with a name only three people remember. Generating the sentence was never the hard bit. Reaching the source of truth is.
This is where most enterprise AI efforts start: information retrieval. You wire the model up to docs, knowledge bases and support content, it answers questions competently, and everyone is pleased for a fortnight. Then, inevitably, someone asks a more interesting question.
Can the AI raise a Jira ticket? Can it read the production logs? Can it review a pull request? Can it restart a service? Can it query a database?
And the problem changes shape entirely. The model no longer needs information; it needs tools.
## We have seen this problem before
Part of why MCP feels so familiar to anyone who's been around a while is that the underlying problem is not new. Every successful platform eventually grows a standard way of reaching capabilities beyond its own walls. Operating systems got plugin architectures, browsers got extensions, IDEs got plugins, cloud platforms got APIs.
The details differ; the pattern is almost monotonously consistent. A platform gets more useful the moment it can reach past its original boundaries, and AI systems are now having exactly that growth spurt.
The snag is that every integration drags complexity along with it. Without some standardisation, every AI application ends up writing bespoke glue for every service it wants to touch. Each one speaks a slightly different dialect, with its own auth, shapes and footguns:
```ts
// Without a shared protocol, every client learns every tool's dialect by hand.
const github = new GitHubClient(githubPat); // REST + personal access token
const jira = new JiraClient(jiraOAuth); // REST + OAuth2
const confluence = new ConfluenceClient(confluenceKey); // yet another auth
const slack = new SlackClient(slackToken); // events + webhooks
// …and your AI app has to understand all four. Add a fifth tool? Write a fifth adapter.
```
GitHub needs one implementation. Jira needs another. Confluence another. Slack another. The internal systems need a dozen more between them. You can see how quickly that gets out of hand. It's the same N×M integration sprawl every platform team has fought before, only now it's a model doing the integrating.
MCP's proposal is almost suspiciously simple: instead of teaching every AI client how to talk to every possible tool, teach the tools how to present themselves through a common interface. A tool describes itself *once* (its name, what it does, the arguments it expects) and any compliant client can call it:
```ts
// With MCP, a tool describes itself once; any client can discover and call it.
server.registerTool(
"deployment_status",
{
description: "Current deployment status for a given service",
inputSchema: { service: z.string().describe("service name, e.g. 'checkout'") },
},
async ({ service }) => {
const status = await platform.getDeploymentStatus(service);
return { content: [{ type: "text", text: JSON.stringify(status) }] };
},
);
```
The interesting part was never the protocol design. It's the interoperability, and what that does to the wiring. Point-to-point, the number of integrations you own grows as clients × tools. Route everything through one interface and it grows as clients + tools instead. The difference sounds academic until you drag the sliders:
## Why organisations will build MCP servers
Most of the chatter about MCP is about *consuming* public tools. I suspect the more interesting use case is *exposing* internal ones.
Every large organisation hoards systems that are valuable and a pain to reach. Internal APIs. Deployment platforms. Customer support tooling. Analytics. Feature flags. Inventory. Fraud. The operational dashboards nobody outside one team knows exist.
Most of these already expose an API. The problem is that every one of them looks different: different auth, different data shapes, documentation ranging from "excellent" to "a Confluence page last touched in 2019". So bringing a new tool into an AI workflow gets expensive, fast.
An MCP layer gives you a standard way to expose those capabilities once and let multiple clients consume them, instead of teaching every application how to negotiate with twenty internal systems individually. The architecture gets noticeably simpler, and in most enterprises the internal services comfortably outnumber the public ones, so that's where the saving actually lands.
## Why this matters for engineering teams
The most useful applications here are deeply unglamorous. In fact most of them sound exactly like the day job:
> Show me the open production incidents affecting payments.
Or:
> Find the deployment that introduced this error.
Or:
> Summarise the changes merged into checkout last week.
Or:
> Create a Jira ticket for every failed synthetic test in the last 24 hours.
Not one of these needs artificial general intelligence. They need *access*, and a way to turn a question into an action without the model ever touching the system directly.
And that's where a lot of the real value currently sits. The industry has spent a fortune debating model capability and comparatively nothing on operational capability, which is odd - a brilliant model with no reach into your systems is routinely less useful than a mediocre one with excellent tooling. The binding constraint usually isn't intelligence. It's connectivity.
## The governance question arrives quickly
The instant you start exposing operational capabilities to AI, governance walks in. There's no avoiding it.
Reading information is one thing. Taking actions is quite another. An assistant that can create a ticket is fairly low-stakes. An assistant that can approve a production deployment is a different conversation entirely, and the questions come thick and fast. Who can use which tools? What actions are allowed? How is any of this audited? How is sensitive data protected? How are permissions inherited?
The good news is that none of this is genuinely new. The industry has spent decades building [identity, access control, audit trails and governance models](/articles/trust-but-verify/). MCP doesn't make those obsolete. If anything, it makes them matter more. The job is no longer just securing *human* access to systems. It's securing machine-assisted access too - the same problem with rather higher stakes.
## Why the protocol matters less than the ecosystem
The most important thing to understand is that MCP itself isn't especially revolutionary. Protocols rarely are. HTTP wasn't interesting because of the spec; it mattered because of everything that grew up around it.
Same principle here. If MCP succeeds, it won't be because engineers got excited about protocol design (they won't); it'll be because enough tools, platforms and organisations settle on a common way of exposing capability. Standardisation is rarely exciting. It is almost always extremely valuable. The history of software is, to a large extent, just the history of standardisation that won.
## The future is tool-rich, not model-rich
[Most of the AI conversation is still fixated on models](/articles/what-ai-adoption-actually-looks-like/). Which one's best? Which benchmark nudged up? Which vendor shipped what this week? Those questions matter, but they matter a little less every month.
The more interesting question is:
> What can the model actually *do*?
And answering that depends on tooling far more than on raw intelligence. The enterprise AI assistant that earns its keep won't be the one that writes the most eloquent prose. It'll be the one that can reach into the systems the business already runs on every single day.
Through that lens, MCP stops looking like yet another integration standard and starts looking like foundational infrastructure. Not glamorous. Not revolutionary. Just one of those load-bearing ideas that ends up so normal nobody bothers talking about it anymore. And that, if you've been paying attention, is exactly how you can tell it worked.
## A postscript that practises what it preaches
Since writing this, the argument has grown a working example: the site you're reading runs its own MCP server at `https://mdwebb.io/mcp/`. Point any MCP client at it (streamable HTTP, stateless, no auth) and you get six read-only tools covering the articles, the CV, the projects and the reading list, queryable without scraping a single page. The whole thing is one route handler and no dependencies, which rather proves the essay's point at a jog: the capability was never the hard part, the plumbing was. There's also a plain-text map at [/llms.txt](/llms.txt) for agents that prefer to read the old-fashioned way.
## Further reading
- [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol): Anthropic's original announcement, and the cleanest statement of the problem MCP set out to solve.
- [MCP architecture overview](https://modelcontextprotocol.io/docs/learn/architecture): the client-server model, primitives (tools, resources, prompts) and a worked tools/list and tools/call exchange if you want the wire-level detail.
- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents): a sober take on agent patterns that argues for simple, composable building blocks over heavy frameworks.
