MCP: Connecting Agents to Systems
What the Model Context Protocol standardises, its client-server architecture and primitives, transports, security considerations, and where MCP fits in an enterprise design.
The problem MCP solves
Before MCP, every AI application wrote its own integration for every system: a custom Slack connector for the chat app, another for the IDE assistant, another for the agent framework. With N apps and M systems, that is N × M integrations.
The Model Context Protocol (MCP), introduced by Anthropic in late 2024 and since adopted widely across AI apps and providers, standardises the interface. Each system exposes one MCP server, and each AI app implements one MCP client, which reduces the work to N + M. It plays a role similar to the Language Server Protocol for code editors.
Architecture
- Host: the AI application the user interacts with.
- Client: maintains a connection to one server and relays capabilities to the host's model.
- Server: a lightweight program exposing a system's capabilities in MCP's format. The protocol runs over JSON-RPC.
What servers expose
| Primitive | What it is | Who decides to use it | Example |
|---|---|---|---|
| Tools | Actions with typed inputs | The model | create_issue(repo, title, body) |
| Resources | Readable data, addressed by URI | The app or user | A file, a DB schema, a document |
| Prompts | Reusable templates or workflows | The user | "Summarise this PR" |
Clients can also offer capabilities back to servers, such as asking the host's model to generate text (sampling) or asking the user for input (elicitation).
Transports and deployment
- stdio: the server runs as a local subprocess of the host. Simple, and good for developer tools with local access (files, git).
- Streamable HTTP: the server runs as a remote service, suitable for shared, multi-user, centrally managed integrations. Remote servers use OAuth-based authorisation.
MCP in an enterprise design
A typical pattern for "let our internal assistant use company systems":
- An MCP gateway or registry lists approved servers, with central auth, rate limits, audit logs and policy.
- Servers act with the user's identity (OAuth on behalf of the user), not a god-mode service account, so the agent can only do what that user could do.
- Scoped tools per role: read-only tools for most users, write tools behind approval.
- Observability: log every tool invocation with the user, the arguments and the result size.
Security considerations
MCP makes connecting tools easy, including connecting risky ones:
- Untrusted servers: a third-party server can return malicious instructions in tool results, or describe its tools misleadingly. Vet and pin the servers you allow, like any dependency.
- Prompt injection through data: content fetched through a server (emails, web pages, issues) may contain instructions. Treat it as untrusted.
- Over-broad permissions: a server with admin credentials turns any successful injection into a serious incident. Use least privilege.
- Confused deputy: make sure the server checks that the user is allowed to perform an action, not just that the server can.
- Dangerous combinations: an agent that reads untrusted content, can access private data, and can send data out is the classic exfiltration setup. Break at least one of the three.
Key takeaways
- MCP is an open protocol that standardises how AI applications connect to tools and data. Build an integration once and use it from any MCP-capable client.
- Servers expose tools (actions), resources (data) and prompts (templates). Clients inside AI apps connect to them over stdio or HTTP.
- MCP turns an N × M integration problem into N + M.
- Security is your job. Authenticate servers, scope permissions, vet third-party servers, and treat tool outputs as untrusted.