Loading ToolBench
This is Vilnius transport MCP server for claude desktop proof of concept
Server defines 2 tools with basic schemas and descriptions present. However, descriptions are quite short (averaging ~60 chars, below the 194-char production baseline), parameter descriptions are minimal or absent, and output schemas are not documented. Naming follows verb_noun convention appropriately (find_stops, find_closest_stop), but parameter documentation is weak. No parameter type constraints (enums, ranges, patterns) beyond basic JSON Schema types. No error handling guidance in tool descriptions. The tools are read-only and well-scoped (one responsibility each), meeting composition pattern, but lack the depth expected for production quality.
Find the closest public transport stop to given coordinates
Search for public transport stops by name
Tool descriptions are too short (48-65 chars; production baseline 194 chars). Missing WHEN to use each tool and any prerequisites. Descriptions do not explain differences between the two find_* tools or guide tool selection.
Parameter descriptions are minimal. The 'name' parameter in find_stops has only 'Full or partial name of the stop to search for' (52 chars); no guidance on partial matching behavior, name case sensitivity, handling special characters, or error recovery if no matches found. The 'coordinates' parameter in find_closest_stop has only format example but no guidance on precision, valid Vilnius bounds, or what 'closest' means (by straight-line distance? by travel time?).
Output schemas are not documented in the tool definitions or code. The server uses gtfs_kit to return results, but the exact structure (field names, types, pagination support, total count) is not visible. LLMs cannot plan downstream operations without knowing what fields will be returned.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No error handling guidance in tool descriptions. If find_stops returns zero matches, or if coordinates in find_closest_stop are outside Vilnius bounds, what should the LLM do next? Should it retry with modified input, or call the other tool? No recovery hints provided.
No pagination support documented for find_stops. If a search returns many stops (e.g., searching for 'Vilnius' could match dozens), is there a limit? Can the LLM paginate results? The production baseline for tools returning lists is to support offset/limit + total count.
No input validation constraints visible. The 'coordinates' parameter accepts any string and calls parse_coordinates(), but the description does not specify acceptable precision (e.g., 'to 5 decimal places'), bounds (must be within Vilnius/Lithuania), or what happens if parsing fails. The 'name' parameter has no min/max length, character restrictions, or partial-match guidance.