A self-hosted tool that turns git repositories into browsable knowledge bases (auto-generated docs, RAG chat, code-graph explorer) over Web UI / REST API / MCP.
Cograph demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter schemas with types and constraints, and clear descriptions. All 11 tools have descriptions (avg ~120 chars) and input schemas with typed parameters. However, output schemas are not documented in the source, parameter descriptions lack dependency hints and format guidance, and error handling patterns are absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. The write_page tool is a state-changing operation but lacks confirmation/dry-run pattern.
Symbol name to fuzzy-match against the code graph. Uses lexical + trigram match across qualified_name, name, and signature.
Traverse the code graph to find callers, callees, or both for a given symbol.
Regex pattern search across the repository checkout using ripgrep-compatible patterns.
Returns every code node in a specified file.
Returns direct child nodes (fields and methods) of a parent symbol (struct/class/interface).
List files in the repository checkout matching a glob pattern.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does search_code return? field names? structure?). Rubric baseline: 100% of A+ tools have documented return types.
write_page is a destructive, irreversible operation (ships markdown and ends agent loop) but lacks confirmation/dry-run pattern. No tool annotation (destructiveHint). Agents make mistakes, this needs a confirm_before_execute pattern.
Parameter descriptions lack format guidance and constraints. E.g., 'pattern' in grep says 'ripgrep-compatible' but does not explain what that means or give examples. 'glob' in list_files defaults to null but description does not clarify null behavior. Rubric: 'When a parameter has a regex pattern, length limit, or character restriction, state it in the description.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Read a file from the repository checkout with optional line range.
Read a code node by its fully qualified name from the code graph.
Hybrid retrieval combining lexical, symbol, and embedding hits against the code graph.
Query against the in-repo documentation corpus (markdown chunks).
Write a completed wiki page as GitHub-flavored markdown. Calling this tool ENDS the agent loop and ships the markdown verbatim.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 10 read tools should declare readOnlyHint=true; write_page should declare destructiveHint=true. This is a current MCP spec pattern (2026-07-28) that enables safer agent planning.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., what happens if grep times out? If a file is not found? Rubric: 'Error responses must tell the LLM what to do next.'