MCP server that provides tax calculation tools for customers based on specific periods of months
Single tool with basic structure but significant quality gaps. Tool name 'get_tax_for_customer' follows verb_noun convention (+). Description exists but is minimal (47 chars, below 50-200 char LLM-optimized range). Input schema present with types (string, integer) but parameter descriptions are generic and lack constraints. No output schema documented. No error handling guidance. Tool logic is simplistic (hardcoded switch statement) with no validation of inputs (customer name, month range). No pagination, no structured output format specified. Lacks idempotency guarantees and error recovery patterns.
Gets tax for customer for specific period of months
Parameter descriptions are generic and lack constraints. 'customer' and 'forMonths' have minimal guidance; no mention of valid customer names, month range limits, or format expectations.
No output schema documented. Tool returns a free-text string; LLM cannot parse structured fields or plan downstream operations. Violates pattern:response-shaper.
No input validation or error handling. Tool accepts any customer name and any integer; no bounds on forMonths (negative, zero, or 999999 all accepted). No error messages guide LLM recovery.
Tool description (47 chars) is below LLM-optimized range (50-200 chars). Lacks WHEN to use, prerequisites, or distinction from similar tools. Does not explain the tax calculation logic or customer-specific multipliers.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Hardcoded business logic (customer 'Method' multiplies by 2, 'Tax' divides by 2) is not documented in tool description. LLM cannot infer why results differ by customer without explicit guidance.