Loading ToolBench
A repository containing multiple MCP servers: a calendar integration server (ICS-based), a leave management server, and database extraction utilities
This is a multi-language server (TypeScript + Python) with 5 tools across two separate implementations. Code quality and schema definition vary significantly. The TypeScript tools (ping, getMyCalendarDataByDate) use Zod schemas with output schemas defined, while the Python tools use FastMCP decorator syntax without visible schema or input validation. Tool descriptions are present but minimal (10-40 chars). No error handling guidance, no parameter descriptions beyond simple type labels, and critical security gaps (in-memory mock data, no authentication). STDIO transport is the only visible mechanism, capping the score at 50 maximum, but definition quality issues independently score lower.
Apply leave for specific dates (e.g., ["2025-04-17", "2025-05-01"])
Fetches events from ICS calendar for a specific date.
Check how many leave days are left for the employee
Get leave history for the employee
Ping tool
Python tools (get_leave_balance, apply_leave, get_leave_history) lack visible input schemas. FastMCP decorators do not expose Zod/JSON Schema definitions in the provided source code.
Tool descriptions are extremely brief (<40 chars for most): 'Ping tool' (9 chars), 'Check how many leave days are left' (34 chars), 'Get leave history for the employee' (34 chars). These lack context on WHEN to call the tool, WHAT it returns, or prerequisites. LLMs cannot disambiguate between similar tools.
Input parameters have no descriptions. The 'date' param in getMyCalendarDataByDate and 'employee_id'/'leave_dates' in Python tools lack explanatory text. LLMs must infer meaning from names alone. Per pattern baseline, 100% of A+ tools have param descriptions; this server has 0%.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No error handling guidance. Tools return plain strings ('Employee ID not found.', 'Invalid date format.') with no actionable next steps. Per pattern, error responses must say what to do: 'Employee ID not found. Try search_employees() with a partial name.' Current errors give agents nothing to act on.
In-memory mock database with hardcoded employees (E001, E002) and no authentication. apply_leave modifies shared state without idempotency guarantees, retrying an agent call will double-deduct leave balance. Per pattern, irreversible operations (delete, send, publish, apply_leave) must be idempotent or support dry-run/confirmation.
apply_leave description says 'Apply leave for specific dates (e.g., ["2025-04-17", "2025-05-01"])', includes example values. Per pattern, LLMs latch onto examples and reuse them literally. Should use formal format constraint instead: 'Array of dates in YYYY-MM-DD format'.
Tool composition gap: no tool to search or list employees. If an agent does not know employee_id, it must guess. Pattern recommends accepting human-friendly identifiers (names, emails) and resolving to IDs inside the tool, or providing discovery tools.
Python tools return free-text strings ('E001 has 18 leave days remaining.', 'Leave applied for 2 day(s)...') instead of structured JSON. Per pattern, agents need structured output to extract data for downstream calls and continuation. Returning {balance: 18} instead of a string enables the agent to reason about the value.