MCP server with OAuth 2.0 authorization provider running on Cloudflare Workers, demonstrating remote authentication flows
Single tool 'add' has a clear verb-noun name and basic schema with typed parameters. However, the description is minimal (22 chars) and lacks context about when/why to use it. Parameters 'a' and 'b' have type definitions and brief descriptions, meeting baseline requirements. No output schema is documented. The tool is trivial (arithmetic) and does not reflect production patterns like error handling, idempotency hints, or recovery guidance. Zod schema is present but output structure is not formally documented for the LLM.
Adds two numbers together
Tool description is too brief (22 chars). Does not explain when to use 'add' vs other arithmetic operations, prerequisites, or return format. LLMs need 50-200 char descriptions to disambiguate tool selection.
Output schema is not documented. The tool returns {content: [{type: 'text', text: string}]} but this structure is not visible in the tool definition or description. LLMs cannot plan downstream calls without knowing the response shape.
No error handling or recovery guidance. What happens if 'a' or 'b' are NaN, Infinity, or non-numeric? No error messages guide the LLM to self-correct or retry.
No tool annotations (readOnlyHint, idempotentHint). The 'add' tool is read-only and idempotent, but these hints are not declared in the schema, forcing the LLM to infer safety properties.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Parameter descriptions are minimal ('First number to add', 'Second number to add'). No format constraints, range limits, or handling of edge cases (negative numbers, decimals, very large values) are documented.