/

/

Model Context Protocol (MCP)

Model Context Protocol (MCP)

MCP is an open protocol that lets AI models connect to external tools and data sources through a standard interface — and, in doing so, creates a new supply chain to secure.

ON THIS PAGE

Definition

Why it matters

Use cases

Key features

FAQ

Definition

The Model Context Protocol (MCP) is an open standard for connecting AI models to external tools, data sources, and systems through a single, consistent interface. Introduced by Anthropic and now adopted across the industry, it plays a similar role for agents that ODBC played for databases: one protocol instead of a bespoke integration per pairing.

An MCP deployment has three parts:

  • MCP host — the application the user interacts with, such as an IDE, a desktop assistant, or an agent runtime.

  • MCP client — the component inside the host that speaks the protocol.

  • MCP server — a process exposing capabilities to the model: tools it can call, resources it can read, and prompts it can use.

Servers can run locally over stdio or remotely over HTTP. Once connected, the model discovers the available tools from the server's own metadata and can invoke them as part of its reasoning.

Why it matters

MCP is what turns a language model into an operator. It is also where an organisation's agent estate quietly acquires a supply chain.

Servers are code, and most of them are third-party

Adding an MCP server usually means running someone else's process with the user's privileges. Community servers are installed from registries and package managers with the same casual trust as a VS Code extension, and they frequently ship with broad filesystem, shell, or network access.

Tool descriptions are untrusted input

The model reads each server's tool metadata to decide what to call. That metadata is attacker-controllable on a malicious or compromised server, which makes it a direct prompt injection vector — the model is influenced merely by connecting.

Credentials concentrate

An MCP server typically holds long-lived tokens for the system it fronts. Compromise the server and you inherit its access, without ever touching the underlying platform's login flow.

Nobody has an inventory

MCP servers are added per developer, per machine, per project. There is rarely a central record of which servers exist, what they can reach, or who approved them — which is exactly the shadow AI problem in a new form.

Dash's research on this includes CVE-2026-38924: unauthenticated RCE in the Serena MCP server.

Use cases

Legitimate MCP deployments in enterprises typically cover:

  • Developer tooling. Servers exposing repositories, build systems, test runners, and issue trackers to coding agents.

  • Knowledge access. Read-only servers over documentation, wikis, and data warehouses so agents answer from current internal sources.

  • Operational automation. Servers fronting ticketing, monitoring, and incident tooling so agents can triage and update records.

  • Internal platforms. Purpose-built servers that expose a narrow, reviewed slice of a proprietary system rather than granting raw API access.

  • Cross-vendor integration. A single agent working across CRM, storage, and messaging without bespoke connectors for each.

The security-relevant question for each is identical: what can this server reach, which identity does it act as, and who can see what it did?

Key features and benefits

Governing MCP well means treating servers as production software, not developer convenience.

  • Inventory. A live register of every MCP server in use, across every workstation and environment, including transport, version, and origin.

  • Approval and provenance. A reviewed allowlist with a known publisher and pinned version for each entry, so an update cannot silently change behaviour.

  • Scoped credentials. Per-server, least-privilege, short-lived tokens — never a shared admin credential fronting a whole platform.

  • Tool-metadata inspection. Treat tool names and descriptions as untrusted content and check them for injected instructions.

  • Runtime session visibility. A record of which tools were called, with which arguments, by which agent, on whose behalf.

  • Action-level enforcement. Block a tool call at the moment of invocation when it falls outside policy, rather than reviewing it afterwards.

Frequently asked questions

What does MCP actually standardise?

The interface between an AI application and an external capability. Instead of writing a custom integration for every model-and-system pairing, a system exposes one MCP server that any MCP-capable client can use. It standardises discovery and invocation of tools, resources, and prompts — not the model, and not the security model.

Are MCP servers a security risk by default?

The protocol itself is not the risk; the deployment usually is. Servers commonly run with the invoking user's privileges, hold long-lived credentials, and come from third parties. Risk is driven by scope, provenance, and visibility rather than by the protocol.

How is an MCP server different from a plugin or an API integration?

Functionally it is similar, but the consumer is a model rather than deterministic code. The model chooses whether and how to call each tool based on natural-language descriptions, so behaviour is probabilistic and steerable by any content the model has read.

Can you allowlist MCP servers?

Yes, and you should — pinned to publisher and version. Allowlisting alone is not sufficient, because an approved server can still be over-permissioned or compromised upstream, so pair it with scoped credentials and runtime monitoring.

Does Dash cover MCP servers?

Yes. Dash discovers MCP servers across the estate, maps what each one can reach, and monitors tool calls at runtime with session and intent context, so risky invocations can be detected and blocked as they happen.

See what your agents are actually doing.

Dash discovers every AI agent, tool, and MCP server across your estate, understands session and intent, and enforces policy at runtime.