MCP server that analyzes code repository dependencies and provides context for code understanding and modification
Contextception demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive parameter schemas, and structured output types. All 9 tools have descriptions and input schemas visible in source. However, several tools lack output schema documentation in the code, parameter descriptions are sometimes generic, and error handling guidance is minimal. The get_context tool is well-designed with flexible input (string|array) and detailed parameters; search and analyze_change tools are similarly strong. Missing: explicit output schema documentation, error recovery guidance, and tool annotations (readOnlyHint/destructiveHint). The rate_context tool is a good feedback mechanism but underutilized.
Analyze the impact of a git diff (PR or branch). Returns changed files with blast radius, aggregated must-read context, test gaps, coupling signals, and hotspots. If base is omitted, auto-detects merge-base against the default branch (main/master).
Detect representative files across architectural layers. Returns one file per archetype category, selected using structural and git signals. Use for initial codebase orientation. Optionally filter to specific categories via the 'categories' parameter. Available categories: Service/Controller, Model/Schema, Middleware/Plugin, High Fan-in Utility, Page/Route/Endpoint, Auth/Security, Leaf Component, Config/Constants, Barrel/Index, Test File, Database/Migration, Serialization/Validation, Error Handling, CLI/Command, Event/Message, Interface/Contract, Orchestrator, Hotspot.
Analyze a file's context dependencies. Returns categorized lists of files that must be understood before making a safe change. Auto-indexes the repository if needed. Accepts a single file path or an array of file paths for multi-file analysis.
Return the project's entrypoint files (main modules, CLI entry points) and foundation files (most depended-upon). Use for initial project orientation.
Return directory structure with file counts and language distribution. Use as the first call when exploring an unfamiliar project.
Output schemas not documented in source code. Tools return structured results (indexResult, statusResult, etc.) but LLMs cannot see field definitions without explicit schema documentation in tool registration.
Tool descriptions lack WHEN-to-use guidance. Descriptions state WHAT tools do but not when to call them vs similar tools (e.g., when to use get_entrypoints vs get_structure vs get_archetypes for initial exploration).
No error recovery guidance. Tools like index and analyze_change can fail (git errors, missing commits) but descriptions do not tell LLMs what to do next or which errors are retryable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Build or update the contextception index for the repository. Uses incremental indexing when possible.
Rate how useful the last get_context result was for your work. Call this after completing work on a file you previously analyzed. Reports which suggested files were useful, which were unnecessary, and which needed files were missing. Helps improve recommendation quality over time.
Search the index for files by path pattern or symbol name. Returns matching files with structural signals (indegree, role). Use type='symbol' to find files that export a specific name.
Return index diagnostics: file count, edge count, staleness, and last indexed commit.
Tool annotations missing. No readOnlyHint or destructiveHint declared. index and rate_context are WRITE operations; search, get_context, status, etc. are READ_ONLY. Annotations enable agent safety and planning.
Parameter descriptions sometimes generic. 'mode' in get_context says 'Workflow mode: plan, implement, review' but does not explain how each mode adjusts caps or when to use each. 'categories' in get_archetypes lists 18 options but no guidance on which to choose.