Loading ToolBench
Zendesk CLI and MCP Server for Claude Code - Search tickets, manage support, and analyze metrics
Two tools with complete input schemas and descriptions, but descriptions are minimal (10-20 chars baseline). Both tools are READ_ONLY and well-named with action verbs (get_, search_). Schemas include proper types, constraints (minLength, minimum, maximum, default), and nullable fields. However, output schemas are not documented, LLMs cannot predict response structure. No error handling guidance, no recovery hints, and no tool annotations (readOnlyHint missing despite READ_ONLY risk classification).
Get a Zendesk ticket by ID.
Search for Zendesk tickets based on a query with pagination support.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination format). Zendesk API returns verbose metadata, no evidence of stripping irrelevant fields or capping result limits.
Tool descriptions are too brief (10-20 chars). 'Get a Zendesk ticket by ID' and 'Search for Zendesk tickets based on a query with pagination support' lack context on WHEN to use each tool, what data is returned, or dependencies. Baseline for A+ tools is 50-200 chars.
No error handling guidance. If a ticket is not found or search returns zero results, LLMs have no recovery path. Missing actionable error messages like 'Ticket not found. Try search_zendesk() with keywords from the ticket subject.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
No tool annotations. Both tools are READ_ONLY but lack readOnlyHint annotation. This prevents clients from optimizing caching, retry logic, or permission checks. Annotation support is current MCP spec (2026-07-28).
Parameter 'output_path' (nullable string) is undocumented in descriptions. LLMs cannot infer its purpose (custom file output? API response override?). All parameters require descriptions per pattern:tool-description.