A Model Context Protocol server for managing customer data with tools, resources, and prompts for database operations
Single tool with incomplete but present schema and description. Tool naming follows verb_noun pattern (add_customer). Description is adequate at 47 characters. Input parameters have types and descriptions, but output schema is undocumented. Error handling returns structured errors but lacks recovery guidance. Overall quality is below median due to missing output documentation, no pagination support (tool modifies state but returns no guidance on result structure), and lack of idempotency markers. No tool annotations present.
add customer by name, age, type and interests
Output schema is not documented. Tool returns text response but LLM cannot infer structure or what field names to expect in follow-up calls.
Tool description (47 chars) lacks actionable context. Does not explain WHAT happens (record is persisted to database), WHEN to use it (creating new customer records), or any prerequisites.
No tool annotations present. Tool is a write operation (Risk: WRITE) but lacks destructiveHint or idempotentHint, so LLM cannot determine retry safety.
Error handling returns error messages but does not guide recovery. 'Error: <message>' tells LLM nothing about whether to retry, ask user, or abort.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'type' has generic name and description 'The type of the customer'. LLM cannot infer valid values. No enum constraint; description does not state expected values or format.
No pagination or result limits documented in tool or implementation. Tool succeeds silently without returning created customer ID, preventing LLM from chaining to downstream tools that need customer_id.
Tool is not idempotent. Multiple calls with identical parameters will create duplicate customer records. No idempotent handling (e.g., deduplication key) or documentation.