Skip to main content
Glama

follow_ups

Read-only

Identifies Gmail threads you're waiting on or that await your reply, so you can decide whom to nudge and whom to answer.

Instructions

Who is waiting on whom. waitingOnThem: threads whose LAST message is yours (SENT) and has had no answer for at least nudgeAfterDays — candidates for a nudge; a note to yourself (every To and Cc address is the account's own primary address, in any spelling Gmail delivers to it: +tags, dots, googlemail.com) is left out; one other recipient keeps it. waitingOnMe: threads still in the inbox whose last message came from someone else — a person, not a newsletter or an automated notice by its own headers — oldest first. Decided on each thread's last message and its LIVE labels: the search index only proposes candidates (in:sent / in:inbox within the last days), so a thread the index still files under the inbox after it was archived is dropped, as in search. Drafts, trash and spam messages do not count as a thread's last word. Scans at most max threads per side; hasMore says when more candidates existed. A thread with no recorded date is left out rather than given an invented age. USE WHEN: 'what am I waiting on?', 'who have I not answered?', 'what should I follow up on?' DO NOT USE: as an inbox overview (use triage_digest) or to read a thread (use get_thread). SIDE EFFECTS: none.

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": "follow_ups"
  }
}

Input Schema

NameRequiredDescriptionDefault
maxNo
daysNo
nudgeAfterDaysNo

Output Schema

NameRequiredDescriptionDefault
hasMoreYes
scannedYes
waitingOnMeYes
waitingOnThemYes

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and the description confirms with 'SIDE EFFECTS: none.' Beyond that it discloses non-obvious behavior: candidates come from the search index but decisions use LIVE labels, so stale index entries are dropped; drafts/trash/spam don't count as a last word; self-notes (To/Cc all being the account's own address, including +tags/dots/googlemail.com variants) are excluded; threads with no recorded date are omitted rather than guessed.

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?

Broader context is front-loaded and the USE WHEN / DO NOT USE / SIDE EFFECTS blocks are easy to scan, with no filler sentences. Some parenthetical clauses (the self-address spelling explanation) are dense and slow the read, keeping it short of a 5.

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 three optional filter parameters and an existing output schema, the description covers everything an agent needs: what each side means, the exclusion rules, the scanning limit and truncation signal, and the precise boundaries versus sibling tools. Return-value shape is correctly left to the output schema.

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 description coverage is 0%, so the description carries the burden, and it names and contextualizes all three parameters in prose: `max` ('Scans at most `max` threads per side'), `days` ('within the last `days`'), and `nudgeAfterDays` (the no-answer threshold for a nudge candidate). It even interprets the `hasMore` output flag. It does not restate ranges or defaults, which remain in 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?

Opens with a specific framing ('Who is waiting on whom') and immediately defines the two distinct result sides, waitingOnThem and waitingOnMe, with a precise condition for each. An agent can distinguish this from search, triage_digest, or get_thread without inspecting 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?

Explicit USE WHEN section gives three concrete user phrasings that map to this tool, and DO NOT USE names both alternatives (triage_digest for inbox overview, get_thread for reading a thread). This is the strongest form of routing guidance.

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