Description
There is currently no way to answer the question "which of my filters acted on this message?" Gmail's API does not record which filters fired, so today this requires pulling every filter with manageFilter action: "list", fetching the message with getMessage, and manually evaluating each filter's criteria against the headers by hand.
This is worth solving in the MCP because the evaluation is entirely client-side and deterministic. A proposed manageFilter action: "explain" taking a messageId would:
- Fetch the message metadata (from, to, subject, size, attachments, labels).
- Fetch all filters.
- Evaluate each filter's
criteria (from, to, subject, query, negatedQuery, hasAttachment, size/sizeComparison) against that message.
- Return the filters that match, with the specific criterion that matched and the
filterAction each would apply.
Why this matters in practice: I was asked to explain why a particular message had been marked as read. Without this, a prior session guessed from correlation (message category plus label statistics) and concluded a nonexistent "Social category auto-read filter" was responsible. The actual cause was a filter matching from:messages-noreply@linkedin.com with removeLabelIds: ["UNREAD"]. The wrong answer was confidently stated because the right answer was only reachable by manual cross-referencing.
A secondary benefit: the same matcher makes it possible to detect overlapping or shadowing filters, which is the other question that comes up constantly when adding filters to an account that already has dozens.
Caveat worth noting in the implementation: Gmail's query field accepts full search syntax, so a faithful local evaluator is nontrivial for complex queries. Even a partial implementation that handles the common cases (from:, to:, subject:, quoted phrases, OR, -/negation) and clearly reports "this filter's query is too complex to evaluate locally" would be a large improvement over nothing.
Environment: server 3.4.6, node v22.22.3, win32 10.0.26200, stdio transport.
Diagnostic Info
- Server version: 3.4.6
- Node version: v22.22.3
- OS: win32 10.0.26200 (x64)
- Auth status: valid
- Scopes: documents, drive, spreadsheets, script.external_request, gmail.modify, gmail.compose, gmail.send, gmail.settings.basic, gmail.settings.sharing, calendar, forms.body, forms.body.readonly, forms.responses.readonly, presentations, tasks, service.management
Description
There is currently no way to answer the question "which of my filters acted on this message?" Gmail's API does not record which filters fired, so today this requires pulling every filter with
manageFilter action: "list", fetching the message withgetMessage, and manually evaluating each filter's criteria against the headers by hand.This is worth solving in the MCP because the evaluation is entirely client-side and deterministic. A proposed
manageFilter action: "explain"taking amessageIdwould:criteria(from,to,subject,query,negatedQuery,hasAttachment,size/sizeComparison) against that message.filterActioneach would apply.Why this matters in practice: I was asked to explain why a particular message had been marked as read. Without this, a prior session guessed from correlation (message category plus label statistics) and concluded a nonexistent "Social category auto-read filter" was responsible. The actual cause was a filter matching
from:messages-noreply@linkedin.comwithremoveLabelIds: ["UNREAD"]. The wrong answer was confidently stated because the right answer was only reachable by manual cross-referencing.A secondary benefit: the same matcher makes it possible to detect overlapping or shadowing filters, which is the other question that comes up constantly when adding filters to an account that already has dozens.
Caveat worth noting in the implementation: Gmail's
queryfield accepts full search syntax, so a faithful local evaluator is nontrivial for complex queries. Even a partial implementation that handles the common cases (from:,to:,subject:, quoted phrases,OR,-/negation) and clearly reports "this filter's query is too complex to evaluate locally" would be a large improvement over nothing.Environment: server 3.4.6, node v22.22.3, win32 10.0.26200, stdio transport.
Diagnostic Info