Loading ToolBench
Customer support MCP server for managing cases, searching cases, and updating case records in Salesforce with AI-powered summaries and email integration
Server has 4 tools with basic schemas and descriptions, but significant gaps prevent production use. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization). Schemas are present but incomplete: parameters lack type definitions in several cases (e.g., 'email_content' in update_case is typed as 'object' with no nested schema). Error handling returns generic error dicts without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Parameter descriptions are minimal (e.g., 'Case subject' for subject param). Output schemas are not documented, LLMs cannot predict response structure. No pagination support despite search_cases_by_email returning lists. Naming is acceptable (verb_noun pattern), but descriptions fail to explain WHEN to use each tool or what distinguishes them.
Create a new case in Salesforce
Retrieve a case record by case number
Search for open cases by customer email
Update an existing case record by case number in Salesforce
Descriptions are too short (10-50 chars vs. 50-200 char baseline). 'Create a new case in Salesforce' and 'Retrieve a case record by case number' lack context for LLM tool selection. No explanation of WHEN to use create_case vs. update_case, or when search_cases_by_email is appropriate.
Parameter 'email_content' in update_case is typed as 'object' with no nested schema. LLMs cannot infer what fields it expects. Similarly, 'disputed_amount' lacks min/max constraints, and 'status' lacks enum values (e.g., 'New', 'In Progress', 'Resolved').
No output schemas documented. LLMs cannot predict what fields create_case, get_case, or search_cases_by_email return. Code shows dict() conversion of Salesforce responses, but response structure is opaque to the agent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Error handling returns generic {'error': 'message'} dicts without recovery guidance. E.g., 'Failed to create case: ...' tells the LLM nothing about whether to retry, ask the user, or abort. No error classification (retryable vs. fatal).
search_cases_by_email returns a list but has no pagination (limit, offset, next_cursor) or total count. Large result sets will blow context windows. Code shows no result capping.