MCP Server generating code that adheres to DCI architecture principles.
Server has 4 tools with clear verb-noun naming (prepare_, scaffold_, get_). Descriptions are present and reasonably detailed (100-150 chars each). Input schemas use Zod with proper types and enums. However, output schemas are not documented, responses are free-form text or JSON without declared structure. Parameter descriptions are adequate but lack format constraints (e.g., no regex patterns, min/max for arrays). Error handling returns text messages but does not categorize errors as retryable/user-fixable/fatal. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Missing guidance on when to call each tool vs. alternatives (e.g., when to use get_dci_example vs. prepare_dci_refactor).
Returns targeted DCI examples for named implementation topics. Use only when a specific rule is ambiguous.
Returns the complete human-readable DCI guide, including explanatory material and examples. Not for normal code-generation workflows.
Call this tool when the user asks to refactor code into the DCI paradigm. Pass the target language. Returns only the normative implementation rules and validation checklist required for the refactor by default. It does not include tutorials, analogies, or examples unless detail requests them.
Call this tool when the user provides a mental model or user story and wants you to write a new DCI Context from scratch. Returns only the normative implementation rules and validation checklist required to translate it into code by default. It does not include tutorials, analogies, or examples unless detail requests them.
Output schemas not documented. Tools return free-form text or JSON without declared structure. LLMs cannot plan downstream calls or extract structured data reliably.
Tool descriptions lack guidance on when to call each tool vs. alternatives. E.g., get_dci_example says 'Use only when a specific rule is ambiguous' but prepare_dci_refactor also returns rules. Ambiguous selection logic.
No tool annotations despite all tools being read-only. Missing readOnlyHint in schema would help LLMs understand safety and retry semantics.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Error handling returns plain text messages without categorization. Errors like 'language is required' or 'No examples found' do not indicate whether the error is retryable, user-fixable, or fatal.
Parameter 'topics' in get_dci_example has minItems=1 but description says 'required when detail is examples', inconsistent. Other tools have topics with default=[] but no validation that examples detail requires topics.