Reduce the parity gap btw cli and mcp

[vitali87]

[vitali87]

This issue has no body, so before proposing any implementation here is the measured gap. Enumerated from codebase_rag/cli.py (@app.command) and codebase_rag/mcp/tools.py (MCPToolName) on main at 0.0.702: 19 CLI commands, 18 MCP tools. Similar totals, almost disjoint purposes.

In the CLI, absent from MCP

Analysis and lifecycle capability an agent simply cannot reach:

CLI command	MCP equivalent
dead-code	none
stats	none
verify-index	none
diff-index	none
export	none
optimize	none
doctor	none
trace	none as a tool (the string appears in tools.py only via traceback/root-cause wording)
workspace, language, graph-loader	none

Process lifecycle -- start, stop, status, daemon, mcp-server, help -- is arguably NOT parity-relevant: an MCP server should not start or stop itself. I would exclude those from scope rather than count them as gaps.

In MCP, absent from the CLI as direct commands

MCP tool	CLI
FLOW_VERDICT	none
EXPLAIN_TRACEBACK	none
RANK_ROOT_CAUSES	none
SEMANTIC_SEARCH, STRUCTURAL_SEARCH, STRUCTURAL_REPLACE, SURGICAL_REPLACE_CODE, QUERY_CODE_GRAPH, GET_CODE_SNIPPET, READ_FILE, WRITE_FILE, LIST_DIRECTORY	reachable only inside the start agent REPL, not as commands

What the shape suggests

The gap is not one surface trailing the other; they were built for different users and drifted. Two distinguishable kinds of gap, which probably want different treatment:

1. Analysis the agent cannot reach (dead-code, stats, verify-index, diff-index, export). These look like the valuable half: an agent asking "what is unreachable in this repo" or "is my index stale" currently cannot. Each is a thin wrapper over machinery that already exists.
2. Agent tools with no scriptable entry point (flow-verdict, explain-traceback, rank-root-causes). Valuable for CI use -- cgr flow-verdict in a pipeline -- but it is a different audience, and three of these are the newest features in the repo (Traceback to graph correlation: rank root cause candidates via CALLS/FLOWS_TO, served over MCP #227, Epic: dynamic runtime call-graph capture (hybrid static/dynamic analysis) #1244), so their interfaces may not be settled enough to freeze into CLI commands yet.

What I need from you before doing anything

Which direction, and how much. My reading is that (1) is worth more than (2) and that dead-code, verify-index and stats as MCP tools are the highest value per unit of work, since an agent that can ask "is this index current" before trusting a query is strictly better than one that cannot. But that is a product judgement about who this tool is for, and I would rather not pick it for you -- especially on an issue whose body is empty, where I would be inventing the requirement and then satisfying it.

Say which subset you want and I will take it. Nothing here is blocked on anything technical.

[vitali87]

Taking this. The issue has no body, so recording the scope I measured before starting, since "parity gap" could mean several things.

Comparing the two tool surfaces (normalising the three known renames: query_graph/query_code_graph, replace_code/surgical_replace_code, create_file/write_file), five CLI capabilities have no MCP equivalent:

CLI tool	Assessment
find_duplicate_code	accidental gap — read-only, already implemented
get_function_source	accidental gap — read-only, already implemented
web_search	deliberate — see below
research	deliberate — see below
execute_shell	deliberate, and a security decision

web_search and research should stay out. Issue #1128 moved web search behind a sandboxed research sub-agent precisely so external web content never shares a context with repository reads, and MCP's ask_agent never wired web_search in the first place — I verified that, it is the no-external-content configuration already. Adding them to MCP would reopen the boundary that issue closed.

execute_shell is not a parity bug either. Exposing arbitrary shell execution over MCP is a decision for the maintainer, not something to close quietly under a parity ticket.

So I am scoping this to the two accidental gaps: expose find_duplicate_code and get_function_source over MCP. Both are read-only, both already exist as CLI tools, and both fit the existing registration pattern in codebase_rag/mcp/tools.py.

If the intended scope was broader — or if shell-over-MCP is actually wanted — say so and I will adjust rather than assume.

[vitali87]

claimed by fix/clean-remedy-strings

[vitali87]

claimed by fix/clean-remedy-strings (session: fix-doc-qualified-name). Branch name is the audit record; session name is the address a peer can reach me on. Both drift independently, so neither is derivable from the other.