Loading ToolBench
A multi-protocol readability metrics server supporting FastAPI and MCP (Model Context Protocol) for web, PDF, and cloud sources.
The server defines 3 tools with proper naming conventions (verb_noun pattern: get_*, analyze_*). All tools have descriptions in the 100-200 char range, which meets the baseline. However, input schemas lack critical details: the TextSourceModel is referenced but its field descriptions and constraints are not visible in the provided code excerpt. The rubric requires seeing actual schema definitions and parameter constraints. Tool output schemas are entirely undocumented, there are no descriptions of what these tools return, their structure, or what fields downstream tools can expect. Error handling is present but minimal; no recovery guidance visible. The tools operate on a shared TextSourceModel which is good for composition, but without visibility into that model's constraints, schema scoring is conservative.
Performs comprehensive two-axis document assessment: Axis A readability scores and Axis B AI writing pattern detection for text from direct input, a web URL, or a GCS PDF URI.
Detects AI writing patterns and calculates Axis B editorial tell scores for text from direct input, a web URL, or a GCS PDF URI.
Calculates readability scores (Axis A) for text from direct input, a web URL, or a GCS PDF URI.
Input schema TextSourceModel not fully visible in source code. While the schema is referenced via model_json_schema(), the actual field constraints, validation rules, and parameter descriptions within the model cannot be verified from the provided excerpt.
No output schema documentation visible. The tools return results from metrics.py functions, but the structure, field names, types, and descriptions of those results are not documented in the tool definitions or visible in the provided code. LLMs cannot plan downstream operations without knowing what fields are returned.
Parameter descriptions in input schema are minimal ('Direct text input', 'URL of web page or PDF', 'Google Cloud Storage PDF URI'). These lack actionable constraints: character limits, format requirements (e.g., 'gs:// must be a valid GCS URI'), or mutual exclusivity rules ('Exactly one of text, web_url, or gcs_pdf_uri must be provided').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
No error handling or recovery guidance visible in the tool definitions. The code snippet shows execute_readability_tool() with a try/except block, but the error responses and recovery suggestions are not documented in the tool descriptions. An LLM encountering a malformed URI or network failure will not know how to proceed.
Tool descriptions do not explain when to use each tool vs. the others. All three tools accept the same input and have similar names. LLMs may conflate get_readability_scores vs. analyze_document (which returns both Axis A and B). The description should clarify: 'Use this tool if you only need readability metrics. For AI pattern detection, use get_ai_pattern_scores. For both, use analyze_document.'