Skip to main content
Glama

gmail

The user's Gmail mailbox — READ it, or prepare a DRAFT. Nothing here sends, archives or deletes: that is gmail_act, the tool your client asks you to confirm.

op:

  • "search" (default): search with Gmail query syntax. query e.g. from:foo@bar.com is:unread newer_than:7d. Returns {messages: [{id, threadId, from, subject, date, snippet, labelIds}], count}.

  • "get": a full message (headers, body, attachment metadata) by message_id.

  • "attachment": the CONTENT of an attachment of message_id, by filename (from op="get"; index breaks a tie between same-named ones). Small text (JSON/CSV/Markdown/ plain, ≤256 KB) comes back inline as {encoding: "text", content}; a PDF as its extracted text plus raw_url, a short-lived signed URL to the original (a scanned or protected PDF has no text: text_unavailable says why); an .xlsx as CSV per sheet (sheet, max_rows — default 200, max 5000; if truncated, ask one sheet or raise max_rows; raw_url always gives the original file). An image (png/jpeg/gif/webp, ≤3 MB) and a scanned PDF whose pages are JPEG (≤5 pages, ≤3 MB) come back as IMAGE CONTENT you can look at — nothing stored. Anything else, or over those caps, as a short-lived signed URL {encoding: "url", url, expires_in} (image_unavailable says why an image or scan was not served as image).

  • "drafts": the drafts. Returns {drafts: [{id, message_id, to, subject, date, snippet}], count} — a draft id is what gmail_act(op="send", draft_id=…) sends.

  • "draft": WRITE A DRAFT — a new message (to, subject, body) or a threaded reply (reply_to). It does NOT leave the mailbox. Returns kind: "draft", its id and web_link (the draft opened in Gmail web, to note where it waits): send it with gmail_act(op="send", draft_id=<id>) once the person agrees. ⚠️ A fresh draft can be MISSING from an already-open Gmail tab for a while (the API has it, the client view lags): tell the person to reload or search in:drafts.

  • "accounts": the Gmail accounts this call can use — the user's own, then the mailboxes an admin shared with their team or organization. Returns {accounts: [{email, is_default, shared}]}; pass an email as _account to act on that mailbox. An unknown email is refused, never replaced.

The sending account's Gmail signature is appended by default, after -- (none added when the signature already opens with its own), like the Gmail web client does (the API never adds it on its own) — so do NOT write a sign-off block of your own in body. signature in the answer says what happened: "appended", "none_configured" (the account has no signature — nothing was added), or "disabled" (sign=False).

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

Input Schema

NameRequiredDescriptionDefault
ccNocarbon-copy recipient(s), comma-separated.
opNosearch (default) | get | attachment | drafts | draft | accounts.search
toNorecipient(s), comma-separated. REQUIRED for a new message (omit when replying).
bccNoblind-copy recipient(s), comma-separated — a new message only.
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
bodyNothe message, rendered from markdown to HTML by default.
htmlNoexplicit HTML body (bypasses markdown rendering).
signNoappend the account's Gmail signature (default True); False writes the body alone.
indexNoop="attachment" — 0-based tiebreaker between same-named attachments.
queryNoop="search" — Gmail search query.
sheetNoop="attachment" of an .xlsx — sheet name or 0-based index.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
accountNoemail of the Google account to use — same choice as `_account`.
subjectNosubject line (new message only; a reply keeps the thread's subject).
_accountNoCompte à OPÉRER quand plusieurs existent. `oto_identity(op='list')`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
filenameNoop="attachment" — name of the attachment (e.g. "Contrat.pdf").
markdownNorender `body` from markdown when `html` is absent (default True).
max_rowsNoop="attachment" of an .xlsx — rows per sheet (default 200, max 5000).
reply_toNoid of the message to reply to. When set, this is a threaded REPLY (subject/thread preserved) and `to`/`subject` are ignored.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
from_nameNooptional display name for the From header.
message_idNoop="get"/"attachment" — the message id (from op="search").
attachmentsNofiles to attach, as `source` refs oto resolves server-side (the agent has no local disk). Each item — `kind` selects the origin: - Drive: `{"kind":"drive","file_id":"<id>"}` (id from drive_list/metadata) - Gmail: `{"kind":"gmail","message_id":"<id>","filename":"<name>"}` - URL: `{"kind":"url","url":"https://…"}` — e.g. a signed URL from `oto_upload_url` (upload a local PDF first) or drive_download. Named by the server's `Content-Disposition`, else the path; `"filename"` forces the name (its extension types the file). - Project file: `{"kind":"project_file","project_id":<id>,"file_id":<id>}` (ids from oto_project_files op=list)
max_resultsNoop="search"/"drafts" — max items to return (default 20).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.7/5.0
Behavior4/5

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

Goes well beyond the annotations: signature auto-append behavior and its three result states, the warning that a fresh draft may lag in an open Gmail tab, attachment size/type caps, `text_unavailable`/`image_unavailable` reasons, and short-lived signed URL fallbacks. Annotations only say it is non-readonly and non-destructive, so this is substantial added disclosure; only the auth/permission model for shared mailboxes is left implicit.

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?

Front-loaded with the one-line purpose and the `gmail_act` boundary, then structured as a scannable op list. It is long, and a few asides (the ⚠️ reload note, the parenthetical about the API not adding signatures) could be tightened, but nearly every sentence carries operational information.

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?

With 26 parameters and no output schema, the description compensates by documenting the return shape of every op (search, get, attachment encodings, drafts, accounts). Nothing an agent needs to call it correctly — including the draft-vs-send boundary — is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks: a concrete Gmail query example (`from:foo@bar.com is:unread newer_than:7d`), the source of `message_id` (from op="search"), the `filename`/`index` tiebreak, and `sheet`/`max_rows` truncation guidance. It also warns not to write a sign-off block in `body` because of signature injection.

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 verb+resource framing ("The user's Gmail mailbox — READ it, or prepare a DRAFT") and then enumerates all six ops with what each returns. It explicitly contrasts itself with the sibling `gmail_act`, so an agent can route between read/draft and send/mutate 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?

Gives explicit when/when-not: sending, archiving and deleting belong to `gmail_act`, which the client asks the user to confirm. It also states the follow-up path ("send it with `gmail_act(op="send", draft_id=<id>)` once the person agrees") and when to pass an `email` as `_account` via op="accounts".

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources