Small but complete MCP 2.x server exposing tools for creating and searching notes, plus a resource for reading note content. Includes input validation and idempotency support.
Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Descriptions are present but minimal (Spanish text, 60-90 chars). Input schemas show types but lack comprehensive parameter descriptions. No output schemas documented. Error handling absent. Idempotency key on create_note is good, but overall quality falls well below production baseline (194 char avg description, 100% param coverage in A+ tools).
Crea una nota. Repetir la misma idempotency_key devuelve la original sin duplicarla.
Busca notas por palabras en título y contenido; es una operación de solo lectura.
Descriptions are too brief (60-90 chars vs 194 char baseline). Spanish descriptions lack clarity on WHEN to use each tool and what it returns. 'Busca notas por palabras...' does not explain output structure or pagination behavior.
No output schema documented for either tool. LLMs cannot plan downstream calls or extract fields without knowing response structure. create_note should document returned note_id, title, content, idempotency_key. search_notes should document result array structure, total count, and pagination.
Parameter descriptions are minimal or missing context. 'Idempotency key for deduplication, 8-128 characters' does not explain WHY idempotency matters or what happens if the same key is reused. 'Search query, minimum 2 characters' lacks guidance on query syntax (exact match? substring? regex?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
No error handling guidance. What happens if title exceeds 120 chars? If content is empty? If search returns 0 results? LLMs need actionable error messages and recovery paths, not silent failures or generic 400 errors.
search_notes limit parameter defaults to 5 but lacks guidance on pagination. No mention of offset, cursor, or total_count. If results exceed 5, how does the agent fetch more? Undocumented pagination forces wasteful retry loops.