Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

gmail_act

Destructive

ACT on the user's Gmail mailbox — ⚠️ every op here takes effect: a mail LEAVES, a message moves. Reading and drafting are gmail.

op (required):

  • "send": send a mail, the mail LEAVES. Either an existing draft, as it stands: draft_id (from gmail(op="draft") or gmail(op="drafts")) — the usual path, the person could read it first; or a full message: to, subject, body (or reply_to for a threaded reply), the same arguments as gmail(op="draft"). Returns kind: "sent", the message id and threadId. Never report "sent" without reading kind.

  • "archive": removes the INBOX label from message_ids.

  • "trash": moves message_ids to the trash (Gmail deletes them after 30 days). One call per message: a PARTIAL trash is possible and is named — replay only what was not attempted.

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). (A draft is sent as it stands: its signature was added when it was written.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "gmail_act"
  }
}

Input Schema

NameRequiredDescriptionDefault
ccNocarbon-copy recipient(s), comma-separated.
opYessend | archive | trash.
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.
_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')`.
draft_idNoop="send" — the draft to send, as it stands (no other argument).
markdownNorender `body` from markdown when `html` is absent (default True).
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.
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)
message_idsNoop="archive"/"trash" — the message ids to act on.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety bar is lowered, but the description still adds substantial behavior: mail LEAVES, trash has a 30-day deletion window, a partial trash is possible and replay should cover only unattempted ids, and `kind: "sent"` must be read before reporting success. The signature-append policy and its three reported outcomes (appended/none_configured/disabled) are behavior the agent cannot infer from any structured field.

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-loads the destructive framing and then organizes by `op`, which is the right structure for a multi-op tool. Slightly inflated by heavy backticking and mid-sentence line breaks, plus a parenthetical aside about the API never adding the signature, but almost every clause carries operational meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 21-parameter destructive tool with no output schema, the definition covers the risky paths thoroughly: send results, archive label removal, and trash partiality. It does not say what `archive` or `trash` return on success or on failure, which is the main remaining gap for an agent that must verify outcomes.

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 100%, so the per-field definitions are already documented. The description still adds cross-parameter conditionality the flat schema cannot express: which args apply to which op, that a threaded reply via `reply_to` ignores `to`/`subject`, that `draft_id` takes no other argument, and that `body` should not carry a manual sign-off. The opaque `_org`/`_run_id`/`_instance` plumbing and the `attachments` source-ref shapes are left entirely to the schema.

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?

"ACT on the user's Gmail mailbox — every op here takes effect" states a specific verb and resource, and explicitly contrasts with the sibling `gmail` for reading/drafting. The three ops (send/archive/trash) are enumerated with their concrete effects, so an agent can distinguish this from `gmail` 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?

It names the alternative tool (`gmail`) and the boundary that selects it: reading and drafting belong there, anything that takes effect belongs here. Within the tool it routes between the two send paths (existing `draft_id` labeled "the usual path" vs building a new message with `to`/`subject`/`body`), and explains archive vs trash with a concrete consequence (30 days then deletion).

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

All Tulina toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources