Loading ToolBench
A multi-server MCP setup with Java HTTP server for stock tools and Python stdio server for employee info, integrated with an LLM client
This MCP server exhibits fundamental quality gaps across naming, descriptions, and schema documentation. Four tools are defined, but examination reveals: (1) Tool names lack consistent verb-noun structure and some are ambiguous or contain typos. (2) Descriptions are extremely brief (mostly 10-30 chars), falling well below the baseline of 194 chars and failing to answer WHAT, WHEN, or WHY for LLM tool selection. (3) Input schemas are minimally documented, only string types visible, no enums, ranges, or validation rules. (4) No output schemas are documented, preventing agents from understanding what fields to expect or how to chain tools. (5) No parameter descriptions beyond 'Company name' or 'Employee name', critical context is missing. (6) Error handling is absent from all tool definitions. The codebase shows Spring AI annotations but lacks the rigor required for agentic tool composition.
Get all companies
Get company by name
get stock bt company's name
Get information about a given employee name
Tool descriptions are critically brief (5-8 characters). The rubric requires 10-1024 chars; baseline is 194 chars. 'Get all companies', 'Get company by name', 'get stock bt company's name' lack WHEN/WHY context. LLMs cannot select tools effectively without context on when to call each one vs. alternatives.
No output schemas documented for any tool. Agents do not know what fields to expect (e.g., getAllCompanies returns a List<Company>, but the Company structure, price, employees, country, is not declared in the tool definition). This breaks tool chaining and forces agents to guess field names.
Inconsistent naming convention. Tools mix camelCase (getAllCompanies, getCompanyByName) with snake_case (get_infos_about). The rubric baseline shows 90% of A+ tools use verb_noun pattern. Inconsistency confuses LLMs during tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Typo in getStockByCompanyName description: 'get stock bt company's name' (missing 'y' in 'by'). Typos in descriptions damage LLM parsing and professionalism.
Parameter descriptions are absent or trivial. 'name' appears as a parameter in three tools, but no description explains: is it the full company name or a substring? Case-sensitive? Abbreviation allowed? This forces agents to guess valid input formats.
No enum constraints on 'name' parameters. The rubric states: 'When a parameter accepts one of a known set of values, declare it as an enum.' getCompanyByName and getStockByCompanyName operate on a fixed list of 10 companies (visible in source), but the 'name' param is free-form string. This invites hallucinated company names not in the database.
No error handling guidance in tool definitions. If getCompanyByName is passed an invalid company name, the tool definition provides no error recovery hint (e.g., 'Not found? Try getAllCompanies() first to see available options.'). Agents are left guessing on failures.
getAllCompanies accepts no parameters but returns a fixed list of 10 companies. Per the rubric, 'tools returning lists should accept page/offset and limit parameters.' Without pagination, this is acceptable for small datasets, but the description should state the limit (max 10 companies returned).
Tool composition risk: getCompanyByName and getStockByCompanyName both take a 'name' parameter, but it is unclear whether they accept identical values or different formats. If one expects 'OCP Group' and the other 'ocp-group', the agent wastes calls on mismatches. Parameter naming should be explicit (e.g., company_name for both).