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

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false), and the description usefully reinforces that nothing is transmitted to recipients. It says nothing about what the call returns (a draft id?), whether repeated calls duplicate drafts, or how the saved draft is later sent via send_draft — a notable gap given there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the action and its key constraint front-loaded and the routing hint second. No filler or restatement of the title.

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

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

For a nine-parameter compose tool with no output schema and no annotation coverage of results, the description leaves the agent unsure what comes back and how to follow up. The sending-suppression fact is covered, but the draft lifecycle is not.

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

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

Schema description coverage is 100% and all nine parameters carry inline descriptions, including conditional optionality (to/subject optional when replying, reply_all semantics). The description adds no parameter-level detail beyond that, so the schema does all the work and baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ("Save a message ... in Gmail Drafts") and immediately negates the confusable action ("without sending it"), which separates it from send_email and send_draft. It stops short of naming those siblings explicitly, so differentiation relies on inference.

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

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

"The safe default for writing" gives the agent a clear selection rule for the compose-without-transmitting case, and "new or reply" covers both entry points. It offers no explicit exclusion or pointer to send_email/send_draft for the opposite case, so it is clear context rather than full when/when-not guidance.

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

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

Annotations only declare write/non-destructive/non-open-world; the description adds the missing context an agent needs: the return payload (id and name) feeding modify_labels, the duplicate-name failure mode, and the account-level connection requirement. It also documents the '/' nesting behavior as a mutation semantic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and return value, then trigger, then edge cases, then prerequisite — every sentence carries information. Minor redundancy in restating the '/' nesting rule that the schema already explains.

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

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

No output schema exists, yet the description names the returned fields (id, name) and their purpose, so an agent knows what it gets back. For a 2-parameter write tool with annotations, nothing material is missing.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description's nesting note largely restates the schema's own "'/" nests it under a parent" text. It adds the concrete example "Projects/Acme" but no new constraints such as name length or character rules, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Create a new user label") plus scope ("in one mailbox") and outcome ("return its id and name"). It is clearly separable from list_labels (read) and modify_labels (apply to messages) named in the same sentence.

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

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

Explicit trigger: "when the user wants mail filed under a label that list_labels does not show yet," which both names the sibling to check first and the condition that selects this tool. It also gives a hard prerequisite ("Only for accounts connected with --labels") and a pre-condition failure (name already exists), leaving little to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the constraint that ids originate from search (implying failure on foreign ids), but it says nothing about whether attachments or headers are included, error behavior, or payload size limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence that leads with the return value and then supplies the id form. Slightly redundant with the schema's own parameter description, but there is no filler.

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

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

For a single-parameter read tool with full schema coverage and safety annotations, most of what an agent needs is present. With no output schema, however, the description is the only source describing the return value, and "full text" leaves open whether headers, metadata, or attachments are included.

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

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

Schema description coverage is 100% and the single parameter's schema description is essentially identical to the note in the tool description. The description restates rather than extends the meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific resource and result ("full text of a message returned by the search tool") and pins down the id format, so an agent knows this is a message-body retrieval by search result id. It does not distinguish itself from near-identical siblings such as read_email or read_thread, which is the main clarity gap.

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

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

Usage is only implied through the precondition that the id must come from the search tool, which does usefully tell the agent it cannot pass arbitrary message ids. There is no explicit statement of when to pick this over read_email or search_emails, and no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so 'Does not change the mailbox' is largely redundant. However the description adds substantial behavior the annotations cannot convey: the content-type routing (text/PDF-with-text-layer to text, images up to 5 MB returned visually, everything else and scanned PDFs written to ~/.multi-mail/attachments with a path), plus the not-found error listing available attachments. It does not mention truncation behavior for max_chars or the save flag semantics, keeping it short of complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what it does and returns, then selection rules, then the safety note. Every sentence carries distinct information; nothing repeats the schema verbatim.

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

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 fully by mapping each return form (text, visible image, saved file path with note, error listing attachments). For a 6-parameter read tool with full annotation coverage, nothing an agent needs is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description earns the extra point by explaining selector precedence — part_id preferred, filename as fallback, neither required for single-attachment messages — which is genuine cross-parameter logic the schema does not state.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Download one attachment of a message and return its contents') and immediately scopes it to a single attachment of a specific message, distinguishing it from read_email which only lists attachments. An agent knows exactly what this returns.

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

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

Explicit sequencing guidance: 'Use it after read_email when the user needs what an attached invoice, report or photo says.' It also tells the agent how to select the target (part_id from read_email's list, or filename) and that a single-attachment message needs neither selector — a genuine decision rule, not a hint.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so 'changes nothing' largely restates the safety profile. The real added value is the enumeration of return contents: email, alias, labels/calendar enablement, default account, and drafts-only versus sending mode, which tells the agent what signals it can act on afterwards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each doing distinct work: purpose, when-to-call, and what comes back. The scoping information is front-loaded and there is no filler.

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

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

With no output schema, the description carries the full burden of describing return values, and it does so field by field, including the operationally important drafts-only mode flag and default-account marker.

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

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

There are zero parameters, so the baseline is 4; the description correctly confirms 'takes no input', removing any doubt about whether an account filter is required. Nothing further is possible for an empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('List the Gmail accounts this server can use'), which is unmistakably distinct from siblings like list_labels or list_drafts that also list things.

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

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

It gives an explicit call condition ('first when the user has not said which mailbox') and states the downstream purpose: obtaining the alias values to pass as 'account' to every other tool. That is a clear when-to-use plus a named relationship to all siblings.

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

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

The annotation readOnlyHint=true already declares the safety profile, and the trailing "Read-only." merely restates it. What the description genuinely adds beyond structured data is the returned field set (draftId, message id, thread id, date, recipients, subject, snippet) and the linkage that draftId is required by send_draft — but with no output schema, this still leaves the exact response shape to inference.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and result contents, then usage, then the handoff to read_email. Nothing is padded; the only near-redundancy is the two-word "Read-only." closing.

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

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

With no output schema, the description compensates well by enumerating the fields returned and flagging the one field (draftId) that unlocks a sibling tool. For a two-optional-parameter read tool, an agent has everything needed to select and call it correctly.

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

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

Schema coverage is 100% and both parameters are fully documented in the schema, so the baseline applies. The phrase "in one mailbox" hints at the account parameter's role but adds no detail on alias/local-part handling or result-limit behavior beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List the drafts saved in one mailbox") and immediately differentiates scope: listing only, not reading full text. An agent can distinguish it from send_draft, create_draft, and read_email without consulting any schema.

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

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

Gives two concrete use cases ("check what is waiting to be sent" and "find a draft made earlier with create_draft") and an explicit alternative with its trigger condition ("To read a draft's full text, pass its message id to read_email"). The routing decision is fully determined.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the bar is lower, yet the description adds real content: which label categories are returned, the fields per label, and the sort order. It does not discuss volume, pagination, or what happens on an unknown/unconnected account, and restates "Read-only" redundantly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: identity of the tool first, then the two routing use cases, then an availability note. The trailing "Read-only" earns little since annotation readOnlyHint already says it, but overall there is no wasted bulk.

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

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

For a one-optional-param, read-only list tool with no output schema, the description covers content, fields, ordering, and downstream usage, which is everything an agent needs to call it and consume the result correctly.

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

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

Schema coverage is 100% and the single optional account parameter is fully documented there, so the description adds no meaning about it beyond referencing "one mailbox" implicitly. Baseline 3 is appropriate when the schema carries the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List every label of one mailbox") and scopes it precisely: system labels plus user labels, each with id, name and type, sorted by name. It is clearly distinguishable from siblings create_label and modify_labels, which mutate the same resource.

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

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

Gives two concrete when-to-use paths: finding the exact name for a "label:" search in search_emails, or the name/id to pass to modify_labels. It also preempts an availability question with "Works on every account, with or without --labels."

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

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

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing error behavior for unknown label names, the exact return payload (account plus added/removed label ids), and an explicit safety boundary: TRASH and SPAM are refused, so deletion and spam-marking are impossible. The connection prerequisite is also surfaced. Nothing here 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then use cases, then error/return behavior, with no filler. A couple of sentences are densely packed with semicolon-joined clauses, which slightly hurts scannability but every clause carries information.

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

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

Although there is no output schema, the description names the return values, the failure modes, and the account prerequisite. For a 5-parameter mutation tool with all-optional params, an agent has everything needed to call it correctly and to know what it cannot do.

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

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 meaning the schema lacks: labels may be names in any case or ids from list_labels, and unknown names produce an error. It also implicitly explains the message_ids vs. thread_id choice. It does not cover edge cases such as passing both targeting parameters or empty add/remove.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair and resource ('Add or remove labels') plus the two targeting modes (specific messages vs. every message of a thread). It is clearly distinguishable from siblings create_label and list_labels, which are named as complements rather than alternatives.

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

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

Gives concrete when-to-use recipes mapped to intent: mark read = remove UNREAD, mark unread = add UNREAD, archive = remove INBOX, star = add STARRED, file mail = add a label. It also routes the agent to list_labels for ids and create_label for new labels, and states the prerequisite (account connected with --labels) with a fallback error hint.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, but the description goes well beyond them: HTML-to-text conversion, body truncation with the exact marker and truncated flag, attachment contents excluded, unknown message_id producing a 'not found' error, and the fact that reading does not mark the message as read. Those are the non-obvious behaviors an agent would otherwise have to discover by trial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with what is returned, then routing, then edge cases (truncation, missing attachments, bad id, side effects) — a logical order with no filler sentences. Every clause carries operational information; the long opening list is a payload description, not verbosity.

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

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

There is no output schema, so the description correctly compensates by enumerating the returned fields and flagging the truncation indicator. For a 3-parameter read tool it fully covers routing, limits, failure mode, and side-effect profile — nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description nonetheless adds behavioral meaning to max_chars by explaining that the body is cut at that limit, marked '[truncated]', and flagged with truncated=true, which tells the agent how to react to the value rather than just what it is. message_id semantics (unknown id returns a 'not found' error) are also surfaced, though account is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ('Read one message in full') and enumerates exactly what is returned: from, to, cc, reply-to, date, subject, labels, body as plain text, and attachments with part_id/name/type/size. It explicitly distinguishes itself from read_thread (whole conversation) and get_attachment (attachment contents), so an agent can route without opening any schema.

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

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

It states the trigger clearly ('after search_emails when you need what a single message says') and names the two alternatives with the conditions that select them: read_thread for a whole conversation, get_attachment for attachment contents. Both a when-to-use and a when-to-use-something-else are present.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered and 'Read-only' is redundant. The description still adds real behavior beyond the annotations: oldest-first ordering, the shared max_chars budget split evenly with a 2,000-character floor per message, '[truncated]' marking for cut bodies, and an error on unknown thread_id. The only gap is the shape of that error response, which is minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what is read and in what order, then selection guidance, then the truncation rule and error behavior. No filler sentences, and each clause contributes a distinct fact an agent needs.

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

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

For a three-parameter read tool with no output schema, it covers ordering, field parity with read_email, truncation semantics, and failure on a bad thread_id. Nothing an agent needs in order to call it correctly 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.

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 goes further by clarifying that max_chars applies across the whole thread rather than per message and that each message gets an equal share with a 2,000-character minimum. That resolves the main ambiguity an agent could hit when setting the value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Read a whole conversation: every message in the thread, oldest first' — and pins the return shape by reference ('same fields as read_email'). It explicitly separates itself from the closest sibling, read_email, so an agent can choose 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.

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

Gives both a positive condition ('when the reply history matters, such as before answering or summarising a back-and-forth') and an explicit alternative ('use read_email for a single message'). The routing decision is fully specified rather than implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two behaviors annotations do not: the search spans all connected accounts, and the return is ids rather than message content, implying a required follow-up call. It omits result caps, pagination, and how cross-account hits are ordered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero padding, with the scope stated before the return-value note. Nothing could be removed without losing information.

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

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

For a one-parameter read tool with no output schema, the description covers scope, query dialect, and that the return is ids for fetch. Remaining gaps are pagination and result limits, which matter for a tool that fans out across every connected account.

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

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

With 100% schema coverage and a single documented parameter, the baseline is 3. The description restates that the query is Gmail syntax, which the schema already says ('Gmail search query'), so it adds little beyond confirming the query language.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource and adds meaningful scope: 'every connected Gmail account' with Gmail query syntax. It stops short of distinguishing itself from the sibling search_emails, so the cross-account vs. single-account contrast is only implied rather than stated.

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

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

The sentence 'Returns result ids for the fetch tool' gives a useful chaining instruction, which is real usage guidance. However, it never states when to prefer this over the sibling search_emails, nor any exclusion or preconditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it enumerates the returned fields (id, thread id, date, from, to, subject, snippet) and defines the empty-query fallback, which shapes what the agent should expect back. It does not mention pagination or result limits, though max_results and page_token are documented in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each doing distinct work: scope and syntax, then return fields and the read_email handoff, then the empty-query default. Front-loaded with the search scope, and nothing is padding.

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

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

With no output schema, the description correctly spells out the returned fields and routing to read_email for bodies. For a read-only search tool whose annotations carry the safety profile, this is close to complete; only pagination and the 100-result cap are left to the schema, which is a minor gap.

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

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

Schema coverage is 100%, so the parameter docs already carry the syntax detail, making 3 the baseline. The description nonetheless adds meaning the schema lacks: it explains the empty-query default behavior and reinforces account="all" as an aggregation mode, which affects how the agent interprets the results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Search one mailbox, or all of them... using Gmail search syntax') and names its scope precisely. It goes further than the sibling names alone: it hands off 'full body' retrieval to read_email, so an agent can tell search_emails apart from read_email and read_thread 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.

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

It gives clear operating context: the account="all" mode for cross-mailbox search, the read_email alternative for full bodies, and the default that an empty query returns the newest mail. It does not address when to prefer this over the generic 'search' sibling, which is the one routing question an agent still has to infer.

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

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

The annotations already declare this is a non-read-only, open-world, non-destructive operation, so the safety baseline is covered. The description adds a meaningful consent guardrail beyond that. It omits what happens to the draft after sending (is it consumed/moved?) and what the call returns, which matters for a mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste. The action statement comes first and the consent constraint immediately after, which is the right order for a mutation with a guardrail.

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

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

For a two-parameter send action, the description covers the core action and the consent rule but leaves the post-send state and return value unaddressed, and there is no output schema to cover that gap. It is adequate but not complete for a destructive-adjacent side-effecting call.

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

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

Schema coverage is 100%, with draft_id's provenance (create_draft or list_drafts) and the optional account fallback fully documented in the schema. The description adds no parameter meaning of its own, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Send an existing draft" gives a specific verb and resource that is unambiguous. It does not, however, distinguish itself from the sibling send_email, which an agent could easily confuse with this tool.

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

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

The second sentence is an explicit gating condition: only send when the user explicitly asked. That is real when-to-use guidance. It stops short of naming the alternative (send_email for a new message) or stating what to do when consent is ambiguous.

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

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

Annotations declare the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds the trait that matters most: dispatch happens immediately with no undo step, so consent must be secured first. It does not mention rate limits, send quotas, or what happens on delivery failure, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The capability statement comes first and the safety constraint second, so the agent reads the routing rule before the guardrail.

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

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

For a nine-parameter outbound-mutation tool the schema carries all field detail, and the description covers the two things the schema cannot: when to send and the requirement to confirm first. The only real gap is the absence of a stated fallback to create_draft when the user has not yet confirmed.

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

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

Schema description coverage is 100% and every parameter, including reply_all and reply_to_message_id semantics, is already documented there. The description only echoes the recipient/subject/body trio during the confirmation instruction, adding no new meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Send a message") and covers both modes (new or reply), so an agent knows exactly what the tool produces. The word "immediately" implicitly separates it from the draft-creating siblings, but no sibling is named, so differentiation is left to inference.

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

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

Gives an explicit gating condition — only after the user explicitly asked to send — plus a confirmation prerequisite covering recipients, subject and body. It does not name the alternative path (create_draft / send_draft) for the case where the user has not confirmed, which would have made routing unambiguous.

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