grove

MCP integration

Grove embeds an HTTP MCP server in-process. Agents — Claude Code, Codex, opencode, or any other MCP-aware client — discover it via a config pointer Grove writes for them, and get 27 tools across 9 groups: the comment review loop, walkthrough authoring, task lifecycle, vault notes, the directive reference, IDE control, debug-trace capture, and tree-sitter + LSP code navigation.

How agents connect

  • In-process HTTP server, not stdio. The port is dynamic per Grove launch.
  • Per-task URL routing. Each task's MCP endpoint embeds the task id (/mcp/task/<task_id>), so tools default to the right task without the agent passing taskId. Agents only pass it explicitly to reach across tasks.
  • Config is written at chat launch, per agent provider — Claude gets .mcp.json, Codex .codex/config.toml, opencode opencode.json — into the worktree and the task folder. Writing at launch keeps the port current, and only the agents you actually use get config files.
  • No network exposure. Bound to 127.0.0.1, no TLS, no auth — same trust model as your shell.

Chats against the repo root (rather than a task) bind to a _workspace pseudo-task, so workspace-level agents get the full tool surface with paths resolved to the repo itself.

The tool surface

Comments — the review loop

Tool Purpose
comments_list_pending The agent's inbox — unresolved comments only
comments_list_all Full history, including resolved
comments_create Drop a comment on file:line
comments_reply Append a reply to a thread
comments_resolve Mark resolved

See Comments for the protocol these implement.

Walkthroughs

Tool Purpose
walkthrough_create Multi-step guided explanation, each step pinned to file:line
walkthrough_list List walkthroughs and their steps

See Walkthroughs.

Tasks

Tool Purpose
task_get Task metadata: id, name, branch, base, status, paths
task_list Every task in the workspace
task_create New task + worktree off the base branch; an initialPlan becomes the task's plan.md

Agents can spawn subtasks — an agent planning a refactor can split it into parallel tasks, each with its own worktree.

Notes

Tool Purpose
note_list List the task's note folder (subdir-aware)
note_read Read a note by name or vault-relative path
note_write Create or overwrite a note — it appears live in the sidebar
note_delete Delete a note

Directives

Tool Purpose
directives_reference Returns the :grove-* directive catalog, so an agent can author live note panels correctly. See Directives.

IDE control

Tool Purpose
open_file_in_grove Open a file in the editor, optionally jumping to a line
read_file_lines Read a file with line numbers attached — exact coordinates for comments and navigation

Debug trace

Tool Purpose
debug_trace Inject a tagged print at file:line, run a command, parse the output, revert the file
debug_log_list Read the per-task trace log
debug_log_clear Truncate it

Printf debugging as a primitive: the agent observes runtime values without leaving edits behind. Languages: Rust, JS/TS, Python, Go. See Debug trace.

Code structure (tree-sitter)

Tool Purpose
document_symbols Outline of named symbols in source order
symbol_at The ancestor chain at a line — e.g. class Foo → method bar
anchors_in_scope Vault knowledge anchored to a file: every note that links to it, with lines relocated to the current source. See Wikilinks.

Code navigation (LSP)

Tool Purpose
find_references All usages of the symbol at file:line
goto_definition Definition site — across crates, node_modules, stdlib
goto_implementation Concrete implementations of an interface or trait
hover Type signature + docs

All four accept a symbol name (the server finds the column) or an exact column. find_references and goto_definition also return any vault knowledge anchored to the results — your notes travel with the code. Languages: Rust, TS/JS, Python, Go. See LSP.

What the MCP deliberately does not do

Agents already have Bash, file editing, and rg. Grove doesn't duplicate those. The MCP earns its keep where Bash can't:

  • Structured results — a sqlite-backed comment inbox, validated paths, atomic writes.
  • Editor integration — an agent writes a note and the sidebar updates live.
  • Cross-task addressing — operating on another task's notes or comments without cd.

Plain file reads, search, git operations: agents use their own tools.

Known gaps

  • Agents can author walkthroughs but not retract them (no delete/resolve).
  • Agents can create tasks but not archive or delete them.
  • No auth or per-agent permissions — the server trusts everything on localhost, like your shell does.