Skip to content
Current section: MCP

Local MCP

The cedr CLI includes a local MCP server, started with cedr mcp. Your coding agent launches the process and calls its tools over stdio. The server works on your machine with your local configuration and data.

This is separate from Hosted MCP, which connects to cedr.dev over HTTPS for account and organization tools. Neither connection requires the other, and you can use both. See the MCP overview to choose a connection.

Install the CLI and confirm that cedr --version works in the environment where your coding agent runs. Then register a local server named cedr.

Terminal window
claude mcp add --scope user cedr -- cedr mcp
Terminal window
codex mcp add cedr -- cedr mcp

Use your client’s supported local stdio configuration. For clients that use an mcpServers object, the command and arguments are:

{
"mcpServers": {
"cedr": {
"command": "cedr",
"args": ["mcp"]
}
}
}

Preserve existing servers when adding this entry. The client starts and stops the process; you do not need to keep a separate terminal open, configure an HTTP URL, or expose a network port. Browser sign-in and hosted MCP authorization headers are not needed for this local connection.

If you also use hosted MCP, register that connection as cedr-cloud.

Ask your agent to list the tools from the cedr server. Confirm that route_pick, council_plan, sync_check and monitor_report are present.

With Route configured, ask it to call route_list to inspect your local routes. This does not make a pick or record a verdict.

Remove the local server with your agent’s own command, for example claude mcp remove cedr, codex mcp remove cedr or gemini mcp remove cedr, or delete the cedr entry from the client’s MCP config. Disconnect my agent in the app’s MCP page menu does this for cedr and cedr-cloud together; see Disconnect Your Agent.

Routing and Council planning use the same routes.toml as the CLI. Follow Route to create it. The search order is:

  1. The path supplied with cedr mcp --config /absolute/path/to/routes.toml.
  2. The CEDR_ROUTES environment variable.
  3. The nearest .cedr/routes.toml, searching from the server’s working directory through its parent directories.
  4. ~/.config/cedr/routes.toml, or $XDG_CONFIG_HOME/cedr/routes.toml when set.

Routing calls read the configuration again, so route changes do not require restarting the server. Your client’s working directory and environment determine which repository and configuration the server sees. Use an absolute configuration path when the client starts outside your repository.

sync_check, sync_plan and doctor accept a path argument for the repository. Without it, they use the server’s working directory. Monitor tools use the CLI’s local usage sources; see Monitor for setup and exclusions.

The local server exposes these tools. Your client discovers their arguments through MCP.

Tool Purpose
route_list List local routes, tier chains and cascade routes.
route_pick Choose a provider, model and effort for a route, and record the pick.
route_manual Tag a model you named explicitly and record the pick without routing.
route_verdict Record the outcome of a local pick after checking the work.
route_pools Read the current state of each provider’s plan.
route_history Read recent local picks, verdicts and Council results.
route_stats Summarize local picks, verdicts, timing and cascade outcomes.
council_plan Choose the reviewers for a Council route and return its quorum.
council_merge Merge submitted review reports into a pass, block or incomplete gate.
council_stats Summarize local Council gates and revision outcomes.
sync_check Check generated agent files and cached organization rules offline.
sync_plan Show proposed agent configuration changes as diffs without writing the files.
monitor_report Collect and report local coding-agent usage and estimated API-equivalent costs.
monitor_limits Refresh available plan readings and report usage windows and projections.
monitor_sources Collect local usage and report source availability and health.
doctor Diagnose the machine and repository without applying fixes.

For routing, ask your agent to call route_pick before handing work to another model, start the brief with the returned tag, then call route_verdict after checking the result. For Council reviews, use council_plan to choose reviewers and council_merge to combine their reports. The agent starts the reviewers itself; these tools do not run agents.

A local connection does not grant hosted MCP access. Local tools run with the permissions of the CLI process and can read the configuration, repository files and usage sources needed for their work. Only connect clients you trust.

Picks, verdicts and Council merges write local history. Monitor tools collect usage into the local usage database, and plan readings can contact configured sources. With Route sync configured, routing activity can trigger a background sync with cedr.dev. Local checks and history remain available without a hosted MCP connection; fresh remote readings and synchronization need network access.

  • The client cannot find cedr. Check cedr --version in the client’s environment. If its PATH differs from your shell’s, use the executable’s absolute path as the server command.
  • Starting cedr mcp in a terminal appears to do nothing. It waits for MCP messages on stdin. Register it with your client so the client can communicate with it.
  • Routing reports no configuration or shows the wrong routes. Check the server’s working directory, CEDR_ROUTES and configuration search order. Use --config with an absolute path to select the intended file.
  • Sync or diagnostics check the wrong repository. Supply the repository’s absolute path in the tool’s path argument.
  • Monitor has missing readings. Use monitor_sources and follow Monitor to check source availability and exclusions.
  • The tools differ from this guide. Check the installed CLI version, update it using Install the CLI, then reconnect the client so it discovers the tools again.