Model Context Protocol (MCP) Explained: Servers, Clients, Tools and Resources

The Model Context Protocol (MCP) is an open standard that lets an AI assistant connect to outside tools and data through one common interface, instead of a custom integration for every app. An MCP server exposes capabilities (tools, resources, prompts); an MCP client inside an assistant such as Claude, Cursor or ChatGPT discovers them and calls them on the user's behalf. For businesses, that means a knowledge base, a CRM or a ticketing system can be plugged into any compatible assistant once, and reused everywhere.

What is MCP, in plain English?

Language models are good at reasoning over text, but on their own they cannot read your files, query your database or look up yesterday's policy update. Every assistant vendor used to solve this with its own plugin format, so a company that wanted its data available in three assistants had to build three integrations. That is the classic N times M problem: N assistants multiplied by M data sources.

MCP replaces that with a single contract. It was published as an open specification in late 2024 and is documented at modelcontextprotocol.io. The usual analogy is a USB-C port for AI: the assistant has one socket, and anything that speaks the protocol can plug into it. You build an MCP server once, and every MCP-capable client can use it.

Under the hood, MCP messages are JSON-RPC 2.0 requests and responses. Nothing exotic: a client sends a method name and parameters, the server returns a result or an error. What MCP adds is a shared vocabulary for the things an assistant needs (listing tools, calling them, reading resources) and a handshake where both sides declare what they support.

Hosts, clients and servers: the MCP architecture

The specification separates three roles. Getting them straight makes every MCP tutorial easier to follow.

• Host: the application the user actually works in, such as a desktop chat app, an IDE like Cursor, or a command-line coding agent. The host owns the model, the conversation and the permission prompts.
• Client: a connector living inside the host. Each client keeps one connection to one server, so a host connected to five servers runs five clients.
• Server: a program that exposes capabilities over MCP. It can be a local process on your laptop (reading files, running git) or a remote web service (a SaaS product, a knowledge base, an internal API).

Local and remote transports

MCP defines how messages travel. With stdio, the host launches the server as a child process and talks to it through standard input and output: ideal for local tools that touch your filesystem. With Streamable HTTP, the server is a web endpoint the client calls over HTTPS, usually with an API key or an OAuth token in the headers. Remote servers are what make MCP practical for teams, because nobody has to install anything beyond a URL and a credential.

What happens during a session

1. Initialize. The client connects and both sides exchange their protocol version and capabilities.
2. Discover. The client asks for the list of tools (and resources or prompts if the server offers them). Each tool comes with a name, a description and a JSON Schema for its inputs.
3. Decide. The model sees these descriptions alongside the user's request and chooses whether a tool would help.
4. Call. The client sends a tool call with arguments; the server runs it and returns content, typically text.
5. Answer. The model reads the result and writes its reply, often citing what the tool returned.

Tools, resources and prompts: what an MCP server can offer

A server advertises up to three kinds of capabilities. They differ mainly in who decides to use them.

Clients can also offer capabilities back to servers, for example letting a server ask the user for a missing detail or request a model completion. In practice, though, tools carry most real-world MCP traffic, because they let the model act on its own initiative while the host keeps the user in control of approvals.

How Claude, Cursor and ChatGPT use MCP to reach knowledge bases

Assistants know a lot, but not your internal procedures, last quarter's pricing or the exact wording of a state regulation that changed this year. That gap is exactly what retrieval-augmented generation (RAG) fills, and MCP is the cleanest way to expose a RAG knowledge base to the assistants your team already uses.

Take Kopik as a concrete case. Its MCP server lives at https://kopik.fr/api/mcp and uses the Streamable HTTP transport. It exposes three tools: list_bases (free, lists the public bases, optionally filtered by topic or query), ask_base (returns a written answer plus numbered source passages) and search_base (returns only the passages, at the same price, for agents that prefer to reason on their own). A typical exchange looks like this:

1. A user in Cursor asks: "What deductions can a sole proprietor take for a home office?"
2. The model sees that a knowledge base tool is available and calls ask_base on a base such as US Small Business Taxes & Deductions (IRS Guides) with the question.
3. The server retrieves the relevant passages from the indexed documents and returns an answer grounded in them, with numbered citations.
4. The model writes its reply and points the user to the cited passages, so the claim can be checked.

The same server works in Claude Code, Cursor, ChatGPT and other MCP clients, because the contract is the same. In Claude Code, one command adds it: claude mcp add --transport http kopik https://kopik.fr/api/mcp --header "Authorization: Bearer kpk_…". In Cursor and most other clients, you add a "kopik" entry under mcpServers in the configuration file (.cursor/mcp.json for Cursor) with the URL and the Authorization header. Our step-by-step tutorial on connecting a knowledge base to AI agents with MCP covers each client in detail.

Security and compliance: what to check before connecting a server

An MCP server is code that your assistant trusts with real actions and real data. Treat it like any third-party integration that will pass through a SOC 2 audit or a HIPAA review.

• Least privilege. Give each server its own API key with the narrowest scope possible, and rotate keys you no longer use.
• Prompt injection. Text returned by a server may contain instructions aimed at the model. Good servers mark returned content clearly as untrusted (Kopik wraps it in dedicated tags) so the client treats it as data, not orders.
• Spending limits. For paid tools, set a ceiling. The knowledge base tools above accept a maxPriceCents argument that refuses the call, at no cost, if the base is more expensive.
• Data residency and regulated data. Do not route protected health information or data covered by state privacy laws (such as the CCPA in California) through a server whose processing you have not reviewed.
• Approvals. Keep the host's confirmation prompts on for tools that write, send or delete.

MCP vs a REST API: do you need both?

MCP does not replace APIs; it sits on top of them. A REST API is ideal when your own code calls a service in a fixed way: a nightly job, a backend route, a Slack bot. MCP is ideal when a model decides at runtime which capability to use. Many products offer both: a REST API with keys for developers, and an MCP server for assistants. If you are designing a private setup, our guide to a private knowledge base as RAG for AI agents shows how the two fit together.