MCP server for managing employee leave balances, applications, and history
LeaveManager has 3 tools with schemas and descriptions visible in source. However, significant gaps in parameter descriptions, output documentation, and error handling guidance severely limit agent effectiveness. All tools are directly defined in main.py via @mcp.tool() decorators. Tool names follow verb_noun convention (get_*, apply_*), which is good. However, parameter descriptions are minimal or absent, output schemas are undocumented (tools return plain strings rather than structured objects), and error handling provides no recovery guidance. The apply_leave tool performs a destructive write operation without confirmation or dry-run capability, violating the confirmation-request pattern. Output strings mix multiple data points in unstructured text, forcing LLMs to parse natural language rather than accessing typed fields.
Apply leave for specific dates
Return remaining leave balance for an employee
Return leave history for an employee
Output schemas are undocumented. All three tools return plain strings rather than structured JSON objects with typed fields. LLMs must parse natural language text (e.g. 'E001 has 18 leave days remaining') instead of accessing leave_balance and employee_id as structured fields.
Parameter descriptions are missing or minimal. 'employee_id' is described as 'The employee identifier' (8 chars, too generic). 'leave_dates' has a basic description but no format or validation hints (e.g. 'ISO 8601 dates', 'YYYY-MM-DD'). Parameter descriptions must be 10-100 chars and explain format, constraints, and valid ranges.
No error recovery guidance. When tools return 'Employee ID not found', the LLM has no instruction on what to do next (e.g. 'Try searching available employees'). Error messages must guide the agent toward recovery, not just state the problem.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
apply_leave performs destructive state modification (deducts leave balance, modifies history) without confirmation or dry-run capability. This violates the confirmation-request pattern. Agents may approve leave by mistake. Should support a 'dry_run' parameter or require explicit confirmation.
Tool descriptions are too short and lack actionable details. get_leave_balance: 'Return remaining leave balance for an employee' (54 chars, acceptable but generic). No mention of what happens if employee_id is invalid, or when to use this vs get_leave_history. Descriptions should answer: what, when, what returns, what if it fails.
No pagination or result limiting documented. While current dataset is small (2 employees), get_leave_history could return hundreds of entries. No mention of limits or pagination support.
No input validation or constraint documentation. apply_leave accepts leave_dates as array but does not validate format, check for duplicates, reject weekends, or document expected ISO 8601 format. Parameter descriptions must specify format (ISO 8601 string, YYYY-MM-DD).