Model Context Protocol for operations teams: what to ask before you connect a server

Your team wants to connect the agent to the ERP, the CRM and the shared drive. The quickest way now is MCP. Someone finds a server, adds it, and the agent can suddenly read and write in a new system. That is the point of MCP. It is also why operations and risk should see each server before it goes in.

In one sentence: an MCP server is a new set of powers for your agent, and the protocol leaves the controls to you.

/01Where it comes from

MCP stands for Model Context Protocol. Its own site calls it "an open-source standard for connecting AI applications to external systems"¹. Through it, AI applications "can connect to data sources (e.g. local files, databases), tools (e.g. search engines, calculators) and workflows"¹. The site's analogy: "Think of MCP like a USB-C port for AI applications"¹.

That analogy is honest about the upside and quiet about the risk. A USB-C port lets you plug in a charger. It also lets you plug in a stranger's stick.

/02What it actually is

Three parts. The host is the AI application your people use. The client lives inside it and talks to servers. A server exposes tools (actions), resources (data) and prompts to the agent. When the agent decides to use a tool, the client calls the server, and the server does the work in the target system.

So each server is a bundle of powers. A read-only document server is low risk. A server that can create purchase orders, update supplier records or send email is a new route into your systems.

The spec is clear about how seriously to take that:

• "Tools represent arbitrary code execution and must be treated with appropriate caution"².
• "Hosts must obtain explicit user consent before invoking any tool"².
• "There SHOULD always be a human in the loop with the ability to deny tool invocations"³.
• Clients "MUST consider tool annotations to be untrusted unless they come from trusted servers"³.

And the sentence that matters most for a buyer: "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD" build consent flows, access controls and data protections². The protocol describes good behaviour. Your host, and your own controls, have to deliver it.

/03What it is good at, and what it is not

Good at. Ending bespoke integrations. One standard way to connect many tools. For a team building agents, that is a real saving. It also makes the list of powers explicit: a server declares its tools, and you can read them.

Not good at. Deciding which of those powers the agent should use, when, and with whose approval. MCP connects. It does not hold your delegation of authority.

Where it goes wrong. Mixing servers. Simon Willison warns that MCP "encourages users to mix and match tools from different sources that can do different things"⁵. One server reads private data. Another fetches web pages that might carry instructions. A third can send email. Together they form his lethal trifecta⁵, and no single server looks dangerous on its own.

Tokens. The security guidance says "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server"⁴. In plain terms: a server should not be handed your user's ERP token and pass it through. Ask how each server authenticates to the target system, and as whom.

/04What to check

Before a server goes in:

1. /01

   Who publishes it, and who maintains it? Treat it as a supplier.

2. /02

   List its tools. Which read, which write, which send data out?

3. /03

   Which credential does it use in the target system? Its own, scoped identity, or a person's?

4. /04

   What does your host do before a tool runs? Ask the user, check a policy, or nothing?

5. /05

   Which other servers will run alongside it? Does the combination give the agent private data, untrusted input and a way out?

6. /06

   How is it updated? Pinned version, or whatever ships next?

/05Where it is going

MCP has become the default way to connect agents to tools, and the number of public servers keeps growing. Our view: buyers will soon keep an approved-server list the way they keep an approved-software list, with owners and review dates. The protocol will keep improving its authorisation story. It will still leave the question "should this agent do this, now?" to you, because the spec says so.

/06Gatehouse fit

Gatehouse sits between the agent and the systems its tools reach. Whatever server the agent calls, the action is checked against signed rules before it runs. Anything the rules do not name is refused and recorded, so a new server adds no powers until someone signs them in. Holds go to a named approver. For why a pinned plugin is not a safe plugin, read the Plugin4Shell post.

/07At a glance