III · Tool Use & EnvironmentMature★★

Model Context Protocol

also known as MCP, Open Tool Protocol

Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.

This pattern helps complete certain larger patterns —

  • used-byCross-Domain Enterprise Agent Network★— Decompose enterprise agency into domain-specialised agents (finance, supply chain, HR, service), each grounded in its own system of record, and route artefacts between them through a standardised inter-agent protocol.
  • used-byTool Discovery★— Let the agent discover available tools at runtime rather than hardcoding the tool list at agent build time.
  • used-byTool Search Lazy Loading★— Defer loading tool schemas into the context window until a search step shows they are needed.
  • used-byTool/Agent Registry★— Maintain a single queryable catalogue of both available tools and available agents, with metadata (capability, cost, latency, quality) the agent can use to pick the right one for a task.

Context

An organisation operates several agent hosts at once: an IDE plugin, a desktop assistant, a custom CLI, a teammate's editor agent. Each of them wants access to the same underlying tools (a GitHub integration, a Postgres query tool, a documentation search) and ideally the team should be able to write each tool once.

Problem

Without a shared protocol, every tool has to be re-implemented as a vendor-specific function-calling adapter for each host. The same GitHub integration ends up rewritten three times with subtly different argument names and error shapes, and the implementations drift as each host evolves. Authentication is rewired per host, and there is no clean way for a new agent host to discover what tools already exist in the organisation.

Forces

  • Agents need a stable contract; tool authors need freedom to evolve the implementation.
  • Local (stdio) and hosted (HTTP) deployments have different operational shapes but should expose the same surface.
  • Auth must travel without leaking host credentials to every tool.

Example

A developer writes a 'GitHub PR review' tool once and exposes it via Model Context Protocol. Now it works in Claude Desktop, in Cursor, in their custom CLI agent, and in their teammate's VS Code agent — without rewriting the integration four times. The host and the tool only need to agree on MCP, not on each other's internal details.

Diagram

Solution

Therefore:

Tools live behind a server speaking a common protocol. Hosts list available tools, call them with typed arguments, and receive typed results. The protocol covers discovery, invocation, errors, and (in some implementations) prompts and resources alongside tools.

What this pattern forbids. Agents can only see tools advertised by an MCP server; servers can only advertise tools matching the protocol's typed shape.

The smaller patterns that complete this one —

  • generalisesTool Use★★— Let the LLM produce typed calls against an external toolkit instead of producing free-form text the surrounding system has to parse.
  • generalisesMCP-as-Code-API★— Materialize MCP servers as a directory of typed code wrappers so the agent writes code that imports them and large tool outputs flow between calls inside the sandbox without ever entering the model's context window.
  • generalisesMCP Bidirectional Bridge★— Run a framework as both MCP client (consuming external MCP servers as tools) and MCP server (publishing its own agents, tools, and workflows back over MCP) so capabilities flow both directions across the protocol boundary.

And the patterns that stand alongside it, or against it —

  • complementsInter-Agent Communication★— Define a protocol for agents to exchange tasks, capabilities, and results across process or vendor boundaries.
  • complementsSecrets Handling★— Ensure the model never receives secrets in plaintext; tools resolve credentials from references at runtime.
  • complementsTool Output Poisoning Defense★— Treat tool output as untrusted content and apply instruction-stripping plus per-tool trust labels.
  • composes-withTranslation Layer★★— Insert a typed boundary between the agent's clean domain model and a messy or legacy external API.
  • alternative-toSynthetic Filesystem Overlay·— Project heterogeneous enterprise data sources into a single Unix-like tree exposed through filesystem primitives so the agent reuses path semantics it already knows instead of learning a bespoke API per source.
  • complementsDecentralized Agent Network·— Agents publish signed DID+JSON-LD identity records so any peer can discover and verify them without a central registry — the agent equivalent of the open web.
  • alternative-toAgent Adapter★★— An interface layer connecting an agent's tool-calling protocol to heterogeneous external tools, normalizing their schemas into one the agent expects.
  • complementsHierarchical Tool Selection★— Organise tools into a tree of categories so the agent first picks a branch and then a specific tool within it.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in recipes

Used in frameworks

Show 41 more

References

Provenance