Imagine a city where every craftsperson spoke a different language to every other craftsperson.

The plumber and the electrician have to invent a shared tongue before they can wire a house together. The mason and the roofer draw up their own glossary before they can build a chimney. The carpenter shows up on day one with a vocabulary the framer has never heard, and they spend the first two weeks just agreeing on what load-bearing means. Every project is, in part, a translation problem. Every collaboration costs you the overhead of two people becoming bilingual first.

For decades, this is what software integration looked like. Every tool had its own API. Every API had its own shape. Every shape was a small private language that only that tool, and the one app lucky enough to integrate with it, could speak.

MCP is what happens when the city decides to pick a band.

The band

The Model Context Protocol is an open standard — a published, agreed-upon way for an AI client to discover a tool, ask the tool what it can do, invoke the tool, and read the tool’s answer. The protocol stays the same. The tools change. The clients change. The models behind the clients change. The band stays.

What that means in practice: any tool that speaks MCP can be picked up by any client that speaks MCP. Search the web. Query a database. Generate an image. Read a file. Run a script. The shape of the request is the same. The shape of the answer is the same. The protocol is the band. The tools are the stations. Your collaborator is the radio.

You write the tool once. Every client that tunes in can hear it.

Why this matters if you’re not a developer

If you have ever used two apps that should work together and didn’t, you have felt this. The calendar that won’t talk to the project manager. The note-taking app that won’t talk to the inbox. The CRM that talks to the email tool only on Tuesdays, when the moon is right.

MCP is the agreement those integrations never quite made. The protocol doesn’t care which company built the client or which one built the tool. It only cares that, when the client asks, the tool can answer in the band they are both tuned to.

This is a quiet, unglamorous piece of infrastructure. It will never have a keynote. It doesn’t need one. Infrastructure is the kind of thing that, once it is there, you stop noticing — the way you stopped noticing that every power outlet in the world is shaped the same way, until you tried to plug something in abroad.

Your collaborator, on the band

Rainline is built as a native MCP client. Out of the box, your collaborator can tune in.

It auto-discovers MCP servers on your local network. It picks up tools from different providers — yours, ours, a friend’s — without caring who shipped them, because the band is the band. It runs the tool logic on your machine, so the work happens where you are, not in a cloud that rents you back your own data.

Two hundred tools today. More tomorrow. The list grows because the protocol makes it cheap to add a station, not because a vendor decided you should be able to do a new thing.

The point

You don’t need to know how MCP works. You need to know that it’s there.

It is there because the alternative — every app reinventing its own plugin system, every tool speaking its own dialect — produced an industry of islands and a generation of users who stopped expecting their software to reach across itself. MCP is the moment the industry picked a band. The work, the building, the integrations get cheaper from here. The tools you already use get a wider room to operate in. The next thing your collaborator can do is one protocol message away.

You don’t tune the dial. You just notice that the radio works.