The missing context layer for AI coding agents — index a repo's git+PR history with a multi-agent pipeline, serve atoms to any agent via MCP.
Three tools with clear, detailed descriptions and well-structured schemas. All tools are READ_ONLY and properly documented with rationale and source references. However, parameter descriptions lack depth (e.g., 'k' parameter in context_query has minimal guidance on selection strategy), and output schemas are returned as JSON strings rather than formally declared. Error handling is present but generic. Tool composition is sound, each has a single responsibility. Naming follows verb_noun convention (context_query, context_list_topics, context_validate) and is clear.
List all discovered knowledge topics in this repo (clusters of related atoms). Useful for getting a high-level view of what conventions exist before diving into specifics with context_query.
Search team conventions, design decisions, deprecations, and anti-patterns extracted from this repo's git and PR history. Returns the top-k matching knowledge atoms with rationale and source references (PR numbers, commit SHAs). CALL THIS BEFORE proposing code changes or design choices in this codebase. The repo has codified rules — async-first policies, error-handling conventions, deprecation paths, anti-patterns — that your training data doesn't know about. Querying first ensures your answer reflects this team's actual conventions, not generic best-practice advice.
Check a proposed code change, plan, or diff against this repo's codified rules. Returns violations (if any) with severity, rationale, and source citations. Use this before submitting PRs to catch convention violations early.
Output schemas not formally declared. Tools return JSON strings; LLMs cannot parse structure without explicit schema documentation. context_query returns {question, atoms[], guidance}; context_list_topics returns {topics[], message?, total_atoms?}; context_validate returns unspecified structure.
Parameter 'k' in context_query lacks guidance on selection strategy. Description says 'max number of atoms to return (default 5)' but does not explain when to increase/decrease k, performance implications, or recommended range. Baseline: param descriptions average 72 chars; this is ~40 chars.
Parameter 'mode' in context_validate has enum constraint but lacks rationale for each mode. Description says 'heuristic (fast, deterministic, no API calls) or llm (slower, uses Haiku to judge violations)' but does not explain when to choose each or cost/latency tradeoffs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Error handling is generic. When DB not found, returns JSON with 'error' field, but does not guide LLM on recovery (e.g., 'Run contextlayer index <repo> first'). Baseline: A+ tools include recovery guidance in error responses.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are READ_ONLY and idempotent, but this is not declared in the MCP schema. LLMs cannot infer safety properties without explicit hints.