The Model Context Protocol (MCP) is an open protocol introduced by Anthropic in November 2024 that standardizes how AI applications connect to external tools and data sources. It defines servers, which expose tools, resources, and prompts, and clients, which consume them, over a transport layer supporting both local and remote connections.
- An open protocol standardizing how AI applications reach tools and data
- Servers expose tools and resources; clients consume them over a transport
- On a trajectory to become the dominant integration protocol for agents
- Every MCP server is an attack surface and every tool call a control point
Why is the Model Context Protocol important?
MCP matters because it is on a trajectory to become the dominant integration protocol for AI agents, in the way HTTP became the dominant integration protocol for the web. Major model labs and platform providers have adopted it as a first-class interface for agent tool use since Anthropic introduced it, and Anthropic subsequently donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation, placing it under neutral governance.
The enterprise security implications follow directly from that adoption. Every MCP server exposing tool calls to an agent is a potential attack surface, and every MCP-mediated tool invocation is a control point. A protocol that standardizes how agents reach systems also standardizes where an enterprise can inspect and govern that reach.
That second half is the part most organizations have not yet acted on. Standardization is usually discussed as an integration convenience. For a security team it is the first time agent tool use has had a consistent shape to enforce against.
What is the Model Context Protocol?
MCP is an open specification defining how an AI application requests capability from an external system. It replaces the pattern where every application built bespoke integrations with a common interface any compliant client can consume.
The architecture has two roles. An MCP server exposes capability in three forms: tools, which are functions an agent can invoke; resources, which are data an agent can read; and prompts, which are reusable templates. An MCP client, typically an AI application or agent runtime, discovers what a server offers and calls it.
Discovery is the mechanism worth understanding for security purposes. A client asks a server what tools it provides, and the server returns a tool list including descriptions of what each tool does. The agent then reasons over those descriptions to decide what to call – which means the tool list is input to the model's decision-making, not merely configuration.
The transport layer supports local connections over stdio and remote connections over Streamable HTTP, so an MCP server may run on a developer's laptop or as a remote third-party service.
Types of MCP servers and transports
MCP deployments divide by where a server runs and by who operates it, and both determine the risk.
By transport, local servers communicate over stdio and run on the same machine as the client, which is common for developer tooling and coding agents. Remote servers communicate over Streamable HTTP and may sit anywhere, including outside the organization.
By operator, first-party servers are built and run by the enterprise itself, exposing internal systems to its own agents. Third-party servers are operated by a vendor as a service. Community servers are installed from public registries, and this is the category that most often enters an environment without review.
By exposed capability, tool servers provide functions with side effects – the highest-consequence category, since a tool call changes something. Resource servers provide read access. Prompt servers provide templates, and are the least discussed and not risk-free, since a template shapes model behavior.
Model Context Protocol & Onyx
Onyx governs MCP traffic at the protocol level rather than inferring it from network or application signals. The MCP Scanner identifies servers across the environment, including the ones nobody registered. The MCP Gateway sits at the MCP level and routes traffic, which is what creates a chokepoint where none existed. Runtime guards then apply policy on both tool calls and tool list responses.
That last point is the one worth noting. Inspecting the tool call catches an agent doing something it should not. Inspecting the tool list response catches the server telling the agent something it should not – a poisoned description that steers the reasoning loop before any call is made. MCP security covers both directions.
