Loading ToolBench
A multi-server MCP implementation with leave management and Pokémon information tools
This server exhibits severe structural issues that undermine tool usability. Six tools are defined across two separate FastMCP instances (New_server/main.py and MCP_server/poke.py), but the packaging and initialization are fragmented. The New_server tools (get_leave_balance, apply_leave, get_leave_history) have basic parameter descriptions but lack output schema documentation. The poke.py tools have minimal descriptions and no parameter descriptions for async functions. Critical gaps: (1) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences (apply_leave is destructive; others read-only). (2) Descriptions are too short (avg 35 chars vs. baseline 194) and lack 'when to use' context. (3) No output schema documentation anywhere, LLMs cannot plan downstream calls. (4) No error handling guidance, functions return unstructured strings with no recovery hints. (5) Tool composition is incoherent, leave management and Pokémon lookup serve completely different domains with no logical connection. (6) MCP_server/main.py defines nothing; MCP_server/poke.py is a separate, disconnected instance. This fragmentation suggests the server was hastily assembled from unrelated examples.
Apply leave for specific dates (e.g., ["2025-04-17", "2025-05-01"])
Create a powerful squad of Pokémon for a tournament.
Check how many leave days are left for the employee
Get leave history for the employee
Get detailed info about a Pokémon by name.
List popular tournament-ready Pokémon.
No output schema documentation for any tool. LLMs cannot infer return structure, field names, or types. Impossible to plan multi-step agent workflows.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). apply_leave modifies state and is not idempotent; LLMs cannot distinguish it from read-only tools without explicit hints.
Descriptions are extremely short and lack actionable context. Average 35 chars vs. baseline 194 chars. No 'when to use' guidance. Examples: 'Check how many leave days are left for the employee' (49 chars) lacks prerequisites; 'List popular tournament-ready Pokémon' (38 chars) does not explain when to call it vs. create_tournament_squad.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Parameter descriptions missing for async Pokémon tools. get_pokemon_info('name') lacks a description of what 'name' means or accepts (e.g., case sensitivity, abbreviations). create_tournament_squad() and list_popular_pokemon() have no input params documented.
No error handling or recovery guidance. Functions return plain strings ('Employee ID not found', 'No data found...') with no actionable next steps. Try list_employees() to find the correct ID.'
Tool composition is incoherent. Leave management (E001, E002, balance tracking) and Pokémon data (Charizard, tournament squads) serve completely unrelated domains. No logical grouping or purpose. Suggests the repo is a collection of unrelated examples rather than a cohesive SRE debugging/automation tool.
Fragmented FastMCP initialization. MCP_server/main.py is empty ('Hello from pokemon!'). MCP_server/poke.py defines tools in a separate instance (mcp = FastMCP('poke')). New_server/main.py defines unrelated tools in another instance (mcp = FastMCP('LeaveManager')). Two independent servers, not a unified MCP server.
Input schema for create_tournament_squad and list_popular_pokemon is empty ({}). No parameters, no constraints, no structure to guide LLMs.
apply_leave modifies in-memory state (employee_leaves dict) without confirmation or dry-run. No idempotency guarantees. Agents will retry on ambiguous failures and double-apply leave. Per pattern:confirmation-request, irreversible operations must support confirmation.
Mock employee data is hardcoded in memory with no persistence. Once the server restarts, all leave balances reset. Not suitable for any production or even testing scenario where state must survive process restarts.