Loading ToolBench
MCP server for querying Berlin public transport (BVG) stop information
Single tool 'stop_information' has critical definition gaps. Description is minimal (34 chars, below 50-char baseline for clarity). Input schema is present but incomplete: 'stop' parameter lacks required/properties structure and has no description in the schema itself, only in the rubric text. No output schema documented. No error handling guidance. Tool name lacks action verb prefix (should be 'get_stop_information'). No parameter validation or constraints. Inferred tool registration (ToolRegistry pattern) caps individual tool at 50 max, but definition quality issues push it lower.
Get stop information from bvg
Tool name lacks action verb. 'stop_information' should be 'get_stop_information' to signal the action clearly to LLMs.
Description is too short (34 chars). Baseline is 50 - 200 chars for clarity. Current text 'Get stop information from bvg' lacks context on when to use it, what it returns, or prerequisites.
Input schema is incomplete. 'stop' parameter has no 'required' array, no 'description' field in the schema object itself (only in rubric text), and no type validation. Schema should declare required: ['stop'].
No output schema documented. LLMs cannot plan downstream calls or extract fields. Tool returns TextContent but structure is undocumented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2026-07-28+ | v2 |
Error handling is minimal. Handler checks for null 'stop' but returns generic 'parameter required' message. No guidance on what to do if API fails, no retry hints, no available alternatives on 404.