MCP and the New Shape of AI Tools
Model Context Protocol is being called 'USB-C for AI,' which is accurate but undersells it. A closer look at what it actually changes — and what it doesn't.
In 2016, Microsoft's team built something called the Language Server Protocol. LSP is unglamorous: a specification for how editors and language analysis tools should talk to each other over JSON-RPC. It doesn't compile code or run tests. It just standardizes a conversation.
But before LSP, if you wanted autocomplete and go-to-definition and inline type errors for TypeScript, you had to build those features into each editor separately. A plugin for VS Code, a different one for Vim, another for Emacs. The same logic, written four times. After LSP, you write the language server once, and any editor that speaks the protocol gets the features for free.
Eight years later, most developers use LSP-powered features constantly without knowing the acronym. That's not a failure of marketing. It's what success looks like for infrastructure.
Model Context Protocol was announced by Anthropic on November 25, 2024. It was built by two engineers — David Soria Parra and Justin Spahr-Summers — out of a specific frustration: Claude Desktop had no way to be extended. You couldn't connect it to your filesystem, your calendar, your code. Every tool that wanted AI integration was writing its own connector, and every AI application was writing its own plugin layer. The integration count grew as the product of the two: M models times N tools means M×N bespoke connectors.
MCP collapses that to M+N. If your tool speaks MCP, any AI that speaks MCP can use it. If your AI speaks MCP, any tool that speaks MCP is available to it. The math is simple. The engineering effort is not.
What it actually is
MCP is a protocol, not a product. It specifies how an AI client should request capabilities from an external server, how that server should describe its available tools, and how results should flow back. It's built on JSON-RPC 2.0 — the same transport mechanism LSP uses. The parallel is not accidental. Parra had worked on LSP before.
An MCP server exposes tools. A tool is a named function with a typed input schema and a return type. The AI calls it by name with arguments. The server does the work and returns a result. Nothing about this is magic. It's closer to a well-typed REST API than to anything resembling reasoning.
What makes it interesting isn't the protocol itself. It's what happens when enough things implement it.
By April 2025, there were over 5,800 MCP servers available. GitHub, Stripe, Notion, Hugging Face — all with servers. OpenAI adopted the protocol in March 2025. Google DeepMind followed. By December 2025, Anthropic had donated MCP to the Linux Foundation under the Agentic AI Foundation, a move co-signed by Block and OpenAI. At that point it stopped being Anthropic's protocol and started being the protocol.
What it changes for personal tools
The most underappreciated use case isn't enterprise integration. It's personal software.
Before MCP, if you wanted an AI to access your notes, your calendar, your task list, you were either uploading files manually into a chat window or relying on one of the walled gardens that had prebuilt integrations with their own models. There was no clean way to tell Claude: here is my knowledge base, here is my calendar — use them together.
MCP makes that composability possible. Not because it's novel technology, but because it's a shared language. When a personal knowledge base exposes a public MCP endpoint, it means any MCP-capable AI client — Claude, ChatGPT, something not invented yet — can search your documents, propose a patch, or pull context before answering a question. The knowledge base isn't locked to one vendor's ecosystem. It's available to whatever tool you trust.
That's worth sitting with. The implication isn't just convenience. It's that the useful parts of your digital life — your notes, your people, your calendar — could become connectable to the AI tools you actually use, rather than only the tools a single vendor decided to support.
What it doesn't solve
MCP solves the connection problem. It doesn't solve the trust problem.
A well-formed MCP server still needs permissions, approval policies, and audit logs. The protocol says nothing about what an AI is allowed to do with the tools it calls. A server that exposes delete_all_documents without access control is just as dangerous when it speaks MCP as it would be with a proprietary integration. The standard gives you a clean interface; what you put behind that interface is still your responsibility.
There's also a subtler issue: typed schemas require actually thinking about what your tool does. Vague APIs produce vague AI behavior. Writing a good MCP server turns out to be an exercise in precision — you have to name things carefully, type your inputs, decide what error states mean. That's useful discipline. It's also more work than most teams initially expect.
Infrastructure has a way of disappearing
The USB-C analogy is everywhere in MCP coverage. It's apt, but the more useful comparison might be LSP — because LSP succeeded quietly. Nobody threw a party when Vim finally supported TypeScript autocomplete through a language server instead of a bespoke plugin. It just worked, and then it kept working, and eventually nobody thought about it at all.
That's where MCP is going. Not "AI agents can use tools" as a headline feature. Just: the systems you care about are connected to the AI tools you use, without anyone having to rebuild the integration each time a new model ships.
The interesting question isn't what MCP makes possible right now. It's what gets built once the protocol is boring — once it's assumed to be there, like HTTP, invisible and everywhere.
Asgeir Albretsen is the founder of Harbor.