What is the Model Context Protocol (MCP)?

The problem it solves

Before a shared standard like MCP, connecting an AI assistant to something useful — a company database, a file system, a project-management tool, a search API — meant writing a custom integration for that exact pairing of assistant and tool. Connect the same tool to a second AI application and you write the integration again, because there was no common language for “here is what this tool can do and how to call it” that every AI application understood.

That approach scales badly. With N AI applications and M tools, you end up needing something close to N times M separate integrations, each one bespoke, each one needing separate maintenance when either side changes. MCP’s job is to turn that into N implementations of one protocol on the AI-application side and M implementations of the same protocol on the tool side, so any compliant pair can simply work together.

The client/server idea, plainly

MCP is built around a client and a server, in a similar spirit to how a web browser (client) talks to a website (server) through the shared HTTP standard rather than a bespoke protocol per site. In MCP terms, the AI application — the assistant you are chatting with, or the coding tool you are using — acts as the client. An MCP server sits in front of a particular tool or data source (a database, a set of files, a specific API) and exposes what that tool can do in a standard, describable way: what actions are available, what information they need, and what they return.

When the assistant needs to do something outside its own reasoning — read a file, query a database, call an external service — it talks to the relevant MCP server using the shared protocol, gets back a result in a standard shape, and continues. Neither side needed to be built with the other specifically in mind; they only needed to both speak MCP.

Why a standard actually matters

A shared protocol turns “can this AI assistant use that tool” from an engineering project into a question of whether both sides support the standard. That has the same kind of effect that other widely adopted standards have had elsewhere in computing: it lowers the cost of connecting things that were built independently, it lets a tool builder support many AI applications by writing one server rather than many custom integrations, and it lets an AI application gain access to an entire ecosystem of tools as that ecosystem grows, rather than only the handful its own developers happened to wire up by hand.

Typical uses

In practice, MCP-style connections show up wherever an assistant needs to reach beyond its own training and the text of the current conversation:

• Reading and writing local or company files, so an assistant can work with real documents rather than only what was pasted into the chat.
• Querying a database, so an assistant can answer questions grounded in current, structured data rather than guessing.
• Calling external APIs — a calendar, a ticketing system, a search service — so the assistant can check or change something in another system.
• Combining several such connections in one session, so a single assistant can move between tools within one task rather than being limited to one integration at a time.

How it relates to agents, APIs and RAG

MCP is closely tied to a few other ideas covered elsewhere on this blog. It is one of the mechanisms that makes AI agents practical: an agent’s “tool use” step often means calling out over MCP to whichever server exposes the capability it needs, rather than a one-off integration written for that agent alone. Underneath, an MCP server is generally reached through the same kind of request-and-response mechanism as a regular API, explained in our API article — MCP standardises the shape of that conversation so an AI application does not need a custom client for every API it might ever want to use. And when the “tool” in question is a search over a knowledge base rather than an action, the pattern overlaps with retrieval-augmented generation, described in our RAG explainer.

MCP in certification study

MCP is a genuinely new, still-maturing standard rather than an established syllabus topic, so do not expect deep, protocol-level questions about it on current exams. Where it does surface — in passing, as an example of how AI applications connect to external tools and data — is in AI-focused material such as the AWS Certified AI Practitioner (AIF-C01), which cares about the concept of connecting a model to external context and tools, and in developer-focused study such as the AWS Certified Developer – Associate, which cares more broadly about how applications integrate through APIs. Our /revision library keeps the fuller syllabus for each exam up to date lesson by lesson as this area develops.