Guide · Concepts
What is the Model Context Protocol (MCP)?
The Model Context Protocol — the open standard connecting tools and data to AI agents, and the layer where governance either happens or doesn’t.
The Model Context Protocol (MCP) is the open standard for connecting AI models to tools and data. A tool exposes its capabilities once, in a standard way, and any MCP-compatible agent can use them — no custom integration per pair. It has become the common plug of the agent ecosystem: the layer through which agents reach CRMs, inboxes, documents, and APIs.
That makes MCP something else, too: the layer where governance either happens or doesn’t. Every consequential thing an agent does travels through a tool call, so the tool boundary is exactly where control belongs — which tools are admitted, which calls need approval, what gets logged. This guide explains MCP in plain terms, then what 2026 taught about ungoverned tool access, and how monopea uses MCP as both client and server with a default-deny gate at that boundary.
What problem does MCP solve?
Before a standard, every connection between a model and a tool was a one-off. Wiring an agent to your CRM, then your calendar, then your docs meant three bespoke integrations, each maintained separately and each breaking in its own way. With many models and many tools, custom connections multiply without limit — the same integration explosion the software industry has hit many times before.
MCP replaces the tangle with a common interface. A tool exposes its capabilities once, as an MCP server; any MCP client — the agent side — can discover and use them. The agent learns to speak one protocol instead of a hundred APIs. It is the move that made USB and HTTP valuable: agree on the plug, and everything behind it interoperates. Since its release as an open standard in late 2024, MCP has been adopted broadly across the industry, which is precisely what makes it worth building on — tools you connect today are not bets on one vendor’s integration list.
How does MCP work, in plain terms?
MCP is client–server. An MCP server wraps a tool or data source and advertises what it offers; an MCP client, inside the AI application, connects and makes those offerings available to the model. The model never needs the tool’s internals — only the server’s declared capabilities, which keeps the connection scoped and inspectable.
Servers expose three kinds of things: tools (actions the model can invoke — update a record, send a draft), resources (data it can read — documents, records), and prompts (reusable templates). The categories matter for governance more than they first appear: resources are reads, tools are potentially writes, and a well-governed agent treats them differently — reads flow, mutations wait for review. Standardizing the shape of a tool call is also what makes a generic approval gate possible at all: because every action arrives as a structured call with a name and arguments, infrastructure can hold it, show it to a human verbatim, and dispatch it only on approval — regardless of which tool or vendor is behind it.
- Tools — actions the agent can invoke; the calls that change things
- Resources — data the agent can read to ground its work
- Prompts — reusable templates a server can offer
Why does the tool layer need governing?
Because capability and risk arrive through the same plug. The moment an agent has tools, text-generation failures become action failures: a prompt-injected instruction in an email is harmless to a chatbot and a live threat to an agent that can call send, pay, or delete. And an open ecosystem cuts both ways — 2026 made this concrete when hundreds of malicious skills were found in a major agent framework’s community registry, delivering malware to the machines that installed them.
None of that is an argument against MCP; it is the argument for governing the layer MCP standardizes. Three properties do most of the work. Default-deny onboarding: a tool you have not explicitly admitted is not callable — connectivity is not permission. Approval at the call boundary: mutation-capable calls are held as proposals for human decision; unknown tools fail closed. And credential separation: the connection authenticates with secrets the model never sees, so a compromised or over-curious tool interaction cannot exfiltrate what was never in context. MCP gives every tool the same shaped doorway; governance is deciding what may walk through it.
What should you look for in an agent that “supports MCP”?
Press on scope, defaults, and extensibility. Can you bring your own servers — including internal tools — or is “MCP support” a short fixed list? Are connections scoped to the access you grant and revocable at any time? And the question that separates governed platforms from the rest: when you connect a new server, what can it do before you have said anything — everything it advertises, or nothing until admitted?
Be wary of implementations that treat connection as permission, grab broad credentials instead of scoped ones, or paste tokens into the model’s context to authenticate (see our secrets-management guide for why that ends badly). MCP is deliberately neutral about trust — it standardizes the plug, not the policy. That neutrality is a feature: it means the policy layer is yours to demand. An agent platform that speaks MCP but cannot tell you its default policy for a brand-new tool has answered your question.
How Monopea uses MCP — as client and as server
As a client, MCP is monopea’s tool layer: you connect the tools you use through an MCP catalog, and every tool enters under default-deny onboarding — nothing is callable until admitted, mutation-capable calls become pending proposals with their exact arguments, unknown tools fail closed, and connections authenticate through the write-only vault, so the model references {{secret:NAME}} and never sees credentials. Sub-agents inherit the same gate, so delegation never widens permissions.
monopea is also an MCP server: @monopea/mcp-server exposes your agent’s capabilities — ask_brain, search_knowledge, traverse_knowledge, remember, list_memory, list_personas, and more — to any MCP-compatible client, so your governed agent and its memory become a tool inside the other software you work in. Both directions cross the same governance layer, and everything is logged to the Ed25519-signed audit chain.
What to take away
One plug, not a hundred
A shared protocol means tools and agents interoperate without a custom integration per pair — and because every action arrives as a structured call, a single approval gate can govern all of them.
Connectivity is not permission
The question that sorts platforms: what can a newly connected tool do before you say anything? Look for default-deny onboarding and fail-closed unknown tools, not connect-and-go.
Keep credentials out of the plug
MCP connections should authenticate through infrastructure — a write-only vault, dispatch-time substitution — never by pasting tokens into the model’s context where injection can reach them.
FAQ
What is MCP?, in short
- What does MCP actually stand for and do?
- MCP is the Model Context Protocol: an open standard that lets AI models connect to tools and data through a common client–server interface. A tool exposes capabilities once as an MCP server, and any compatible agent can use them — no bespoke integration for each pair.
- What does an MCP server expose?
- Three kinds of things: tools (actions the model can invoke), resources (data it can read), and prompts (reusable templates). The read/write distinction matters for governance — a well-run agent lets resource reads flow while holding mutation-capable tool calls for approval.
- Is MCP itself secure?
- MCP standardizes the connection, not the trust policy — that neutrality is by design. Security comes from the layer above: default-deny tool onboarding, approval gates on mutations, scoped and revocable access, and credentials the model never sees. Judge platforms on that layer, not on the protocol logo.
- Is Monopea an MCP client or an MCP server?
- Both. As a client it connects your tools through a default-deny catalog where mutations become approvable proposals. As a server, @monopea/mcp-server exposes ask_brain, search_knowledge, remember, and more — so your governed agent is usable as a tool from any MCP-compatible app.
Keep exploring
Approval gates
Why “always ask first” in a system prompt is not a control — and what a real approval gate looks like: default-deny policy, a proposal lifecycle, fail-closed unknown tools, and audit chains.
Secrets management
Why an AI agent must never see your credentials, how prompt injection turns context into an exfiltration channel, and the write-only vault pattern that fixes the class.
Long-term memory
Why persistent memory turns an assistant into an operator — and why it must be tenant-owned, inspectable, and stored somewhere you can name.