Archaeological intelligence about a git repository, over MCP. It doesn't act on your code — it answers questions about its history.
mcp-dossier provides 5 read-only analysis tools with clear, domain-specific purposes. All tools have descriptions (avg 120 chars) and input schemas with typed parameters. However, schemas lack detailed parameter descriptions, most params have only 1-2 sentence descriptions without format constraints, ranges, or examples. Output schemas are not documented in the visible code. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool names are clear (coupled-files, file-dossier, hotspots, repo-briefing, review-gap) but lack action verbs (get_, list_, analyze_). No tool annotations (readOnlyHint, etc.) despite all being read-only. Composition is sound, each tool has one responsibility and tools chain naturally (e.g., file-dossier uses coupled-files internally).
Identifies files that frequently change together with a target file, excluding large commits (tsunamis) that create false coupling
Provides detailed historical analysis of a specific file including churn, risk profile, ownership, coupled files, and recent commit subjects
Identifies files with high churn and complexity, ranked by a score combining commit frequency and indentation-based complexity
Provides a high-level summary of the repository including total commits, file count, date range, and top 5 authors by commit count
Suggests files that likely should have been changed together with the provided changed files, based on historical coupling patterns
Tool names lack action verbs. Names like 'coupled-files' and 'hotspots' are nouns; LLMs infer intent better from verb_noun patterns (e.g., 'analyze_coupled_files', 'list_hotspots'). Current names are domain-clear but not action-clear.
Parameter descriptions are minimal (1-2 sentences). Missing format constraints, ranges, and examples. E.g., 'maxCommitFiles' lacks min/max bounds; 'minCoChanges' lacks guidance on typical values. Descriptions should be 50-150 chars and include constraints per pattern:constrained-input.
Output schemas not documented in visible code. LLMs cannot plan downstream calls or extract fields without knowing response structure. All 5 tools lack documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
No tool annotations despite all tools being read-only. Adding readOnlyHint=true to all 5 tools would signal safety to agents and enable optimizations (e.g., parallel execution, no confirmation needed).
Error handling not visible in tool definitions. No recovery guidance, error classification, or actionable messages. E.g., if a file path is invalid, what should the LLM do next? Search for similar files? Retry with a different path?