Skip to main content
Glama

preview_filter

Read-only

Check a Gmail filter before creating it to see today's match count, duplicate or overlapping filters, and missing label names; nothing is created or changed.

Instructions

Check a filter BEFORE create_filter makes it: how much mail its criteria match today, which existing filters have exactly the same criteria, which share a from/to/subject/query value with it, and which label names in addLabels do not exist yet. Creates nothing and changes nothing. Takes the same criteria as create_filter and checks them the same way, so a preview cannot accept what the create would refuse. currentMatches counts what Gmail's search returns for the derived query — the same unverified index create_filter's applyToExisting sweep would act on; it is a size, not a promise that the filter engine agrees on every message. A rule with no positive criterion (only negatedQuery or hasAttachment:false) is not counted at all: it would match nearly the whole mailbox. overlapping is literal: two filters overlap here when they carry the same value in the same field. Whether two different searches intersect is the search engine's question, and is not guessed at. USE WHEN: before create_filter, to show the user what the rule would catch and avoid a duplicate. SIDE EFFECTS: none. Requires gmail.settings.basic (it lists the existing filters).

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

Input Schema

NameRequiredDescriptionDefault
toNo
fromNo
sizeNo
queryNo
subjectNo
addLabelsNo
maxMessagesNo
excludeChatsNo
negatedQueryNo
removeLabelsNo
hasAttachmentNo
sizeComparisonNo

Output Schema

NameRequiredDescriptionDefault
queryYes
cappedYes
overlappingYes
sameCriteriaYes
currentMatchesYes
labelsToCreateYes
trashesMatchesYes
currentThreadCountYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.0

TDQS

A4.4/5.0
Behavior5/5

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

The annotations already mark it as read-only, and the description adds substantial behavior beyond that: no side effects, the required gmail.settings.basic permission, the caveat that currentMatches is a search-index size and not a promise, the exclusion of rules with no positive criterion, and the literal definition of overlap. None of this contradicts the annotations.

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?

The first sentence is front-loaded with purpose and outputs, and the remaining sentences add useful caveats about matching behavior, query counting, overlap, permissions, and side effects. The length is justified by the tool's complexity, though 'Creates nothing and changes nothing' is slightly redundant with 'SIDE EFFECTS: none.'

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 does not need to explain return values in detail. It covers purpose, side effects, permissions, matching caveats, overlap semantics, and the no-positive-criterion edge case, which is complete enough for correct invocation.

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

Parameters3/5

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

Schema description coverage is 0% across 12 optional parameters, so the description must carry parameter meaning. It explains several core criteria fields and semantics for from/to/subject/query, addLabels, negatedQuery, and hasAttachment, but it leaves size, sizeComparison, maxMessages, excludeChats, and removeLabels undocumented, creating clear gaps.

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 specific verb and resource: it checks a prospective Gmail filter before create_filter, and enumerates exactly what the preview returns, including match count, duplicate filters, overlapping filters, and missing labels. It names the sibling create_filter and clearly distinguishes the preview role from the actual creation role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit USE WHEN condition: before create_filter, to show the user what the rule would catch and avoid a duplicate. It also states that it creates and changes nothing, but it does not spell out explicit when-not or full alternative-tool guidance, so it falls short of a complete 5.

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