Loading ToolBench
MCP server for Gmail integration with unread email listing, filtering, delete and archive capabilities
This Gmail MCP server has complete JSON schemas for all 9 tools and clear verb-starting names (list_*, search_*, delete_*, archive_*, create_*, modify_*). However, descriptions are inconsistent in depth and quality. Several tools have descriptions under 100 characters that lack context about when to use them or what prerequisites exist. Parameter descriptions are present but often terse. No input validation guidance, error recovery hints, or output schema documentation visible in the tool definitions themselves. The server follows basic naming and schema structure conventions but falls short of LLM-optimized descriptions and comprehensive parameter guidance expected in A-grade servers.
Archive emails (remove from inbox). Accepts positions[] from email list and/or message_ids[].
Create a new Gmail label
Move emails to trash and mark as read. Accepts positions[] from email list and/or message_ids[].
List emails in Gmail (defaults to inbox, including both read and unread)
List all Gmail labels
List recent actions performed by the server (archived, deleted, labeled emails)
list_labels and list_recent_actions have minimalist descriptions ('List all Gmail labels', 'List recent actions...') that lack context about when to call them, what data they reveal, or what structure they return. LLMs need discovery guidance.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., does search_emails return message_id, thread_id, both?) without seeing the response structure. delete_emails and archive_emails should document what they return on success.
delete_emails and archive_emails lack actionable error guidance. Descriptions do not explain what happens if positions are invalid or message_ids are not found, or suggest recovery (retry? check list_recent_actions for confirmation?). Error handling is not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
List unread emails in Gmail inbox with optional subject filtering
Batch add/remove labels on emails. Accepts positions[] and/or message_ids[], plus add_labels[] and/or remove_labels[] (label names). When adding a Triage/* label, all other Triage/* labels on the email are automatically removed.
Search emails using standard Gmail search query syntax (e.g. 'from:user@example.com', 'has:attachment', 'subject:report', 'after:2024/01/01', 'is:starred')
delete_emails and archive_emails accept both 'positions' (from list_* results) and 'message_ids', but descriptions do not clarify the relationship or warn if both are provided (which takes precedence?). Parameter interdependencies are undocumented.
create_label requires 'background_color' and 'text_color' only together ('Must be used with...' in descriptions), but JSON schema does not reflect this with conditional constraints. LLMs may pass one without the other, causing silent API failures.
search_emails description mentions 'standard Gmail search query syntax' but does not provide examples or document what happens with invalid queries. LLMs may construct malformed Gmail search strings without guidance.
No tool documentation explains pagination. If max_results defaults to 50, does that mean 50 per page? What happens if you want results 51-100? No cursor, offset, or next_token mentioned. LLMs cannot handle large result sets without pagination guidance.
modify_labels description mentions special Triage/* label behavior ('all other Triage/* labels are automatically removed'), but this constraint is not enforced in the schema or validated with error messages. If an LLM tries to add two Triage/* labels simultaneously, it will silently fail.