Loading ToolBench
A multi-component MCP demonstration with Java Spring Boot servers and Python FastMCP server providing tools for stock information and employee data
This server exhibits critical gaps in definition quality across all four tools. Three tools lack descriptions entirely (getCompanyByName, getStockByCompanyName, get_info_about), violating the fundamental pattern that every tool must have a non-empty description for LLM selection. Parameter descriptions are completely absent, even the 'name' parameters across tools have no guidance on format, valid values, or semantics. Input schemas are partially visible but lack the required descriptive metadata. The one tool with a description (getCompanies) is minimal (14 chars, below the 20-char floor). Tool naming shows some adherence to verb conventions (get_*) but lacks clarity on distinctions. Output schemas are not documented. No error handling guidance is present. The server appears to be a classroom exercise rather than a production implementation, evidenced by minimal schema detail and lack of parameter validation patterns.
Get all companies
Get Information about a given employee name: - First Name - Last Name - Salary - Email
Three of four tools (getCompanyByName, getStockByCompanyName, get_info_about in Java implementation) lack descriptions entirely. Per pattern:tool-description, every tool must have a non-empty description explaining what it does and when to use it.
All parameter descriptions are missing. The 'name' parameter appears in three tools (getCompanyByName, getStockByCompanyName, get_info_about) with zero documentation of expected format, valid values, or semantics. Per pattern:tool-description, every parameter must have a description explaining what it controls.
Output schemas are not documented for any tool. LLMs cannot plan downstream calls or extract data without knowing what fields to expect. getCompanies returns List<Company>, getCompanyByName returns Company, getStockByCompanyName returns Stock, and get_info_about returns employee details, but none of these return structures are formally documented in the tool definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
getCompanies description is 14 characters ('Get all companies'), below the 20-character floor. Per HARD SCORING RULES, descriptions under 20 chars cannot exceed 40 points. This tool provides no context on when to call it vs other discovery tools, what structure is returned, or what fields the agent should extract.
No error handling guidance exists. If getCompanyByName('InvalidCorp') is called, the tool throws 'Company not found', but the LLM has no recovery hint (e.g. 'Call getCompanies() to see available companies' or 'Try a partial name search'). Per pattern:recovery-guide, errors must guide the LLM on next steps.
Tool naming mixes conventions: Java tools use camelCase (getCompanyByName, getStockByCompanyName) while Python uses snake_case (get_info_about). Per pattern:tool and code review guidance, consistency aids LLM parsing. Additionally, 'getCompanyByName' and 'getStockByCompanyName' lack clarity on what distinguishes them, both search for company info by name, but one returns Company records and one returns Stock data. A clearer name like 'get_company_details' vs 'get_stock_price' would disambiguate.
No input validation constraints are documented. The 'name' parameter in getCompanyByName, getStockByCompanyName, and get_info_about accepts any string, but valid values are constrained (e.g. 'Maroc Telecom', 'OCP Group', etc. for companies). Per pattern:constrained-input, enum or regex constraints should guide the LLM toward valid inputs and enable self-correction.