Gmail MCP server for reading Gmail messages via Model Context Protocol.
Gmail MCP has clear, verb-prefixed tool names (list_emails, get_email, search_emails, list_labels) and reasonable descriptions (avg 65 chars). All tools have input schemas with type constraints (minLength, min/max for numbers). However, parameter descriptions are minimal (avg 45 chars), output schemas are undocumented, and error handling is absent. No guidance on what fields are returned or how to chain tools. Lacks pagination documentation despite maxResults cap at 50. No error recovery patterns.
Read one Gmail message by messageId.
List Gmail inbox messages. Supports maxResults and Gmail query filters.
List all Gmail labels and folders.
Search Gmail messages with Gmail search syntax.
Output schemas completely undocumented. No specification of what fields list_emails, get_email, search_emails, or list_labels return. LLMs cannot plan downstream tool calls or extract required data (e.g., messageId for get_email chaining).
Parameter descriptions are minimal (avg 45 chars, well below 72-char baseline). 'Optional Gmail search query, applied within INBOX' lacks detail on query syntax, supported operators, or examples of valid queries.
No error handling or recovery guidance. If a messageId is invalid, the tool returns a raw error with no actionable next step. No guidance on retryability, user-fixable errors, or alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Pagination not documented. maxResults capped at 50, but no mention of offset/cursor, total count, or how to fetch next page. LLMs cannot reliably iterate through large result sets.
Tool descriptions lack WHEN/WHY guidance. 'List Gmail inbox messages' does not explain when to use list_emails vs search_emails, or what each returns differently. LLMs may pick the wrong tool.