MCP Tools

Codeep integrates with the Model Context Protocol (MCP) to extend its capabilities with external tools like web search, GitHub explorer, and image understanding.

Available MCP tools

Tool	Provider	What it does
`Web Search`	Z.AI / MiniMax	Real-time web search results
`Web Reader`	Built-in	Fetch and parse any web page
`GitHub Explorer`	Built-in	Browse GitHub repos and files
`Image Understanding`	MiniMax	Analyze and describe images

ℹ

MCP tools are enabled automatically when you have the appropriate provider configured. No extra setup required.

Using MCP tools

MCP tools are available to the agent automatically. Just describe what you want and the agent will use the appropriate tool. For example:

“Search for the latest Next.js 15 breaking changes” → uses Web Search
“Read the docs at https://example.com/api” → uses Web Reader
“Look at this GitHub repo and summarize the API” → uses GitHub Explorer

Custom MCP servers

Built-in MCP tools (web search, github read, image vision) are surfaced through Codeep's provider integrations and need no configuration. For everything else, Codeep 2.0 is a full MCP client: both transports (stdio + Streamable HTTP), tools / resources / prompts / sampling, capability negotiation with roots, auto-restart on crash, mid-run catalog refresh.

Configure MCP servers from any of these sources — Codeep merges all of them on session start. On name collisions, higher-precedence sources win (top of the list beats bottom):

Source	Path	Scope
`ACP client`	passed via session/new mcpServers field	Zed, Claude Desktop, etc. — the editor knows its own config, so it wins
`Project config`	<workspace>/.codeep/mcp_servers.json	This repo (commit it to share)
`.mcp.json`	<workspace>/.mcp.json	Cross-tool standard (Claude Code, Cursor, Kilo Code)
`Global config`	~/.codeep/mcp_servers.json	All projects on this machine

★

Already have a .mcp.json from Claude Code or Cursor? Codeep reads it as-is — point your other tools and Codeep at the same file and they'll all stay in sync.

ℹ

Workspace-sourced servers (project config and .mcp.json) need a one-time per-workspace approval before they spawn — Codeep prompts on first run, or use /mcp trust. Global and ACP-provided servers start without a prompt.

Config file shape

Each entry chooses ONE transport. command + args means stdio (a child process Codeep spawns). url + optional headers means Streamable HTTP (Codeep POSTs to that endpoint per the MCP spec).

{
  "mcpServers": {
    "fs": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-filesystem", "/path"],
      "env": { "READ_ONLY": "1" }
    },
    "remote": {
      "url": "https://mcp.example.com/",
      "headers": { "Authorization": "Bearer xxx" }
    }
  }
}

Managing servers interactively

Inside any Codeep session (TUI, Zed, VS Code extension):

/mcp                              # list connected servers + tools + spawn errors
/mcp browse                       # curated marketplace of popular servers
/mcp browse <id>                  # details + env-var hints for one entry
/mcp install <id> [extra args]    # wire it into project config + spawn
/mcp add <name> <command> [args]
/mcp remove <name>
/mcp reload                       # re-read config + re-register
/mcp resources                    # list resources servers expose
/mcp read <uri>                   # fetch one resource's contents
/mcp prompts                      # list prompt templates
/mcp prompt <server> <name> k=v

/mcp add writes to the project file and live-spawns the new server (no session restart). /mcp remove kills the running child and removes the entry from the project file. /mcp reload picks up edits you made to the JSON file directly.

In the VS Code extension, the same operations are available from the command palette:Codeep: Add MCP Server…, Codeep: Remove MCP Server…, and Codeep: Open MCP Servers Config. No JSON editing required.

Lifecycle

Each server runs as a child process. Tools are exposed to the agent under <server>__<tool>and injected into the model's tool catalog so it can call them natively. Processes are torn down when the session ends or the CLI exits (SIGTERM/SIGINT). A server that crashes is auto-restarted up to 3 times in a 60 second window with exponential backoff; persistent failures appear in /mcp.

Resources & prompts (auto-injected as virtual tools)

Every server that exposes resources (URI-addressable context blobs) or prompts (named templates) automatically gets four virtual tools the agent can call natively:

<server>__resource_list <server>__resource_read <server>__prompt_list <server>__prompt_get

You can still poke at them yourself with /mcp resources, /mcp read <uri>, /mcp prompts, and /mcp prompt <server> <name> key=value — useful for exploration and debugging.

Sampling — Codeep as the host LLM

Servers that advertise the sampling capability can ask Codeep to generate a completion on their behalf via sampling/createMessage. We bridge to chat() using the active provider and model; the server gets the assistant text back. No tool use is forwarded — sampling is text-in / text-out by design.

Client capabilities

Codeep advertises roots (with listChanged: true) and sampling in the initialize handshake. It also subscribes to tools/list_changed, resources/list_changed, and prompts/list_changed notifications — when the server reports new tools mid-session, the agent picks them up on the next iteration without a restart.

★

MCP tool definitions are auto-injected into the agent's tool catalog on every iteration. The agent picks them alongside built-in tools without you having to mention them by name. pre_tool_call and on_error hooks apply to MCP tools too — see the Lifecycle Hooks section under Commands.

Zed Editor (ACP)Git Integration