Skip to main content
Glama
shigechika

gwsadm-mcp

by shigechika

gmail_message_trace

Check whether a message (by RFC 822 Message-ID) reached specific users' mailboxes.

Instructions

Check whether a message (by RFC 822 Message-ID) reached specific users' mailboxes.

Answers "who got this email and who didn't" for a KNOWN Message-ID and a KNOWN candidate recipient list — there is no Workspace API to search across every user for one message, so the caller supplies who to check (a mailing-list roster, or simply the people who reported a problem). For each recipient this impersonates that exact user via domain-wide delegation and searches their own mailbox (including Spam and Trash) for the Message-ID.

Requires the gmail.readonly DWD scope — granted PER SERVICE ACCOUNT CLIENT ID in the Admin console (Security > API controls > Domain-wide delegation), separately from the admin.directory.* / admin.reports.* scopes the rest of this server uses, and NOT on by default. A domain missing that grant reports a per-recipient error rather than a silent "not found" — the two must never be confused, since "not found" here can also legitimately mean the message was delivered and later deleted by the user, or never delivered at all; this tool cannot tell those apart, only "a match currently exists in this mailbox" from "it doesn't".

Read-only: only messages().list and messages().get (metadata only, never the message body) are issued against each impersonated mailbox — see DomainClient.find_message_by_id.

A per-recipient result sets ambiguous: true (with match_count) when more than one message in that mailbox shares the Message-ID (e.g. a mailing-list copy plus a direct CC) — the other fields describe only the first match in that case, not a combined answer. match_count_capped is set alongside it when the mailbox has enough matches that match_count itself is a lower bound, not exact.

Args: message_id: The RFC 822 Message-ID to search for, with or without angle brackets. Must be shaped like an address (local@domain, no whitespace) — this is validated before use, since it is interpolated into a Gmail search query. recipients: Comma- and/or whitespace-separated exact recipient email addresses to check (max 50 per call — split a larger list across multiple calls rather than expecting a partial result). domain: Configured [domain.*] section to route EVERY recipient through. Default: resolved per-recipient from their own address suffix, so one call can cover a mixed staff/student list. Set this only when recipients use an alias/secondary domain with no config section of its own.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNo
message_idYes
recipientsYes
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses impersonation via domain-wide delegation, searches including Spam and Trash, the read-only use of messages().list and messages().get (metadata only), the per-recipient error vs. "not found" distinction, the inability to distinguish deleted vs. never delivered, and the ambiguous/match_count cap behavior. This is exemplary disclosure.

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

Conciseness5/5

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

Though long, the description is structured into a clear one-line purpose, a rationale paragraph, scope/permission warnings, behavioral caveats, and an Args list. Every sentence adds necessary information for a complex tool, and the front-loaded first sentence immediately answers what the tool does.

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 the sparse schema, absence of annotations, and no output schema, the description provides comprehensive context: return semantics, error handling, ambiguity flags, domain configuration, scope prerequisites, and read-only behavior. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains message_id angle-bracket flexibility and address-shape validation, recipients format and max count, and the domain parameter's default per-recipient resolution and special alias-domain use case. This adds substantial meaning beyond the bare 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?

The description opens with a specific verb + resource + scope: "Check whether a message (by RFC 822 Message-ID) reached specific users' mailboxes." It clearly defines the tool as a targeted per-recipient lookup, distinct from the other sibling tools which focus on health, audits, or drive activity.

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?

The description explicitly states when to use this tool: for a KNOWN Message-ID and a KNOWN candidate recipient list, and explains the absence of a cross-user Workspace API. It gives concrete operational guidance such as the 50-recipient limit, splitting larger lists, domain routing, and the required gmail.readonly DWD scope, making usage conditions unambiguous.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shigechika/gwsadm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server