Loading ToolBench
MCP server for orchestrating customer support workflows including ticket processing, issue classification, Jira integration, Slack notifications, and email management
The server has 7 tools with basic schemas and descriptions, but significant gaps in definition quality. Tool names follow verb-noun convention (good), but descriptions are present for all tools, however, they lack depth and actionable guidance for LLM selection. Parameter descriptions exist but are minimal (5-15 chars typical). No output schemas are documented for any tool. No error recovery guidance. The tools are organized around a customer support workflow, but several critical quality patterns from the 54 Agentic Tool Patterns are missing: constrained inputs (no enums where needed), error classification, recovery guidance, and idempotency markers. Most tools are WRITE or IRREVERSIBLE but lack confirmation/dry-run capabilities. Average tool score: ~42/100.
Classify a support ticket's issue type using an LLM
Create a Jira ticket for a support issue
Generate an email draft response for a customer support ticket
Send a Slack notification about a new support ticket
Process a customer query and create a new support ticket in the database
Run the complete customer support pipeline on a batch of customer queries from a CSV file
No output schemas documented for any tool. LLMs cannot predict response structure or plan downstream tool calls. E.g., process_query returns {ticket_id, customer_email, customer_name, status} but this is not formally documented in the tool definition.
No error recovery guidance. Tools return {error: str(e)} on failure, but do not tell the LLM what to do next (retry? ask user? call a different tool?). E.g., 'Ticket not found' does not suggest calling process_query to create one.
Tool descriptions lack selection guidance. 'Classify a support ticket's issue type using an LLM' does not explain when to call this vs draft_email or create_jira. LLM must infer intent from name alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Send an email response to a customer for their support ticket
No enum constraints on string parameters. 'product_purchased' in process_query is a free-form string, LLM may invent invalid product names. Status, issue_type, and other categorical fields should be enums.
run_batch_pipeline is IRREVERSIBLE but has no confirmation step, dry-run option, or preview. An LLM could accidentally process 1000 queries without human approval. No idempotency guarantee documented.
Tool name 'send_email_tool' is awkward and non-standard. Should be 'send_email' to match pattern verb_noun naming. '_tool' suffix is redundant in MCP context.
Parameter descriptions are minimal (5-10 chars). E.g., ticket_id is described only as 'The ticket ID to classify', does not state format, valid range, or what happens if the ID doesn't exist.
No dependency hints in descriptions. E.g., draft_email and send_email_tool depend on prior classify_issue and create_jira execution, but this is not documented. LLM may call tools in wrong order.
No idempotency markers or guarantees documented. Retry behavior is unclear for tools that modify state (create_jira, notify_slack, send_email_tool). Will a retry create duplicates?