The Model Context Protocol, Explained: Why Tools Are the New APIs
If you've followed AI agent development at all, you've run into the acronym MCP — the Model Context Protocol. It's become the default way AI agents connect to external tools and data sources, and it's the protocol Xibrary is built on. But the name doesn't explain itself, so here's the plain version: what MCP actually is, and why it matters more than it sounds like it should.
The problem MCP solves
Before a standard like MCP existed, every AI application that wanted to connect to an external tool — a database, a file system, a search index — had to build a custom integration for it. Multiply that by every tool and every AI application, and you get an N×M integration problem: every agent needs custom glue code for every tool it wants to use. That doesn't scale, and it's exactly the problem USB solved for hardware two decades earlier — one standard connector instead of a different cable for every device.
MCP is that standard connector for AI agents. It defines a common way for a "server" (a tool, like Xibrary) to describe what it can do, and for a "client" (an AI agent, like Claude) to discover and call those capabilities, without either side needing custom code for the other. Build one MCP server, and any MCP-compatible agent can use it — that's the whole point.
Anthropic's original announcement described it plainly: MCP is "a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments" — see Anthropic's introduction to the Model Context Protocol. It's worth noting this hasn't stayed an Anthropic-only standard — Google Cloud has since announced official MCP support for its own services, which is exactly the cross-vendor adoption a standard like this needs to actually solve the integration problem instead of just relocating it.
How it's different from a REST API
A REST API is designed for a developer to read documentation and write code against it. An MCP server is designed for an AI agent to read a tool's name and description at runtime and decide, on its own, whether and how to call it. That's a real design constraint, not a technicality — it means the description text of an MCP tool isn't just documentation, it's the interface the agent reasons over to decide what to do. Write a vague tool description and a capable agent will still misuse or ignore your tool, the same way a person will bounce off a confusing UI.
This is part of why we think about MCP tool design the way we think about game design — good affordances, honest feedback, no ambiguity about what a thing does. We wrote more about that specific parallel in what game design teaches you about designing for AI agents.
Why Xibrary is MCP-first
Xibrary exposes two tools over MCP — search_parts and get_part_specs — alongside a plain REST API for anything that isn't yet MCP-native. We built MCP-first on purpose: the whole premise of Xibrary is that AI agents, not people, are the primary users making the sourcing decision, and MCP is the protocol built specifically for that relationship. It's a small, concrete example of a much bigger shift we think is underway — agentic commerce, where more and more purchasing and sourcing decisions get made by an agent acting on a human's behalf rather than the human doing it directly.
Tools are the new APIs
The bigger claim underneath all of this: as AI agents become the primary consumers of more software, "does this have a good MCP tool" starts to matter as much as "does this have a good API" did in the last decade of software. That's not a small shift for anyone building developer infrastructure — it's a new audience with different needs, different failure modes, and a different definition of what "good documentation" even means. We built Xibrary as a bet that taking that audience seriously, early, is worth it.