MCP server with OAuth 2.0 authentication provider running on Cloudflare Workers, demonstrating authorization flows
The server defines a single tool 'add' with minimal documentation. The tool has a basic Zod schema (a: number, b: number) but lacks descriptions for parameters, output structure documentation, and any error handling guidance. The tool name 'add' is a verb but is overly generic for a mathematical operation, 'add_numbers' would be clearer. Parameter descriptions are null/missing entirely, violating the critical requirement that every parameter must have a non-empty description. No output schema is documented. The implementation is simplistic (basic arithmetic) with no error handling, validation guidance, or recovery hints. This server fails multiple critical checks from the Definition Quality rubric.
Missing parameter descriptions: 'a' and 'b' parameters have null/empty descriptions, violating critical rule that every parameter must have a non-empty description explaining what it controls.
Missing tool description: The 'add' tool lacks any description. Without a description, LLMs cannot determine when or why to select the tool.
Undocumented output schema: The tool returns structured content (text response) but does not document the output schema. LLMs need to know what fields to expect.
No error handling or validation: The tool accepts any numbers without documented constraints, limits, or error guidance. Missing validation rules and recovery hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Generic tool name: 'add' is too generic. Recommend 'add_numbers' to be more specific and self-documenting. Tool names should start with a clear action verb and specify the resource/domain.
No parameter type hints in description: While Zod schema enforces number type, the parameter descriptions (currently null) should state the expected format, range, and constraints explicitly for LLM clarity.