MCP server for filing structured complaints about missing or confusing information
The server defines 5 tools with explicit schemas, descriptions, and input validation constraints. Tool names follow verb_noun conventions (file_complaint, list_complaints, resolve_complaint, search_complaints, get_cache_stats). Schemas are visible and properly structured with JSON Schema types. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. The server lacks tool annotations (readOnlyHint/destructiveHint/idempotentHint), and descriptions are present but generic. Output schemas are not documented, which violates the pattern:tool requirement. Error recovery guidance is absent.
File a structured complaint about missing or confusing information
Get cache performance statistics
List all filed complaints with optional filtering
Mark a complaint as resolved
Search complaints by content
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing the response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The LLM cannot determine which tools are safe to retry. 'file_complaint' and 'resolve_complaint' are clearly write operations but lack the destructiveHint.
Pagination not properly documented. 'list_complaints' accepts limit (max 100) but no offset, cursor, or total_count guidance. Returning up to 100 items at once risks context window exhaustion.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Error handling guidance absent. Tool descriptions do not explain what errors are possible, what they mean, or how to recover. E.g., 'resolve_complaint' with invalid complaint_id returns nothing, should it be a 404 with 'Complaint not found, try search_complaints'?
'search_complaints' description does not specify which fields are searched or query syntax. 'query' parameter lacks format guidance (regex? natural language? exact match?).
'resolve_complaint' description (35 chars) is too brief and does not explain idempotency or side effects. Does calling it twice with the same complaint_id cause errors?
'get_cache_stats' tool purpose is unclear. Description does not explain what cache it monitors, what metrics are returned, or when an agent should call it. This looks like an internal tool leaking into the public API.
Response chaining broken. 'file_complaint' likely returns a complaint_id, but 'resolve_complaint' requires complaint_id with a strict UUID pattern. The two tools cannot chain if the IDs don't match the expected format.