// Reference for Gmail's search query syntax — operators like is:sent, newer_than:, from:, has:attachment, label:, and how they compose. Read this when constructing a Gmail search query string for the google_workspace.gmail_search_messages Code Mode call, especially when filtering by sent vs received, recency, sender, or labels.
| name | gmail-query-syntax |
| description | Reference for Gmail's search query syntax — operators like is:sent, newer_than:, from:, has:attachment, label:, and how they compose. Read this when constructing a Gmail search query string for the google_workspace.gmail_search_messages Code Mode call, especially when filtering by sent vs received, recency, sender, or labels. |
These tools live on the google-workspace MCP server, sanitized to
google_workspace in Code Mode. In Docker Agent Mode the only MCP tool
exposed to Claude Code is execute_code; write TypeScript inside it and
call the Gmail tools as dotted callables, e.g.
google_workspace.gmail_search_messages({ query: "is:sent", pageSize: 3 }).
gmail_search_messages accepts a query parameter that uses Gmail's
standard search operator language — the same syntax the Gmail web UI
search box accepts. Operators combine with implicit AND; use OR
(uppercase) for disjunction and parentheses for grouping.
Note: gmail_search_messages returns message IDs, thread IDs, and URLs
only — not full message contents. To read sender, recipient, subject,
date, and body for a matched message, follow up with
google_workspace.gmail_get_message (single id) or
google_workspace.gmail_get_messages_batch (array of ids).
| Operator | Meaning | Example |
|---|---|---|
is:sent | Messages the user sent (not received) | is:sent |
is:unread | Unread messages | is:unread |
is:starred | Starred messages | is:starred |
from:<addr> | Sender address (substring or full) | from:alice@example.com |
to:<addr> | Recipient address | to:team@example.com |
subject:<text> | Subject contains text | subject:"weekly update" |
newer_than:<n>d | Messages newer than N days (also h, m, y) | newer_than:7d |
older_than:<n>d | Messages older than N (same units) | older_than:30d |
after:<date> | After a date (YYYY/MM/DD) | after:2025/01/01 |
before:<date> | Before a date | before:2025/02/01 |
has:attachment | Messages with at least one attachment | has:attachment |
label:<name> | Messages with the given Gmail label | label:invoices |
in:inbox | In the inbox (excludes archived) | in:inbox |
in:anywhere | Includes Spam and Trash (rarely needed) | in:anywhere |
is:sent newer_than:7d -> sent in the last 7 days.(from:alice OR from:bob) is:unread.-: is:sent -label:archived.subject:"quarterly review".newer_than:Nd over after: when "the last N days" is what
you actually want — after: is calendar-anchored and behaves
unexpectedly across timezone boundaries.is:sent with the
pageSize argument on the dotted call —
google_workspace.gmail_search_messages({ query: "is:sent", pageSize: N }) —
do not try to express the limit inside the query string. (Pagination
tokens come back as pageToken and are passed back in via the same
argument name on the next call if you need to walk past the first page.)Reference vocabulary for designing instrumented harnesses that drive vulnerability discovery — design classes (trigger-driven vs coverage-driven), tiered scope (T1 isolated function / T2 multi-component / T3 full build), systematic input exploration, the two-coverage distinction (fuzzer-feedback vs audit), existing-fuzzer selection (libFuzzer / AFL++ / Jazzer / atheris / `go test -fuzz`), seed-corpus discipline, diagnostic checkpoints, common pitfalls, and design-document scope. Read when designing or reviewing a harness specification. Stays neutral on language and stack — pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class taxonomy.
Reference vocabulary for interpreting vulnerability findings — detector-vs-impact distinction, severity anchoring on demonstrated evidence, the eleven-item interpretation rubric, delegation transparency, primitive-extent scaling, the disqualifier taxonomy (D-0..D-4), CVSS Achievable / Environmental framing, hedging-phrase elimination, and falsification asymmetry. Read when interpreting a finding to decide whether the demonstrated evidence supports the severity it would warrant. Surface-neutral; pulls in the relevant surface skill (e.g. `memory-safety-c-cpp`) for bug-class-specific exploitability factors.
Reference vocabulary for memory-safety vulnerabilities in native C/C++ code — bug-class taxonomy, common arithmetic patterns that lead to corruption, dispatch-family discipline, type-confusion idioms, use-after-free patterns, and exploitability factors. Read when analyzing, hypothesizing, designing harnesses for, or triaging findings against C/C++ code with sanitizer support (ASAN/UBSAN/TSAN/MSan). Not applicable to managed runtimes (JVM, .NET) or scripting languages — those have their own skills.
Markdown formatting conventions for email summary documents — heading depth, list style, line length, emoji policy, and a mandatory provenance footer. Read this when producing a markdown report that summarizes one or more email messages so the output matches the project's house style.
Canonical shape of the .workflow/emails/emails.json file passed between the fetch and summarize states — required fields (sender, recipient, subject, date, body), types, and field semantics. Read this whenever you write or read emails.json so producer and consumer agree on the shape.
Tone and length conventions for email summaries — voice, verb tense, what to include vs omit, and target sentence count. Read this when writing the prose Summary line for each email so the voice is consistent across the report.