Loading ToolBench
MCP server for Zoho Mail — read, search, and send email via Claude
The server defines 4 tools with basic but incomplete schema and documentation. All tools have names following verb_noun conventions (list_, search_, read_, send_) and descriptions present in the code. However, schemas lack important detail: parameter types are declared via Zod but descriptions are minimal for some parameters, output schemas are not documented, and error handling is absent. The tools form a logical chain (list/search → read, send standalone), but lack pagination support and robust error guidance. Parameter validation is basic (string/number only, no enums). Output is returned as raw JSON stringified text rather than structured objects. This is typical community-quality work: functional but missing production patterns around error handling, output structure documentation, and validation.
List recent inbox messages — returns sender, subject, date, messageId, and folderId
Read the full body of an email given its messageId and folderId (both returned by list_inbox and search_emails)
Search inbox by keyword, sender email, or subject fragment — returns messageId and folderId for use with read_email
Send an email from the configured ZOHO_SENDER address
Output schemas not documented. Tools return raw JSON text without explicit schema documentation. Agents cannot infer what fields to expect or plan downstream calls.
No error handling or recovery guidance. Tools throw raw Zoho API errors ('Zoho 401: ...') with no actionable next steps for the LLM. Missing error classification (retryable vs user-fixable vs fatal) and recovery hints.
No pagination for list_inbox and search_emails. Unbounded results (default 20, no max enforced) risk blowing context windows. No limit validation, no total_count or next_cursor returned. Large mailboxes will break the agent's reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
'send_email' description (67 chars) lacks critical information: Does it modify state (yes, sends)? What are prerequisites? Are there retry semantics? Missing idempotency guidance.
Parameter 'count' in list_inbox and search_emails has no min/max constraints. Agents could pass count=999999 causing timeout or excessive API usage. No validation in code.
Output returned as plain JSON text inside { type: 'text', text: JSON.stringify(...) } rather than structured tool output. Agents must parse text, losing signal.
'search_emails' description says 'returns messageId and folderId' but actual output includes subject, from, date, summary, inconsistent with documented interface. Agents may miss available fields.
No tool annotations (readOnlyHint, destructiveHint). 'send_email' is destructive (sends irreversible message) but unmarked. Clients cannot detect which tools have side effects. BONUS pattern from current spec (2026-07-28).