MCP server: compute the duration between two dates in years/months/days.
Single tool 'between' has a clear, action-oriented name and reasonable description (118 chars, within 10-1024 range). Input schema is present with proper JSON Schema structure and type declarations. However, the schema lacks descriptions for the 'to' parameter (only has 'Optional ISO 8601 end. Defaults to now.' in the tool description, not in the schema itself). Output schema is completely undocumented, the tool returns an AgeResult object with 8 fields (years, months, days, total_days, total_hours, total_seconds, display, from, to) but LLMs have no visibility into this structure. Error handling is basic: catches exceptions and returns error messages, but does not guide recovery or categorize errors. No parameter validation constraints (min/max, regex patterns) are documented.
Compute the duration between two ISO 8601 dates as { years, months, days } plus total seconds/hours/days.
Output schema completely undocumented. Tool returns AgeResult with 8 fields (years, months, days, total_days, total_hours, total_seconds, display, from, to) but LLMs cannot see the structure. This violates pattern:tool and forces LLMs to guess field names for downstream reasoning.
Input schema parameter 'to' lacks description in the schema object itself. The tool description mentions 'Optional ISO 8601 end. Defaults to now.' but this text is not in the inputSchema.properties.to.description field. LLMs may not parse tool-level descriptions when reading schemas.
No parameter validation constraints documented. The 'from' parameter accepts any string; no regex pattern, length limit, or format constraint is declared. Invalid dates are caught at runtime with a generic error 'invalid date: <input>' rather than preventing invalid input upfront.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Error handling is minimal and not actionable. When date parsing fails, the error is 'age failed: invalid date: <input>', it does not guide the LLM on what format is expected or how to recover. No error categorization (retryable vs. user-fixable).
Tool is idempotent and read-only (no state modification), but this is not declared via tool annotations (readOnlyHint). LLMs cannot infer safety from the definition alone.