mcp-google-workspace

Overview Schema Source Related Servers Discussions Admin

Gmail Get Mail Digest

gmail_get_mail_digest

Read-onlyIdempotent

List recent received and sent mail as one snippet feed, excluding drafts, Spam and Trash, to catch up on the last few days quickly without category or importance filtering.

Instructions

List the mail received and sent in a recent time window (default the last 3 days) as one feed with snippets, with no category or importance filtering; drafts, Spam and Trash are left out. Use it to catch up on recent mail; use gmail_search_emails to find mail by sender, subject or any Gmail query, and gmail_check_mail_updates to poll for new mail since a saved checkpoint. Returns messages (id, thread_id, from, subject, date, snippet, unread, has_attachments, direction 'received' or 'sent'), count, window and account_timezone; there is no next page. Read bodies with gmail_read_emails.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gmail_get_mail_digest"
  }
}

Input Schema

Name	Required	Description	Default
`window`	No	Lookback window as '<int><unit>' where unit is d (days), h (hours), or w (weeks), e.g. '24h' or '2w'; default is '3d'. Mail received or sent since now minus the window is listed.	3d
`max_items`	No	Maximum messages to return, 1 to 100 (default 25). There is no next page: when the window holds more, shorten it or page through gmail_search_emails instead.
`unread_only`	No	When true, only unread messages are listed (adds is:unread); by default read and unread both are.

Output Schema

Name	Required	Description
`count`	No	Number of items in this response.
`window`	No
`has_more`	No	Whether another page is available.
`messages`	No
`fetched_at`	No	RFC3339 time when this response was fetched.
`next_page_token`	No	Opaque token for the next page, or null.
`account_timezone`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.1.0Nov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description still adds real behavioral facts: Spam/Trash/drafts excluded, no category or importance filtering applied, and critically 'there is no next page' — a truncation behavior an agent would otherwise misjudge. It stops short of mentioning auth requirements, rate limits, or what happens when the window exceeds max_items beyond the schema's own note, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then alternatives, then return shape — a sensible ordering with no filler sentences. The inline enumeration of every returned field (id, thread_id, from, subject, date, snippet, unread, has_attachments, direction) is the one wasteful part, since an output schema already exists and duplicates it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a zero-required-parameter read tool with full schema coverage and an output schema, the description covers everything an agent needs: what it returns at a high level, how truncation behaves, what is excluded, and which sibling to use instead. Nothing material is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning above the schema: it restates the default 3-day window as behavior rather than a field default, and pairs the 'no next page' constraint with the implied consequence that a large window is silently truncated. It does not explain unread_only filtering in prose, leaving that entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the mail received and sent') plus scope ('recent time window, default last 3 days'), and immediately bounds it with exclusions ('no category or importance filtering; drafts, Spam and Trash are left out'). The addition of 'as one feed with snippets' makes the output shape distinguishable from a search tool without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives the primary use case ('catch up on recent mail') and names two discriminating alternatives with their conditions: gmail_search_emails for sender/subject/Gmail queries, and gmail_check_mail_updates for polling since a checkpoint. The agent can route correctly on the first read.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server