Skip to main content
Glama

what_changed

Read-only

Fetches mailbox events—arrived or removed messages and label changes—since a supplied history ID, enabling incremental checks without stored state.

Instructions

What happened in the mailbox since a point you already hold: messages that arrived or were removed, and labels applied or taken off — from Gmail's own event log, in one call. Pass the historyId a previous what_changed or get_profile returned; the reply carries the next one to keep. mailwarden stores NOTHING between calls, so the id lives with you. Reports EVENTS, not current state: a message that was marked unread and then read appears under both, and both are true. For how the mailbox looks NOW, use search or get_thread. Gmail keeps roughly a week of history. An id older than that is an ERROR, never an empty result — it means the question can no longer be answered incrementally, so take a fresh historyId from get_profile and re-establish state with search. labelId narrows the feed to events touching one label (e.g. 'INBOX', or a snooze label). Counts are complete even when the id lists are cut at 200 (truncated). USE WHEN: a recurring check — 'what came in since I last looked', watching a label, or confirming a bulk action landed. Far cheaper than re-running a search over the whole slice. DO NOT USE: for a first look at a mailbox (there is no id yet — start with triage_digest or search), or to read content: this returns ids only, no sender, subject or body. SIDE EFFECTS: none.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sinceHistoryId": "<sinceHistoryId>"
    },
    "name": "what_changed"
  }
}

Input Schema

NameRequiredDescriptionDefault
maxNo
labelIdNo
sinceHistoryIdYes

Output Schema

NameRequiredDescriptionDefault
addedYes
deletedYes
recordsYes
historyIdYes
truncatedYes
labelsAddedYes
labelsRemovedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.25.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv0.18.0

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavior beyond the readOnly annotation: it explains the history-id lifecycle, states that mailwarden stores nothing between calls, clarifies event-vs-current-state semantics, describes Gmail's roughly one-week retention, and specifies that an old id is an error rather than an empty result. It also notes that returned ids omit sender, subject, and body, and that counts remain complete even when id lists are truncated.

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?

The description is long but well structured and front-loaded: it states the purpose first, then explains the id lifecycle, event semantics, alternatives, edge cases, and use guidance. Every section adds operational value for a history-based incremental-sync tool.

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 that an output schema exists, the description provides all the key context an agent needs: id provenance and persistence expectations, retention limits, error behavior for stale ids, truncation behavior, and explicit guidance for first-time vs recurring use. It also confirms there are no side effects.

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?

With 0% schema description coverage, the description compensates well for the key parameters: it explains where `sinceHistoryId` comes from and what `labelId` narrows. However, it does not explain the `max` parameter or clarify its relationship to the 'cut at 200 (`truncated`)' behavior, and it refers to `historyId` rather than the schema's `sinceHistoryId`.

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 states a precise verb and resource: it reports what happened in the mailbox since a held history id, covering arrivals, removals, and label changes from Gmail's event log. It explicitly distinguishes this from sibling tools by saying it reports events, not current state, and points to search/get_thread for current mailbox state.

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?

It gives explicit USE WHEN cases: recurring checks, watching a label, and confirming a bulk action landed. It also gives explicit DO NOT USE cases: first look at a mailbox with no id, or reading content, and names triage_digest/search/get_profile as the correct alternatives.

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