What is the Model Context Protocol (MCP)? A plain-English guide

Large language models are strong reasoners trapped in a box. On their own they can't read your files, query your database, hit an API, or remember what happened yesterday. To do anything useful in the real world, a model needs tools. Until recently, every AI app wired up those tools in its own bespoke way.

The Model Context Protocol (MCP) is an open standard that fixes that. It defines one common language for connecting AI applications to external data and actions. A model that speaks MCP can plug into any MCP-compatible tool the same way. No custom glue per integration.

The USB-C analogy

The comparison you'll hear most often is that MCP is "USB-C for AI." Before USB-C, every device had its own connector and its own cable. After it, one port shape works across laptops, phones, monitors, and chargers. MCP does the same thing for AI tools: instead of N different integrations for N different apps, everything agrees on one plug.

That standardization is the whole point. A tool built once as an MCP server works with Claude, Codex, ChatGPT, Cursor, and any local agent that speaks the protocol, without the tool author writing a single line of app-specific code.

Clients and servers

MCP uses a simple client–server model:

• An MCP client lives inside the AI app: Claude Code, Cursor, ChatGPT desktop, and so on. It's the thing the model reasons with.
• An MCP server exposes a set of capabilities: tools (actions the model can call), resources (data it can read), and prompts (reusable templates).

When a session starts, the client asks the server "what can you do?" The server answers with a list of tools and their input shapes. From then on, the model can call those tools as it works, and the client relays the results back into the model's context.

A weather server might expose a get_forecast tool. A GitHub server might expose create_issue. A memory server like Knownbase exposes tools such as upsert_note and search_notes. The model doesn't need to know how any of them are implemented, only what they're called and what arguments they take.

What a tool call actually looks like

Under the hood, MCP is JSON-RPC. When a client connects, it sends an initialize request; the server responds with its capabilities. Adding a server to an app is usually just a small block of config pointing at the server's URL or command:

{
  "mcpServers": {
    "knownbase": { "url": "https://knownbase.dev/mcp" }
  }
}

Once that's in place, the tools appear to the model automatically. You don't prompt-engineer them in by hand. The protocol advertises them.

Why it matters

MCP turns AI tooling from a pile of one-off integrations into an ecosystem. For builders, it means writing a capability once and having it work everywhere. For users, it means the tools you rely on show up in whatever agent you happen to be using that day. And because the interface is standardized, you can swap the model underneath without rebuilding your integrations.

This is why "MCP server" has become such a common phrase so quickly. It's the unit of capability in the agent era: a self-contained bundle of things a model can do, portable across every app that speaks the protocol.

Where memory fits in

One of the most valuable things you can expose over MCP is memory. Models are stateless between sessions: close the window and the reasoning, decisions, and hard-won context are gone. An MCP memory server gives agents a durable place to write things down and read them back later, across sessions, across tools, and across teammates.

That's exactly what Knownbase is: an MCP server whose tools let any agent store and search project memory. We go deeper on why that's needed in Why AI agents need persistent memory, and on the practical setup in How to give Claude Code and Codex persistent memory over MCP.