Loading ToolBench
Java client library for the Model Context Protocol (MCP) Toolbox. Provides a comprehensive SDK for building MCP servers and clients in Java.
This is an SDK/framework repository, not a functional MCP server with live tool implementations. Tool definitions are extracted from TEST code only (McpToolboxServiceTest.java), not from actual tool implementations or server code. No implementation source code is visible in the provided materials. All 4 tools have descriptions and input schemas defined in test assertions, but the schemas are minimal (empty for find-bus-schedules, basic string params for others). Parameter descriptions are present but generic. Output schemas are completely undocumented. The 'book-ticket' tool lacks a proper output schema definition.
Book a bus ticket for a passenger on a specific trip
Find all available bus schedules from the transit system
Query bus schedules for a specific route between origin and destination
Search transit policies for a given query
Tool definitions exist only in test code, not in actual server implementation or registration code. No visible tool.json, no @ToolDefinition annotations, no MCP protocol message handlers shown.
find-bus-schedules has empty input schema ({}). Tool provides no way for client to customize behavior.
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, making downstream composition impossible.
Parameter descriptions are generic and lack constraints. 'Origin city/location' and 'Destination city/location' don't specify format, length, or how to handle ambiguous names (e.g. 'Springfield' exists in 30 states).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
book-ticket has 'passenger_name' as a required parameter marked '(bound parameter)', unclear what 'bound' means. Is it pre-filled by the LLM? From session context? Undocumented binding rules prevent proper usage.
No error handling documented. What happens if a bus route doesn't exist? If a ticket booking fails (already sold out, invalid passenger)? How should the LLM recover?
No pagination support visible for list-like operations (find-bus-schedules, search-policies). If there are hundreds of bus schedules or policies, returning all in one response blows context window.
query-schedules and search-policies accept free-form strings with no enum or validation. LLMs may hallucinate invalid city names or policy keywords, wasting API calls.
Tool descriptions are 50 - 60 characters, near the 10 - 1024 character baseline but lacking context on WHEN to use each tool. What distinguishes 'find-bus-schedules' (all schedules?) vs 'query-schedules' (filtered schedules?)? This ambiguity forces LLM to guess.
book-ticket is marked as a WRITE tool but has no confirmation/dry-run pattern and no audit trail requirements. Agents can book tickets without user confirmation, risking unwanted charges or reservations.