What is MCP? The Model Context Protocol, explained for people who build with AI

If you've used Claude or Cursor at any point in the last year, you've seen the letters MCP. Probably in a settings screen, next to an empty URL field, with no explanation anywhere in sight. This is the explanation.

The problem it solves

A language model on its own does one thing: it produces text. It can't read your database, call your API, or click a button. For a while, every capability beyond text meant a custom integration between one specific assistant and one specific tool, which meant every new assistant had to reimplement every tool, and every tool had to beg every assistant for a plugin slot. The classic N-times-M integration mess.

The Model Context Protocol, which Anthropic open-sourced in late 2024, is the boring fix: one standard way for any assistant to discover and call any tool. Under the hood it's JSON-RPC messages over a transport, which is about as unglamorous as plumbing gets. That's a compliment. Standards should be unglamorous. Adoption went faster than almost anyone predicted, and by now it's simply how assistants talk to the outside world.

How it works

There are servers and there are clients.

A server is a program that offers tools: named functions with typed inputs, things like create_component or query_database. A client is the assistant application itself, whether that's Claude, Cursor, or an agent you wrote, and it connects to servers, reads their tool lists, and lets the model call those tools mid-conversation.

The detail that makes the whole thing click: the model decides when to call what. You say "add a Redis cache between the API and the database," and the assistant works out the right sequence of tool calls on its own. The server never has to parse English. The model never touches your internals directly. Each side keeps doing the one thing it's good at.

Servers come in two flavors. Local ones run on your machine, talk over stdio, and can touch your files. Remote ones are hosted services you reach over HTTP, from any assistant that has the URL. The remote flavor is the interesting one, because it collapses "integration" down to pasting a URL.

What that feels like in practice

Arketo happens to be a remote MCP server, so we can make this concrete. Your workspace comes with one URL. You paste it into whatever assistant you already use, ideally the one that built your app. From then on, that assistant has drawing tools: create a component, connect two services, mark a finding.

Then you talk to your assistant, not to us. "Map the architecture of this repo." It reads code the way it always could, and now it can also draw what it finds onto a canvas we render and host. No agent to babysit, no export step, no plugin to install. That's the setup, all of it.

This is also why our pricing says you bring the LLM. MCP made the assistant swappable: we never hold a model API key, never see your prompts, and don't care which assistant you happen to pay for. The standard unbundled that for everyone at once.

The bigger consequence

The quiet thing MCP changed is that "integration" stopped being a feature somebody builds and became a property a tool either has or doesn't. Anything with an MCP server works with every assistant, including ones that don't exist yet, through the same URL. The question used to be "which assistant has a plugin for X?" Now it's "does X speak MCP?", and the answer keeps being yes.

If you'd rather feel the difference than read about it, the live demo is an Arketo canvas being driven over MCP. One URL, one standard, and a model doing the drawing.