The Model Context Protocol (MCP) Explained: A Plain-English Guide for UK Teams

The Model Context Protocol (MCP) is an open standard that gives AI assistants a single, shared way to use external tools and data. An MCP server publishes what it can do; an MCP client built into Claude, Cursor, ChatGPT or another assistant discovers those capabilities and calls them when a question needs them. For an organisation, it means you can connect a knowledge base or an internal system once and make it available in every compatible assistant your staff use.

Why MCP exists

A language model on its own is a closed box. It cannot open your shared drive, check a supplier's record or read the guidance HMRC updated last month. Early on, each assistant solved this with its own plug-in system, which meant that a software firm wanting to appear in three assistants maintained three separate integrations, and an IT team approving them had three different security models to review.

MCP standardises the connection. The specification, released openly in late 2024 and maintained at modelcontextprotocol.io, describes how an assistant and a data source introduce themselves, list what is on offer and exchange requests. Messages use JSON-RPC 2.0, a long-established and deliberately simple format. The practical upshot: build one MCP server and it works with any client that implements the protocol.

The architecture: host, client, server

Most confusion about MCP comes from mixing up three roles. Here they are, in the order a request travels.

• The host is the application in front of the user: a chat app, a code editor such as Cursor, or a terminal agent. It runs the model, holds the conversation and asks the user for permission when needed.
• The client is a component inside the host that maintains a dedicated connection to a single server. Connect four servers and the host runs four clients.
• The server exposes capabilities. It might run locally (reading files, querying a local database) or remotely as a web service (a SaaS product, a document search, a company API).

stdio versus Streamable HTTP

There are two standard transports. stdio is for local servers: the host starts the server as a subprocess and the two communicate through standard input and output. Streamable HTTP is for remote servers: the client sends requests to an HTTPS endpoint, normally carrying an API key or OAuth token in the headers. For organisations, remote servers are the interesting part, because adding one requires a URL and a credential rather than software on every laptop.

A request, step by step

1. The client opens a session and both sides agree a protocol version and their capabilities.
2. The client requests the server's list of tools, each with a name, a description and a JSON Schema describing its arguments.
3. When the user asks something, the model reads those descriptions and decides whether a tool would help.
4. The client sends the tool call; the server executes it and returns the result, usually as text.
5. The model uses the result to compose its answer, ideally quoting or citing the source.

Tools, resources and prompts compared

An MCP server can expose three types of capability. The key difference is who is in control of using them.

The protocol also lets clients offer features back to servers, such as asking the user a clarifying question. Even so, tools do most of the heavy lifting in real deployments: they are what lets an assistant go and fetch an answer without the user copying and pasting anything.

How assistants reach knowledge bases through MCP

A general-purpose assistant does not know your staff handbook, your product catalogue or the precise wording of a VAT notice. The usual answer is retrieval: search a trusted set of documents first, then let the model answer from what was found. You can run that retrieval yourself on top of a vector database, or use a hosted RAG as a service offering; either way, MCP is how the assistant gets to it.

Kopik is one example of the hosted route. Its remote server, at https://kopik.fr/api/mcp over Streamable HTTP, exposes three tools: list_bases lists the public knowledge bases (free, and the only one usable without a key), ask_base returns a written answer with numbered source passages, and search_base returns the passages alone at the same price. If you only want one base, such as UK VAT for Businesses: HMRC Notices, you can point the client at that base's own URL (https://kopik.fr/api/mcp?base= followed by its slug) and the tools no longer need a base argument.

Configuration follows the same pattern in most clients. In Cursor, you add a "kopik" entry under mcpServers in .cursor/mcp.json with the URL and an Authorization header of the form Bearer kpk_…; in Claude Code, a single claude mcp add command with --transport http does the same. Keep the URL in quotes if it contains a question mark and you use zsh.

UK GDPR and security checks before you connect

Every MCP server you connect becomes part of your data flows. If personal data might pass through it, the usual UK GDPR obligations apply, and the ICO's guidance on AI and data protection is a sensible starting point for your assessment.

• Map the data. Record which servers receive which information, and whether that includes personal data. Update your records of processing and, where the risk is high, your DPIA.
• Scope the credentials. One key per server and per use, with the minimum access needed. Revoke keys when a project ends.
• Guard against prompt injection. Content returned by a server can include text that tries to steer the model. Prefer servers that flag returned content as untrusted, and keep human approval for tools that send, write or delete.
• Cap the costs. Paid tools should offer a ceiling; on Kopik, a maxPriceCents argument rejects the call free of charge when a base costs more.
• Respect the limits. Remote servers enforce rate limits; build agents that back off rather than retrying in a tight loop.

Do you still need an API if you have MCP?

Usually, yes. A REST API suits deterministic code: a scheduled job, a web form, an integration your developers control end to end. MCP suits situations where a model chooses, mid-conversation, which capability to use. The two are complementary, and many services publish both. A useful rule of thumb: if a person types the question, MCP; if a programme does, the API.