Trail-code

What it does

Trail-code (formerly graft) builds a map of a repository on your own machine. It parses the source with tree-sitter into a graph of files, functions, classes and the calls between them, and keeps that graph as a local cache in a graft/ folder. Started with `trail mcp`, it gives any MCP client six read tools over the map: ranked lookup of the code behind a plain-words question, the signatures of one file, callers or callees of a symbol to a chosen depth, a regex search grouped by enclosing symbol, an overview of directories and hub files, and a drift check.

Each query first compares the working tree with the last build and re-parses only what changed, so uncommitted edits show up in answers. Building the map needs no model and no key. Plain-English summaries are an optional extra from `trail build --deep`, which sends code to a model provider you pick.

The MCP server is one piece of a bigger CLI. The same package wires hooks and a statusline into Claude Code, writes instruction files for other agents, and keeps team "learnings" as markdown in a .trail/ folder committed to git. A learning can be marked with `trail note --always-follow` so agents stop rather than go against it. Learnings reach agents through hooks and instruction files, not through the MCP tools.

A few things the README leaves out, from src/mcp/tools.ts: `trail_find_code` returns 5 results unless `limit` is set, `trail_trace_calls` walks one level of direct callers unless `depth` is raised ("all" walks the full closure), and `trail_repo_map` shows 16 directory entries unless `max_dirs` says more. When the server is started in a parent folder holding two or more git repos, the search, caller, map and freshness tools answer across all of them. The older `graft_*` names, and pre-0.8.1 names such as `graft_ask` and `graft_grep`, still work (src/mcp/tool-names.ts).

What it needs

The README installs the CLI once with `npm install -g @trailhq/trail-code` and runs `trail init` in the repo, which builds the first map and registers the server with the agents you pick. The older `@nanonets/graft` package and `graft` command run the same code. No account or key for the MCP tools. A model provider key is only needed for the optional `trail build --deep` summaries.

Limits

• Not covered Indexes the 24 languages the README lists; files in other languages are skipped
• Read only The MCP tools only read the code map; learnings are saved and checked through the CLI and Claude Code hooks
• Size cap trail_find_code returns 5 results and trail_repo_map 16 directories by default; trail_find_all is the uncapped search
• Early release Skills and the team view across repos are announced as coming soon in the README

Indexes 23 languages plus Vue single-file components; files in other languages are skipped. OCaml and Zig get symbols only, with no call edges, and the broad tier (Rust, C, C++, C#, Ruby and others) resolves calls by name rather than by type. Precise compiler-grade edges need `trail build --lsp` and a language server on PATH. The MCP tools only read the code map: saving or checking team learnings is done through the CLI and Claude Code hooks, and the shared Trail workspace for teams is announced as coming soon. Search tools return a capped top-N by default (see about); `trail_find_all` is the exhaustive one.

Who it suits

Developers who want an MCP-capable coding agent (Cursor, Codex, Gemini CLI and others) to find code, callers and blast radius in a local repository without grepping file after file, with no key and the map kept on disk. Claude Code users get the most, since the CLI adds hooks and learnings around the same map. It is a navigation aid for repos on your machine. Anyone wanting an agent to work with a code host's issues or pull requests, or a hosted index across many repos, needs a different server.