A remote MCP server providing calculator tools without authentication
Two tools with minimal but present schemas and descriptions. Tool naming follows verb_noun pattern (add, calculate), which is good for LLM parsing. However, descriptions are very short (11-43 chars, below baseline of 194 chars), parameter descriptions are minimal, and output schemas are not documented. Error handling exists for divide-by-zero but is not systematic. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite correct risk classification. Schemas use Zod validation at runtime but descriptions lack detail about constraints, expected return formats, and when to use each tool.
Simple addition tool
Calculator tool with multiple operations
Tool descriptions are extremely short (11-43 characters vs. baseline 194 chars). 'Simple addition tool' and 'Calculator tool with multiple operations' lack context about when to use each tool, what they return, and dependencies between them.
Parameter descriptions are missing or minimal. The 'operation' enum in calculate tool has only 'The arithmetic operation to perform' but does not explain valid values, consequences of division by zero handling, or how results are formatted.
Output schemas are not documented. The tools return { content: [{ type: 'text', text: String }] } but this structure is not declared in any tool metadata. LLMs cannot plan downstream calls or extract return values reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing despite correct risk classification (READ_ONLY). Modern MCP spec supports tool annotations in the protocol; these tools should declare readOnlyHint: true.
Error handling is ad-hoc. Divide-by-zero returns a plain text message 'Error: Cannot divide by zero' but does not classify the error as retryable or user-fixable, and does not guide recovery. Other invalid inputs (e.g., operation='invalid') are not caught.
Input validation is incomplete. The 'operation' enum is validated via Zod at runtime, but no description explains the constraint. Numeric 'a' and 'b' parameters have no documented range or bounds.