What MCP is, and why your AI needs it
The Model Context Protocol is how AI tools reach knowledge that isn't in their training data. Here is what it actually does, in plain terms.
Your AI assistant is good at reasoning and bad at knowing things about you. It has never seen your pricing decision, your escalation policy, or the reason you moved off that vendor last spring. Every session starts from nothing, and you fill the gap by pasting context in by hand.
The Model Context Protocol — MCP — is the open standard that closes that gap. It is a contract between an AI client and an external source of knowledge or capability. The client asks; the server answers.
What it actually is
MCP is a protocol, not a product. A server exposes a set of tools — named operations with typed inputs — and the AI client discovers them, decides when to call them, and feeds the results into its own reasoning.
That is genuinely all it is. The interesting part is what it removes:
- No plugin per tool. One MCP server is reachable by every MCP client. Write it once, and Claude, Claude Code, Cursor, Codex and ChatGPT can all use it.
- No vendor lock-in. The protocol is open. Switching AI vendors does not mean rebuilding your integration, because the integration was never vendor-specific.
- No copy-paste. The AI fetches what it needs at the moment it needs it, rather than depending on you to have anticipated it.
Why this matters for shared knowledge
Most AI tools ship some form of memory. It nearly always has the same two limits: it belongs to one person, and it lives inside one tool. Your teammate cannot see it, and neither can the next tool you try.
An MCP server sitting in front of a shared knowledge base inverts both. The knowledge is the team's, and every client that speaks the protocol reads the same current version of it.
That is the whole idea behind Verde. Your team writes decisions down once, and the tools your team already uses can read them — with exactly the permissions the person behind the token has, and no more.
What connecting looks like
Concretely, it is one endpoint and a token:
claude mcp add --transport http verde \
https://getverde.ai/api/mcp \
--header "Authorization: Bearer YOUR_TOKEN"
Cursor and Codex read the same details from a .mcp.json. Clients that prefer OAuth, like Claude.ai connectors, use that instead. In every case the AI ends up with the same set of tools, pointed at the same knowledge.
The part people get wrong
MCP does not make an AI trustworthy. It gives it reach, and reach is exactly the thing that deserves a permission model.
A token acts with its owner's permissions and nothing more. If a member cannot read a private document, neither can any AI client holding their token — and that has to be enforced on the server, in the query, not in the tool description. An AI client is not a trust boundary. It is a caller.
Get that part right and MCP stops being a novelty and starts being infrastructure.
