MCP server that provides documentation generation for Rust functions
Single tool with critical gaps. Tool 'generate_doc' has a basic description (54 chars, within bounds) and a single parameter with type and description. However, schema is minimal, output structure is completely undocumented, and error handling is generic. The tool calls external APIs (reading FORMAT_PATH environment file) but has no documented output schema, pagination guidance, or structured response definition. Baselines from the rubric show A+ tools have 100% documented return types and average description length of 194 chars; this tool at 54 chars is brief. Parameter 'code' is appropriately named and described but the tool lacks guidance on what structured output to expect. The implementation shows generic error handling with McpError but no recovery guidance for the LLM. Instructions in ServerHandler are placeholder text copied from a counter example, not relevant to documentation generation.
Generate documentation for a function
Output schema is completely undocumented. Tool returns CallToolResult::success with text content, but LLM has no visibility into structured fields, format, or expected response structure. Baselines require 100% of A+ tools to have documented return types.
Tool description is 54 characters, below the 194-char average for production tools. Missing guidance on WHEN to use this tool, WHAT it returns, and any prerequisites or dependencies. Description lacks context for LLM selection.
No documented output structure. Tool internally generates documentation but returns it as plain text wrapped in Content::text(). No schema for response fields, no field names, no guidance on structure. LLM must guess whether response includes metadata, status, or alternative formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | 2024-11-05+ | v1 |
Error handling lacks recovery guidance. McpError responses with generic messages like 'Failed to read format file' give the LLM no actionable next step.
Parameter lacks constraints and format guidance. Parameter 'code' accepts any string with no documented constraints on length, language dialect (Rust variant?), or expected function signature format. Baseline: constrained inputs prevent hallucinated values.
ServerHandler instructions are placeholder text ('This server provides a counter tool that can increment and decrement values') unrelated to documentation generation. Misleading to LLM about actual server capabilities.