Problem
The `codedb_remote` MCP tool implementation in `src/mcp.zig` supports 11+ actions and a `backend` parameter, but the `inputSchema` JSON only advertises 4:
\"action\":{\"type\":\"string\",\"enum\":[\"tree\",\"outline\",\"search\",\"symbol\"]}
The implementation actually accepts:
- codegraff: `tree, outline, search, meta`
- wiki: `tree, outline, search, symbol, policy, deps, score, cves, commits, branches, dep-history`
Plus a `backend` parameter (`codegraff` | `wiki`) and a `scope` parameter (`runtime` | `all`) for score/cves.
LLMs reading this schema can't discover ~7 actions that actually work. They learn about them only by trial-and-error or by reading docs separately.
Proposal
Update the inputSchema to:
- Enum the full action list
- Document the `backend` parameter explicitly
- Note action × backend matrix in the description, OR have a separate `actions` endpoint (see related issue)
- Add `scope` for score/cves
- Add the new params from the pagination issue (`limit`, `offset`, `prefix`, `since`)
Why
The schema is the only contract LLMs see. Hidden capabilities = unused capabilities.
Problem
The `codedb_remote` MCP tool implementation in `src/mcp.zig` supports 11+ actions and a `backend` parameter, but the `inputSchema` JSON only advertises 4:
The implementation actually accepts:
Plus a `backend` parameter (`codegraff` | `wiki`) and a `scope` parameter (`runtime` | `all`) for score/cves.
LLMs reading this schema can't discover ~7 actions that actually work. They learn about them only by trial-and-error or by reading docs separately.
Proposal
Update the inputSchema to:
Why
The schema is the only contract LLMs see. Hidden capabilities = unused capabilities.