What is MCP?

Before MCP, giving an AI assistant access to a real system meant writing glue code for that specific pair: this assistant, that API. Ten assistants and ten services meant up to a hundred integrations — the classic N×M problem. Each one handled auth, data shapes, and errors differently, and none of it transferred.

MCP collapses that to N+M. The service implements the protocol once, as a server. The AI application implements it once, as a client. Any client can then talk to any server. The common analogy is a USB-C port for AI applications: one connector, many devices.

MCP has three roles, and the names trip people up less if you anchor on who owns what:

• Host — the AI application the user actually runs: a chat app, a coding assistant, an agent runtime. The host decides which servers to connect to and mediates what the model is allowed to do.
• Client — the protocol connector living inside the host. The host creates one client per server connection; the client speaks JSON-RPC to its server and relays results back to the model.
• Server — the program that exposes capabilities: a wrapper around a database, a file system, a SaaS API. It advertises what it can do in a machine-readable catalog the client fetches at connection time.

• Tools are actions the model can decide to invoke — each with a name, a description, and a JSON Schema for its parameters. This is the workhorse primitive: “create a card,” “query a database,” “send a message.”
• Resources are readable context — documents, records, board states — the host can pull into the model’s context window.
• Prompts are reusable, parameterized instruction templates a server can offer for common workflows.

When the model wants to act, the client sends a tool call and the server executes it and returns the result:

// The AI decides to call a tool; the client sends JSON-RPC:
{
  "method": "tools/call",
  "params": {
    "name": "create_card",
    "arguments": {
      "board_id": "b7f3…",
      "title": "Draft May newsletter"
    }
  }
}

The model never sees your HTTP client or your auth code — it sees a typed catalog of what it may do, and the host enforces the boundary.

The protocol is JSON-RPC 2.0 over a transport, and the spec defines two (as of the current revision, July 2026):

• stdio — the server runs as a local subprocess of the host and they talk over stdin/stdout. Zero network setup; the usual choice for local tools like file systems.
• Streamable HTTP — the server is a remote web service; the client POSTs JSON-RPC messages and the server can stream responses. The spec’s original remote transport, HTTP+SSE, was deprecated in the March 2025 revision in favor of Streamable HTTP, though plenty of deployed servers (including ours, at present) still serve the SSE form and mainstream clients continue to support it.

Remote servers authenticate the connection — typically a bearer token in the Authorization header or an OAuth flow — so the server knows who is acting, not just that someone is.

Anthropic introduced MCP in November 2024 and open-sourced the specification and SDKs. Adoption crossed vendor lines fast — OpenAI announced client support in March 2025 — and through 2025 mainstream IDEs and agent frameworks followed. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation, making it vendor-neutral in governance as well as in practice. The ecosystem now counts thousands of servers, discoverable through the official MCP registry. (Facts as of July 2026.)

The practical shift is that an AI assistant stops being a text box and starts being a coworker with hands. With MCP, “draft the May newsletter and file it for review” is not a copy-paste relay — the model reads the brief from one tool call, writes the draft back with another, and moves the work forward in the system your team already uses. The integration cost that used to make this a per-company engineering project is now a config entry.

It also changes what to look for in the software you buy: does this product treat its MCP surface as a first-class interface with real identity and permissions, or as a demo?

A concrete example of the pattern end-to-end: Novum OS is a kanban board where the MCP server is part of the product, not an afterthought. Every UI capability has a typed MCP tool — listing boards, creating and moving cards, writing content, even draining a column as a durable work queue. An agent connects with its own seat — its own identity, scoped permissions, and audit trail — so “the AI did it” is an attributed, revocable fact rather than a mystery write. The five-minute setup guide shows the whole flow.