Loading ToolBench
A Python-based MCP client for human resources operations, providing tools for email management, employee onboarding, geolocation, cloud file operations, expense reporting, and company policy queries.
This HR client exposes 11 tools with mixed quality. While all tools have basic descriptions and visible schema definitions, the descriptions are frequently vague, lack actionable context, and several tools exhibit poor naming patterns (e.g., 'save_draft_email_local_files' vs 'save_draft_email_new' are redundant and ambiguous). Parameter descriptions are sparse or generic. Output schemas are undocumented, we cannot see what these tools return, making it impossible for LLMs to chain results. Error handling is absent from visible code. Several tools combine multiple concerns (e.g., 'onboard_new_employee' requires coordinating image + CSV + multiple fields). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite several tools having write/irreversible risk profiles. Naming inconsistencies ('save_draft_email_local_files' vs 'save_draft_email_new') violate the single-tool-per-action pattern. Average across tools yields a 52, fair but with major gaps in error guidance, output documentation, and composition.
Adds two numbers and returns the sum.
Generate an employee badge using first name, last name, employee number, and existing employee image name.
Generate an expense report for the specified cloud folder. Example folder_path: expense_receipts/20250831_20250913
Download a file from the specified input_file_path, the input_file_path indicated by the user should not be changed in any way. local_destination_path supplied by the user should not be changed in any way. The path should not include the file name, just the directory to save the file to.
Get geolocation coordinates based on city and state
Initiate the employee onboarding workflow. Requires an employee photo image and a CSV file (one header row + one data row with employee and address fields), both located in the ALLOWED directory. The allowed directory is assumed to be known by this tool, do not prepend the allowed directory to the file paths supplied by the user. This tool will prepend the allowed directory automatically.
Duplicate/Ambiguous Tool Naming: 'save_draft_email_local_files' and 'save_draft_email_new' both save draft emails but with unclear differentiation. LLMs cannot reliably distinguish when to use which. This violates the single-tool-per-action principle and forces unnecessary LLM reasoning. Recommendation: merge into one tool or rename clearly (e.g., 'save_draft_email_with_local_attachments' and 'save_draft_email_with_server_attachments').
Missing Output Schema Documentation: None of the 11 tools document what they return. Without visible response schemas, LLMs cannot plan downstream tool chains or extract required fields for subsequent calls. This blocks tool composition and forces extra discovery calls. Recommendation: document return types for all tools (e.g., 'Returns: {success: boolean, message: string, draft_id?: string}').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Query company policies using semantic similarity search.
Save a draft email by providing email recipient address, email subject, body of the email and a list of attachments. The allowed directory is assumed to be known by this tool, do not prepend the allowed directory to what the user entered as a filename or directory/filename. This tool will prepend the allowed directory to the filename or directory/filename that were supplied by the user.
Save a draft email via the Java endpoint /save-draft-email. attachment_paths should reflect exactly what the user entered; this tool will prepend LOCAL_FILE_STORAGE. storage_attachments should include any server-side attachment references.
Summarize images in the specified cloud folder. Example folder_path: expense_receipts/20250831_20250913
The input_file_path should reflect exactly what the user entered, do not modify in any way. Upload a file to the specified destination path. If the user doesn't specify a destination path, leave destination_path blank. It should be assumed the file is located in the allowed directory you have access to.
Generic Parameter Descriptions: Parameters like 'folder_path' in 'summarize_images_in_folder' and 'create_expense_report' lack concrete guidance (format, examples, constraints). The docstring says 'Example folder_path: expense_receipts/20250831_20250913' but this is embedded in the tool description, not the parameter description. LLMs need per-parameter format hints. Recommendation: add to each parameter description: expected format, allowed characters, length constraints, and whether it's relative/absolute.
Missing Tool Annotations for Risk Profile: Multiple tools modify state (WRITE, IRREVERSIBLE) but lack MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). 'onboard_new_employee' is marked IRREVERSIBLE but no annotation signals this to the client. 'save_draft_email_*', 'upload_file_to_cloud', 'download_file_from_cloud', 'create_employee_badge' all mutate state without idempotent/destructive hints. Recommendation: add tool.inputSchema.properties._meta.destructiveHint=true for destructive operations and idempotentHint=true for safe-to-retry calls.
No Error Handling Guidance: The visible code shows function signatures and docstrings but no documented error cases or recovery paths. Tools like 'onboard_new_employee' (IRREVERSIBLE) and 'upload_file_to_cloud' provide no guidance on what happens if the operation fails, is it retryable? Should the user be prompted? What specific errors can occur? Recommendation: document error scenarios in tool descriptions (e.g., 'Errors: FileNotFound (not retryable), UploadTimeout (retryable), PermissionDenied (user-fixable)').
Overly Complex Tool Composition: 'onboard_new_employee' combines five independent concerns in one tool: (1) validate employee image, (2) validate CSV structure, (3) extract employee data, (4) upload files, (5) initiate workflow. If any step fails, the entire operation fails with no partial-success recovery. Recommendation: split into 'validate_onboarding_files', 'initiate_employee_onboarding', and 'get_onboarding_status' so agents can compose and retry individual steps.
Vague Descriptions Lacking Context: Tools like 'summarize_images_in_folder' and 'create_expense_report' have descriptions under 100 chars that do not explain when to use them vs alternatives, what format they expect, or what they return. Baseline is 194 chars; these are 66 and 82 chars respectively. Recommendation: expand to 150-250 chars explaining: (1) what it does, (2) what it returns, (3) when an LLM should call it, (4) any prerequisites.
Conflicting Path Handling Instructions: Tools 'save_draft_email_local_files', 'upload_file_to_cloud', 'download_file_from_cloud', and 'onboard_new_employee' all include long docstring warnings about not prepending the allowed directory. These instructions should be enforced in the tool implementation (server-side path validation), not burden LLMs with multi-line caveats. The fact that these warnings exist suggests the implementation is fragile. Recommendation: validate paths server-side and return clear errors if paths are malformed (e.g., 'Path must not include leading /').
Naming Inconsistency: 'query_company_policies_tool' ends with '_tool', which is redundant (all registered items are tools). This breaks the verb_noun convention. Recommendation: rename to 'search_company_policies' or 'query_policies'.