Loading ToolBench
A demonstration MCP server with multiple service integrations including Google Calendar and Salesforce
The server implements 7 tools across Salesforce and Google Calendar domains with reasonable naming and mostly complete schemas. Tool names follow verb_noun convention (get_, create_, update_, delete_, list_), and all tools have descriptions. However, parameter descriptions are inconsistent in depth, and several critical patterns are missing: no output schemas are documented in the code, no error handling guidance for LLM recovery, and no security considerations visible for destructive operations. The Salesforce tools have detailed parameter descriptions with field guidance (e.g., state picklist notes), which is strong. Google Calendar tools have adequate descriptions but less granular guidance. The server shows mid-tier quality, functional but lacks production-grade polish around error recovery, output documentation, and LLM-optimized descriptions.
Create a new event/meeting/sync/meetup in the specified calendar.
List all calendars accessible by the user.
Create a new account in Salesforce.
Delete an account.
Get accounts with flexible filtering options including name search, industry, type, and date ranges.
Get contacts with flexible filtering options including name, email, title search, and date ranges.
No output/response schemas documented. The code returns dictionaries (e.g., list_calendars returns {'next_page_token', 'num_calendars', 'calendars'}) but these schemas are not declared in tool metadata. LLMs cannot plan downstream tool calls or extract fields reliably without knowing response structure.
No error recovery guidance. Destructive tools (salesforce_delete_account, create_event with send_updates) have no documented error handling or recovery paths. Errors raise generic RuntimeError or HttpError without actionable LLM guidance (e.g., 'User not found. Try search_users() first.').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | 2025-03-26+ | v1 |
Update an existing account.
Tool annotations present but incomplete. toolAnnotations=true is declared, and code shows risk classification (READ_ONLY, WRITE, DESTRUCTIVE), but these are not mapped to structured MCP destructiveHint/readOnlyHint annotations in the tool metadata. Risk labels exist in comments but not in the protocol layer.
Parameter descriptions lack actionable constraints. 'email_contains' in salesforce_get_contacts is described as 'Filter contacts by email containing this text (case-insensitive)' but does not specify max length, pattern (e.g., email format), or whether partial matches are allowed (e.g., 'john' matches 'john@example.com' or just substrings in the email field?).
create_event parameter 'recurrence' is an array of strings but no format guidance. RFC 5545 RRULE format? Natural language? Example: ['FREQ=WEEKLY;BYDAY=MO,WE,FR']? Without format clarity, LLMs will hallucinate invalid recurrence rules.
No pagination documentation for Salesforce list tools. salesforce_get_accounts and salesforce_get_contacts accept 'limit' (default 50) but no 'offset' or 'next_cursor' for pagination. If results exceed the limit, how does the agent fetch the next page? Response does not return total count or next_cursor.
Parameter 'account_data' in create_account and update_account is a free-form object with inline documentation of 50+ possible fields. No schema constraint, enum for Type/Ownership, or structured definition. LLMs will guess field names and types, risking API rejections.
Credentials handled via environment variables and context injection (extract_access_token, auth_token_context), which is correct, but no documented scope declarations or permission checks visible. Tools should declare required scopes (e.g., 'read:salesforce_accounts', 'write:salesforce_accounts', 'calendar.events.create').