What Is MCP? The Model Context Protocol Explained

By MakeYourMCP Team · Published Jul 17, 2026 · Updated Jul 17, 2026

The Model Context Protocol (MCP) is an open protocol, released by Anthropic, that lets AI models and agents connect to external tools and data sources through a single standardized interface instead of a custom integration per application. It replaces one-off, per-platform plumbing with a common way for any MCP-compatible client to discover and call the tools an MCP server exposes.

This page covers the core architecture in plain terms. For the full protocol reference, see the official Model Context Protocol specification.

Before MCP, every AI application that wanted to connect a model to a database, an internal API, or a file system had to build and maintain its own integration for that specific pairing. MCP's pitch is that the integration only needs to be built once, on the server side, and any MCP-compatible application can use it from then on.

How MCP works

MCP defines three roles that stay the same regardless of what's being connected:

• Host: the application the user actually interacts with — a desktop AI assistant, an IDE with an AI pane, or a custom agent runtime. The host is what decides to bring MCP into the picture at all.
• Client: a connector that lives inside the host and maintains a single connection to one MCP server, handling the protocol handshake and message exchange for that connection. A host that talks to three MCP servers runs three clients.
• Server: a process — local or remote — that exposes tools, resources, and prompts over MCP. A server doesn't know or care which host is talking to it; it just answers requests according to the protocol.

In practice: the host starts a client for each server it wants to use, the client asks the server what it offers, and from then on the model — reasoning inside the host — decides, turn by turn, which tool to call and with what arguments. The server executes the call and returns a result the model reads like any other piece of context.

The host/client/server split is what makes MCP a protocol rather than a library. A server doesn't import the host's code and the host doesn't import the server's code — they exchange messages in a shared format, which is what lets a server built for one host work with another without either side being rewritten. A host might run one client connected to a server on the same machine, and another client connected to a server reachable over the network, without needing special-case logic for either — both speak the same protocol once the client is connected.

This also means a single server can, in principle, be reused across every host that speaks MCP, and a single host can combine tools from many independently maintained servers in one conversation — a database server here, an internal ticketing server there — without those servers knowing about each other.

What an MCP server exposes

A server's capabilities fall into three categories defined by the protocol itself:

• Tools — functions the model can actively call, with typed arguments and a typed result. Reading a database row, calling an internal API, or running a search are all tools. A tool is the category where the model initiates an action, so it's also the category where a wrong or malicious call does the most damage.
• Resources — data the server can supply as context: a file, a query result, a document. Resources are things the host can attach to a conversation, not actions the model triggers on its own — closer to "here's a document you can read" than "here's a button you can press."
• Prompts — reusable, parameterized prompt templates a server can offer for common tasks, so the host doesn't need to hard-code them. A server that specializes in code review might expose a prompt template for "review this pull request against our style guide," parameterized by which PR to look at.

Most of the security conversation around MCP is about tools specifically, since they're the category that takes action rather than just supplying context. A resource being wrong is a bad answer; a tool call being wrong or unauthorized is a side effect in a real system — a row that got deleted, an email that got sent, a record that got changed.

A single MCP server usually exposes a mix of all three, not just one. A database server, for example, might offer read/write tools per table, a resource representing the current schema so the model can see what's available, and a prompt template for a common query pattern the team runs often.

Why MCP servers need security controls

Connecting a model to a tool means a decision about what to call and with what arguments is being made by something reading natural language — including text an attacker may have planted in a document, a web page, or the output of another tool. That's a different risk surface than a human clicking through a UI: the model has direct, programmatic access to whatever the server exposes, and it acts on whatever instructions are in its context at the time, not only the ones the user typed.

Without controls in front of that access, an MCP server that can read or write real data has no seatbelt: no restriction on which tools a given agent can call, no isolation keeping credentials out of the prompt, and no record of what happened after the fact. See the complete guide to securing MCP for the full threat model and mitigations.

Concretely, three gaps show up over and over in ungoverned setups. First, an agent that can call any tool a server exposes has no notion of least privilege — a support workflow and a production maintenance workflow end up with identical reach if nothing distinguishes them. Second, if a server needs a database password or API key to do its job, that credential has to live somewhere the server process can reach it — and if it's handed to the model or embedded where the model's context can see it, a well-crafted prompt can potentially extract it. Third, without a record of what was called, with what arguments, and why it was allowed, there's no way to reconstruct what an agent actually did after something goes wrong.

None of these are protocol-level requirements MCP imposes on you — the protocol defines how a host, client, and server talk to each other, not how you authorize, isolate, or log what happens once they're connected. That's a layer you add in front of the connection, which is the subject of the guide linked above.

Building an MCP server without writing one from scratch

Not every MCP server needs to be written by hand. Databases and REST APIs can have their MCP servers generated directly from the source's schema, producing typed tools without custom wrapper code — the schema is introspected, tools are generated from it, and those tools still go through the same authorization and audit layer a hand-written server would sit behind. See how to build a no-code MCP server for how that generation step works and where its limits are.

This matters for the "what is MCP" question specifically because it separates two things that are easy to conflate: the protocol itself, which is fixed and public, and the server implementing it, which can be written by a developer or generated from a source's schema. Either way, what a client sees on the other end is the same kind of typed, discoverable tool set.

MCP vs. plugins and function-calling

Before MCP, connecting a model to a tool usually meant using a specific platform's function-calling API: you define a set of functions in that platform's format, and the model — within that one application — can call them. That works, but the function definitions and the calling convention are tied to that platform. Reusing the same integration in a different host means rewriting it against a different API.

MCP standardizes the server side of that boundary instead of the application side. An MCP server written once can be plugged into any compliant host — Claude Desktop, an IDE assistant, a custom agent runtime — without the server knowing or caring which one it's talking to. The trade-off is real: for a single application calling a handful of in-process functions, a platform's native function-calling API is simpler to stand up than a client/server protocol. MCP's protocol layer pays for itself once you want the same tool available across more than one host, or maintained independently of any single application that consumes it.

The two aren't strictly competing, either. A host can implement MCP clients and still expose its own platform-specific function-calling surface for things that only make sense inside that one application. MCP doesn't replace every use of function-calling — it gives you an option for the tools you specifically want portable across more than one host, without having to maintain a separate integration per platform for those.

The practical question worth asking before building a new integration is who else, besides the application in front of you today, might eventually need to call the same tool. If the answer is "probably nobody else, ever," a platform-native function is the simpler build. If the answer is "possibly another host, or a different agent runtime, later," building it as an MCP server means that reuse doesn't require rewriting the integration from scratch.

Where to go next

This page covers what MCP is. Where you go next depends on what you're starting with. If you already have an MCP server — yours or a third party's — and need to govern what it can do, see how to put a policy gateway in front of it. If you don't have one yet and want to generate one from a database or API instead of writing it by hand, see the no-code MCP builder. Both paths end up behind the same kind of policy gateway — the difference is only in how the MCP server itself came to exist.

Related Guides:

• The Complete Guide to Securing the Model Context Protocol (MCP)
• How to Build a No-Code MCP Server From a Database or API
• MCP Server vs. Custom API Integration: When Each One Wins

← Back to guides list