MCP Protocol

What is MCP?

The Model Context Protocol (MCP) is an open specification for connecting AI models to external data sources and tools. Published by Anthropic under the MIT License, MCP is a standardized way for AI agents to discover and call tools provided by external servers.

MCP solves a coordination problem: every AI coding agent previously had to invent its own plugin system, and every tool had to be reimplemented for each agent. With MCP, a tool that speaks the protocol works with any agent that speaks the protocol.

Canopy implements the MCP server side. AI agents — Claude Code, Cursor, Zed, Continue, and others — implement the client side.

Note

Gulf Shield Technologies is not affiliated with or endorsed by Anthropic. “Model Context Protocol” and “MCP” are used in their descriptive sense — Canopy implements this open specification.

How Canopy uses MCP

Transport

Canopy uses the stdio transport: the MCP client launches canopy serve as a subprocess and communicates over stdin/stdout with JSON-RPC 2.0. No HTTP server, no ports, no networking between agent and Canopy — they are the same process group, talking through pipes.

{
  "mcpServers": {
    "canopy": {
      "command": "canopy",
      "args": ["serve", "."]
    }
  }
}

You rarely write this by hand: canopy setup wires every AI editor it detects, and canopy serve --print-mcp-config prints the exact block for your repo — in Claude Code, Cursor, or Zed format (--client claude|cursor|zed) — without starting the server.

Add --watch and the server re-indexes changed files as you edit, so answers track the working tree. --dashboard starts the local web dashboard alongside the server (Solo tier and above).

Protocol messages

Three exchanges matter:

1. initialize — the client announces capabilities; Canopy returns its server info and its instructions text.
2. tools/list — Canopy returns exactly one tool: canopy_answer, with its JSON Schema.
3. tools/call — Canopy routes the question to a recipe, executes it against the local index, and returns the answer.

The instructions teach phrasing

The server’s instructions text — delivered to the agent at initialize — no longer has to explain a tool catalog. It teaches one thing: phrasing picks the recipe. Name the entity type, keep backticks around paths and symbols (`src/lib.rs`, `MyStruct`), prefer a specific question shape over a vague one, and treat “No strong match in this repository for …” as a real signal.

This is why Canopy works in a properly configured agent without any user-written system prompt: the agent learns how to ask from Canopy itself, at the start of every session.

The one tool

canopy_answer takes a natural-language question (required), an optional format — concise (compact, the default behavior) or standard (fuller answer with citations) — and an optional cap on internal recipe calls. The full shape list and routing behavior are on One Tool: canopy_answer; the schema is in Reference: MCP Tools.

Why only one? A tool catalog is a context tax: schemas consume the agent’s context and orchestration consumes turns. In Canopy’s control benchmark, an agent handed the full v1 multi-tool surface spent 2.3×–5.8× more than shell. The single routed call — the routing and orchestration moved server-side — is where the measured lift comes from.

Which agents work with Canopy?

Any agent that supports MCP stdio transport. canopy setup auto-wires every editor it detects; per-editor guides cover manual setup:

Agent	Guide
Claude Code	How-To: Set up Claude Code
Cursor	How-To: Set up Cursor
Zed	How-To: Set up Zed
Continue (VS Code)	How-To: Set up Continue

For everything else in the How-To section, the pattern is the same: point the client’s MCP config at canopy serve.