Loading ToolBench
A demonstration MCP server repository containing two services: a Leave Manager server for managing employee leave requests and balances, and a Weather MCP server for retrieving weather forecasts and alerts
The server implements 7 tools across leave management and weather domains. Tool naming follows verb_noun convention (submit_leave_request, approve_leave_request, etc.), which is good. However, descriptions are inconsistent in quality and depth. Input schemas are present and well-typed with proper JSON Schema format, but parameter descriptions vary in completeness. Error handling is minimal, most tools lack recovery guidance or actionable error messages. The server bundles two unrelated domains (leave management + weather), which violates composition principles. Resources are implemented (employees://all, leave-requests://all), but tool output lacks structured documentation and pagination. STDIO-only transport is a hard limitation.
Approve a pending leave request
Deny a pending leave request
Find an employee by name using fuzzy matching
Get weather alerts for a US state.
Get weather forecast for a location.
Submit a new leave request
Update the leave balance for an employee
Tool descriptions are generic and lack WHEN/WHY context. E.g., 'Get weather alerts for a US state' does not explain when to call this vs alternatives, what format results are returned in, or how it chains to downstream tools.
approve_leave_request and deny_leave_request both take 'approved_by' parameter (a string name, not an ID). This is user-friendly but exposes a risk: there is no validation that the manager name is real or authorized. No permission-gate pattern is implemented to verify the caller is actually a manager.
Error handling is absent from tool implementations. No error messages guide recovery (e.g., 'Employee not found. Call find_employee() with a partial name'). Errors likely surface as stack traces or generic exceptions rather than actionable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No input validation on date formats (start_date, end_date). The parameter description says 'YYYY-MM-DD format' but there is no runtime validation. An agent passing '2024-13-45' or '2024/07/01' will fail with an unguided error.
leave_type parameter in submit_leave_request has description '(annual, sick, personal, etc.)' but is not declared as an enum in the schema. Free-form strings invite hallucinated values. Should be constrained: enum=['annual', 'sick', 'personal'].
Resource endpoints (employees://all, leave-requests://all, etc.) return plain text strings. No structured output format is documented. For agents to extract data reliably, resources should return JSON or a documented text format, not free-form text.
Server bundles leave management (HR domain) and weather (weather domain) into one MCP server. This violates composition principle, each domain is independent and should be a separate tool server. Mixing unrelated domains confuses tool discovery and violates the 'exactly one thing' rule.
No output schemas are documented. Tool descriptions do not specify what fields are returned or their types. Agents cannot reliably parse responses or plan downstream calls without knowing the output structure.
No pagination or result limits documented. If get_all_leave_requests or find_employee returns a large dataset, context window will be exhausted. Should accept 'limit' and 'offset' parameters and cap results to 20-50 items.