Skip to main content
Glama
rust-works

omni-dev

by rust-works
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

gmail_draft_list

List Gmail drafts with draft IDs, recipients, subjects, dates, and snippets; filter by Gmail search syntax to find a draft before opening or editing it.

Instructions

List Gmail drafts with each one's draft id, which gmail_search with in:drafts cannot return and which gmail_draft_show requires. Each row has draft_id, message_id, thread_id, to/cc/bcc, subject, date and snippet. The message_id changes every time the draft is saved, so address a draft by draft_id. query filters with Gmail search syntax (e.g. to:alice subject:report); omit it to list every draft. limit defaults to 50; pass 0 for every draft up to a hard cap (10000). Each row costs one extra messages.get request. Read-only (gmail.readonly is enough). Mirrors omni-dev gmail draft list. Output is YAML.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum drafts to return. Defaults to 50 when omitted; `0` explicitly means every draft, up to the hard cap (10000). Each draft costs one extra `messages.get` request (20 quota units).
queryNoOnly list drafts matching this Gmail search query (same syntax as the Gmail search box), e.g. `to:alice subject:report`. Omit to list every draft.
accountNoSelects a named Gmail account instead of the ambient `--account`/`OMNI_DEV_GMAIL_ACCOUNT` resolution — e.g. `work`. Omit to use the resolved default account (or the legacy single-account credentials, if no named accounts are configured). Call `gmail_account_list` to discover configured names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.45.0
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum drafts to return. Defaults to 50 when omitted; `0` explicitly\nmeans every draft, up to the hard cap (10000). Each draft costs one\nextra `messages.get` request (5 quota units)."New value: +"Maximum drafts to return. Defaults to 50 when omitted; `0` explicitly\nmeans every draft, up to the hard cap (10000). Each draft costs one\nextra `messages.get` request (20 quota units)."
  2. Addedv0.44.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares read-only scope ('gmail.readonly is enough'), the per-row cost (one extra messages.get request / 20 quota units), the hard cap of 10000, and the volatility of message_id versus the stable draft_id.

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?

Dense but every sentence earns its place and the differentiating fact (draft_id availability) is front-loaded. The parenthetical cost/quota asides and the trailing 'Mirrors omni-dev gmail draft list' / 'Output is YAML' notes make it slightly crowded.

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?

No output schema exists, and the description compensates by enumerating the returned row fields and the YAML output format, plus the account resolution behavior is covered in the schema. Nothing needed to call or interpret the result is missing.

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 coverage is already 100%, so baseline is 3; the description adds a concrete query example ('to:alice subject:report') and restates the limit contract (default 50, 0 means all up to 10000) in agent-facing prose. The account parameter is left to the schema, which documents it well.

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?

States a specific verb+resource ('List Gmail drafts') and explicitly differentiates from two siblings: gmail_search with in:drafts cannot return the draft id, and gmail_draft_show requires that id. The agent can pick this tool without opening either 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?

Explicitly routes between alternatives: use this because gmail_search cannot return draft_id and gmail_draft_show requires it. Also states that omitting query lists every draft and how limit behaves, so the when/when-not conditions are covered.

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

Deploy Server

Other Tools