Loading ToolBench
MCP server for bus inventory and route management with Redbus integration
The MCP server defines 5 tools with basic schemas and descriptions, but falls significantly short of production quality. All tools have descriptions (positive), but they are generic and lack LLM optimization guidance. Descriptions average ~80 chars, below the 194-char production baseline and insufficient to guide agent behavior (e.g., 'Get available bus routes...' lacks WHEN to use and prerequisites). Input schemas are present but minimal, all parameters use simple string types with no enums, ranges, format constraints, or validation guidance. No output schemas are documented anywhere in the provided code. Tools lack error handling guidance, idempotence markers, and composition hints. Tool names lack action verbs (sd_pairs, lis_source_destination, route_details_filtered are noun-heavy and fail the verb_noun pattern). Parameter naming is inconsistent: vendor_id vs lis_source_id vs doj (cryptic abbreviation). No indication of pagination, result limits, or how results chain between tools.
Get available bus routes for a given vendor, source, destination, and date without requiring user state
Query the database to get LISSourceID and LISDestinationID for a given vendor, source, and destination
Query Redbus for detailed route information using LISSourceID, LISDestinationID, and DOJ. Filters results by vendor ID and returns comprehensive route details including pricing and boarding points
Get all source-destination pairs available for a specific vendor
Retrieve all cities served by a specific vendor from the external API
Tool names lack action verbs. 'sd_pairs', 'lis_source_destination', and 'route_details_filtered' are noun-heavy and fail the verb_noun pattern. LLMs cannot infer intent from these names alone. Should be: 'list_source_destination_pairs', 'get_lis_ids', 'get_route_details_by_lis'.
No output schemas documented. Tools return unstructured data with no field definitions, types, or pagination info. LLMs cannot plan downstream calls or extract required fields. Every tool must document its return structure (e.g., 'Returns: {routes: [{id, name, departure, price}], total_count, next_cursor}').
Descriptions are generic and lack LLM guidance. Baseline production avg is 194 chars; these average ~80 chars and omit WHEN to use, prerequisites, and next steps. Example: 'Get available bus routes for a given vendor...' does not explain: When does the agent call this vs route_details_filtered? Must lis_source_destination be called first? Are results paginated?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 6 | - | v1 |
Parameters use generic string types with no constraints. Production tools use enums (vendor_id must match known vendors), patterns (date must be YYYY-MM-DD, validated), and ranges (limit 1-100). Currently, LLMs can pass any string, risking API errors and invalid queries.
Parameter naming is inconsistent and cryptic. 'doj' (date of journey) and 'lis_source_id' use domain jargon and abbreviations opaque to LLMs. 'vendor_id' vs 'source_id' vs 'lis_source_id' create confusion: are source_id and lis_source_id the same thing? Standardize to vendor_id, source_location_id, destination_location_id, travel_date.
No error handling guidance. Tools provide no indication of what can fail, what errors are retryable, or how to recover. E.g., if vendor_id is invalid, does the agent retry? Call vendor_cities first? No guidance means agents will fail silently or loop infinitely.
No composition hints or tool chaining guidance. The relationship between bus_routes and route_details_filtered is unclear. Must lis_source_destination always be called before route_details_filtered? Can agents skip steps? Undocumented dependencies cause silent misuse.
No pagination support or result limit documentation. When vendor_cities or sd_pairs return large result sets, there is no indication of how many items are returned, whether results are truncated, or how to fetch additional pages. Large unbound results waste tokens and risk context window overflow.