Descriptions are too brief and lack guidance on tool selection and prerequisites. Example: 'Get a Zendesk ticket by ID' (29 chars) does not explain when to use this vs related tools, what the output contains, or common failure modes.

Output schemas are not documented. Tools return JSON-stringified results but the structure of returned objects (fields, types, nested properties) is not specified. LLMs cannot plan downstream tool calls or extract relevant fields.

Error handling returns generic error messages ('Error: <message>') without recovery guidance or categorization (retryable vs user-fixable vs fatal). Example: 'Invalid ticket ID' does not guide the LLM on what to do next.

Many exported functions (searchTickets, getTicketDetails, getLinkedIncidents, listTicketFields, etc.) are exported but not visible as registered MCP tools in the zenDeskTools function. Only 5 tools are explicitly registered; it is unclear if the other functions are available via the protocol or only for library use.

No pagination parameters (limit, offset, page_size) visible in tool definitions, yet tools like get_ticket and add_note suggest they may operate on collections. Without pagination, large result sets could exhaust context.

Parameter descriptions for optional fields are minimal. Example: 'tags' in zendesk_create_ticket has description 'Tags to add to the ticket' but does not explain format (comma-separated? array? string with spaces?), maximum count, or character limits.

zendesk_update_ticket has many optional parameters (subject, status, priority, type, assignee_id, tags) but no documentation of which combinations are valid or which fields depend on each other. If assignee_id must be a valid agent, this constraint is not documented.

No confirmation or dry-run pattern for destructive operations. zendesk_update_ticket and zendesk_create_ticket modify state but provide no way to preview changes or confirm before execution.

Tool responses return raw JSON.stringify() output with no filtering. Zendesk API responses likely include verbose metadata, audit fields, timestamps, and internal state that dilute the signal and waste tokens.

Credentials are injected via environment variables (ZENDESK_EMAIL, ZENDESK_TOKEN, ZENDESK_SUBDOMAIN) which is correct, but no permission gates or scope declarations visible in tool definitions. Each tool should declare required permissions (e.g., 'read:tickets', 'write:tickets').