AI Coding Context Layer - MCP server that makes AI coding assistants understand team-specific codebase patterns
CodeContext MCP exposes 3 tools with significant definition gaps. Tool naming follows verb_noun convention (get_, list_) which is good. However, only 1 of 3 tools has a complete input schema visible in the source code (get_codebase_context in mcp-server.js). The other two tools (list_repositories, get_pattern_details) are referenced but their schemas are not shown in the provided source. Descriptions are present but generic (10-50 chars for list_repositories, get_pattern_details). Parameter descriptions are minimal or absent. No output schemas are documented. Error handling is basic (missing API key/repo ID checks exist but no recovery guidance). The server is STDIO-only, which caps protocol readiness at 50 regardless of definition quality.
Get team-specific coding patterns and conventions for the current codebase. Use this tool when: - Starting to write new code - Adding a new feature or API endpoint - Implementing error handling - Writing database queries - Adding authentication - Creating components The tool returns patterns for: error handling, imports, naming, structure, API format, validation, database, and auth.
Get detailed information about a specific pattern type
List all indexed repositories available for context
Two of three tools (list_repositories, get_pattern_details) have no visible input schemas in source code.
Tool descriptions for list_repositories and get_pattern_details are under 20 characters ('List all indexed repositories available for context' is 51 chars, acceptable, but 'Get detailed information about a specific pattern type' is 54 chars, both are minimal). These descriptions lack WHEN to use and WHAT the tool returns.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract fields without knowing response structure. Baseline: 100% of A+ tools have documented return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Parameter descriptions are sparse. 'repo_id' in get_codebase_context lacks format/constraint guidance. 'pattern_type' in get_pattern_details has enum but no description of what each pattern type reveals. Baseline: 100% of A+ tool params have descriptions.
Error handling is minimal. Only checks for missing API_KEY and REPO_ID. No guidance on what to do if API call fails, times out, or returns no patterns. Per pattern:recovery-guide, errors must tell LLM what to do next.