The short answer
MCP (Model Context Protocol) is an open standard that defines a common way for an application hosting a model or agent (the client) to talk to a server that exposes tools, data, and ready-made prompts. Instead of building a bespoke integration for every external system each agent needs, the agent speaks one language to any server supporting the protocol, and the server speaks that same language back to any client.
The problem MCP solves
Before a common standard, connecting an agent to a handful of systems (email, a CRM, a database, a search tool) meant building a custom integration for every agent-system pair. As the number of agents and systems grows, this becomes an M-by-N problem: the number of integrations required scales with the product of agents and systems. MCP replaces that tangle of point-to-point integrations with one standard interface: a system's provider builds an MCP server once, and any agent that supports the protocol can use it without writing bespoke integration code for that specific case.
Client and server roles
MCP's architecture has two main parties. The client is the piece embedded inside the agent's host application, responsible for discovering available servers and communicating with them on the agent's behalf. The server is the party that exposes specific capabilities — callable tools, readable data, or ready-made prompts — and responds to client requests according to the protocol's specification. A single agent can connect to several servers at once, each specialised in a different system.
Tools, resources, and prompts
- Tools: callable capabilities for performing an action or fetching a result, similar to the general notion of agent tools.
- Resources: data or content the client can read and pass along as extra context for the model, without it being a procedural call.
- Prompts: pre-built interaction templates the server exposes for the client or user to use directly.
Separating these three concepts gives a server flexibility in how it exposes its capabilities: a knowledge-management system might expose read-only resources, while a CRM might expose both read and write tools.
Remote vs local servers
An MCP server can run locally on the same machine as the client, which suits operating-system or local-file tools. Or it can run remotely over a network as a service hosted by another party, common when connecting an agent to an enterprise cloud system. The essential difference is not in the capabilities exposed but in the attack surface: a remote server adds a network, identity, and authentication layer that must be secured, while a local server relies on the isolation of the machine itself.
Security considerations
Connecting to an MCP server is a trust decision, just like any other external integration — the protocol itself does not automatically make a server safe. The main considerations:
- Authorization: the server should be granted only the permissions it needs, and client and user identity should be verified before any write tool executes.
- Scoping: do not give one server access to every system if it only needs a limited part of one.
- Trusting the server: running a third-party server means delegating it to handle requests on your agent's behalf; verify its source before connecting it to sensitive data.
- Prompt injection through tool output: output from any tool or resource may contain text designed to manipulate the model (prompt injection via retrieved content), so server output should be treated as untrusted data, not as direct instructions.
MCP vs custom integration
| Criterion | MCP | Direct custom integration |
|---|---|---|
| Effort per new source | One server built once, reused by any supporting client | Separate integration for each agent-system pair |
| Reusability | High across multiple agents and clients | Limited to that one integration |
| Fine-grained control over behaviour | Depends on what the server exposes as tools/resources | Full control since you write the logic directly |
| Fit for a fully internal, unique system | Useful if you plan to expose it to several clients later | Often simpler if used by a single agent only |
| Security considerations | Adds a third party (the server) whose trust must be assessed | Surface limited to what you write and fully control |
When to use MCP vs a direct integration
MCP is clearly useful when more than one agent or application needs to talk to the same external system, or when you want to take advantage of ready-made servers others have built instead of rebuilding an integration from scratch. If, on the other hand, the integration is entirely specific to internal logic that only one agent will ever use, a direct integration through a custom tool may be simpler to build and easier to control. At WKIL, MCP support is documented as part of the agents documentation and the deployment guide for anyone connecting their agent to protocol-compliant servers.