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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's job is to add context, which it does: threading headers set, original message quoted, recipients defaulting to the original sender, and the draft id returned. It omits auth requirements and the 25MB attachment cap (the latter covered in schema), but the added behavioral detail is substantive.

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 tight sentences, front-loaded with what is created and where, then conditional behavior, then return value. No filler sentences.

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 an 8-parameter tool with no output schema, the description covers the operation, the important conditional mode, and the return value, so an agent can call it correctly. Missing only permission/limit context that the schema partially supplies.

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 75% schema coverage, the schema already documents most fields; the description still adds real meaning for replyToMessageId by explaining its threading and quoting side effects and the recipient defaulting rule. Other parameters (to, cc, bcc, body, htmlBody, attachments) are 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?

States a specific verb and resource ('Creates a draft') plus the target location (Naver Mail drafts folder with the Korean name), which is unambiguous. It does not name siblings such as send_message or update_draft, so the differentiation is left implicit 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 description explains the conditional behavior when replyToMessageId is supplied, which implies a reply-draft use case, but never says when to prefer this over send_message/reply or when not to use it. Usage is inferable rather than explicit.

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 this is a non-readonly, non-destructive, non-idempotent write, so the safety profile is covered. The description adds a genuinely non-obvious side effect the annotations cannot express: missing parent labels are created automatically along the '/' path. It stops short of saying what happens when the label already exists, which matters given idempotentHint=false.

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, zero filler, with the core action stated first and the naming/side-effect detail packed into the second. Every clause earns its place.

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 creation tool with no output schema and annotations covering the safety profile, this is nearly complete: it explains the resource, the path syntax, and the parent auto-creation behavior. The remaining gap is duplicate-name handling, which an agent calling a non-idempotent create would reasonably want to know.

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 parameter's schema already includes the same 'Projects/Alpha' style example, so the description adds little new parameter detail. Its nesting syntax remark reinforces the schema rather than extending it; baseline 3 applies when the schema does the heavy lifting.

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 ('Creates') and resource ('a new user label'), and adds the clarifying gloss '(a Naver Mail folder)' so the agent knows what a label is in this domain. The create/update/delete/list distinction against siblings like update_label and list_labels is unambiguous from the verb alone.

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 context is implied rather than stated: the agent can infer this is the tool for making a new label, and the nested-path syntax tells it how to name one. However, there is no explicit guidance on when to prefer this over update_label, or on checking list_labels first to avoid duplicates.

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 destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds nothing beyond that: it does not say whether the deletion is permanent, whether the draft is recoverable or moved to trash, or what authorization is required — all valuable context for a destructive operation.

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 and completely free of waste, but it is under-specified rather than concise: one four-word sentence leaves no room for scope, consequences, or parameter notes.

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 destructive, irreversible-sounding mutation with no output schema and no annotation-level detail about permanence, the description should confirm what happens to the draft and whether recovery is possible. Neither is covered, so an agent cannot fully predict the effect of calling it.

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 0%, so the single required parameter draftId is undocumented everywhere. The description does not mention the identifier at all, leaving the agent to infer its meaning and format entirely from the property name.

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 pairs a specific verb with a specific resource ("Deletes a draft"), so the operation itself is unambiguous. However, it offers nothing to separate it from the many sibling mutation tools such as trash_message, update_draft, or delete_label, and the title is null so no extra signal exists.

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?

There is no statement of when to use this versus update_draft, trash_message, or any other removal path. The only implied guidance is the obvious mapping of "delete" to "draft"; no prerequisites, alternatives, or exclusions are mentioned.

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 destructiveHint=true, but the description adds the thing annotations cannot convey: the blast radius. It explains that deleting a label cascades to the messages inside it, which is the single most important behavioral fact for this tool and directly changes how an agent should behave.

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, zero filler, and the destructive warning is placed immediately after the purpose statement so it is read before any parameter detail. Nothing repeats the schema or annotations 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?

Covers the critical gap (cascading deletion of contained messages) for a destructive, non-open-world, idempotent tool whose parameter is fully documented. It stops short of saying whether the deletion is reversible or what happens to messages that are also in other labels, which would complete the picture for a high-stakes mutation.

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 one parameter at 100% schema coverage and the schema already pointing at list_labels as the id source, the description adds no further semantics such as format or validation rules. Baseline 3 applies since the schema fully carries this burden.

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 ('Deletes a user label') that cleanly separates it from sibling create_label/update_label/list_labels. It also disambiguates the domain term by noting that a label is actually a folder in Naver Mail, which an agent could not infer from the name alone.

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 precondition ('Confirm with the user first'), which is actionable guidance for a destructive operation. It does not name a safer alternative sibling (e.g. unlabel_message/unlabel_thread to remove the label from messages without deleting them), so the routing guidance is strong but not complete.

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 destructiveHint=false and openWorldHint=true, so the external-side-effect profile is already partly covered; the description still adds real value by warning that sending is user-visible and should be confirmed first and that the original attachments ride along. It does not describe failure modes or what the call returns.

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-loading the forward-plus-original-attachments behavior, then the comment-placement options, then the safety instruction. Nothing is redundant.

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 mutation tool with no output schema, the description covers the essential behaviors: original attachments included, where comments land, and the confirmation requirement. Missing only return-value expectations and whether forwardText and htmlBody can be combined.

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 86%, so the baseline is 3; the description only restates the forwardText/htmlBody distinction already spelled out in the schema and adds nothing for messageId, the required parameter, or the 25MB attachment constraint. Marginal value over structured fields.

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 ("Forwards a message") plus a distinguishing scope fact: original attachments are carried along, which separates it from send_message and reply. It never names those siblings explicitly, so the differentiation is inferred 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 "Confirm with the user before sending" gives a clear operational guardrail for when this fires, and the verb implies forward-an-existing-message. But there is no explicit routing versus reply, send_message, or create_draft, which are all plausible alternatives for the same intent.

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 genuinely useful behavior beyond that: text decoding for txt/csv/html/json/ics, base64 for everything else, and an 8MB ceiling. That's real context an agent needs before calling, though error behavior is unstated.

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, front-loaded with the action and scoped by the second on return format. No filler, no repetition of the name or 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 simple two-parameter read tool with no output schema, the description covers the operation, the return encoding rule, and the size limit – essentially everything needed to call it and interpret 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 50%: attachmentId is documented, messageId is not. The description adds no parameter-level detail, so the undocumented messageId carries on being self-evident from its name only. Baseline 3 is appropriate given partial schema coverage and no compensating description text.

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 ('Downloads') and resource ('one attachment of a message'), which cleanly separates it from get_message and other sibling tools. It doesn't explicitly name a sibling alternative, but the resource is unambiguous enough that an agent can pick it out of the list.

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 implied by 'one attachment of a message' and the schema note pointing at get_message as the source of the attachmentId. There is no explicit when-to-use or when-not statement, and no mention of what to do if the attachment is too large or unsupported.

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 structurally. The description adds nothing beyond that: no behavior for a missing/invalid draftId, no note on which account or mailbox is queried, and no mention of the messageFormat default (FULL_CONTENT) that materially changes payload size.

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?

A single front-loaded sentence with zero padding, but the brevity comes from omission rather than economy. It is efficient but under-specified for a tool with a non-trivial format enum.

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 simple read tool with annotations carrying the safety profile and no output schema to explain, the definition is minimally sufficient to invoke. It falls short on failure behavior and on the format-selection tradeoff, which is the only real decision an agent must make here.

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 50%: messageFormat is documented in detail in the schema, but draftId has no description and the description compensates for neither parameter. Nothing in the text clarifies id format or the cost/size implications of choosing FULL_CONTENT or RAW.

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 ('Retrieves') and resource ('a draft') keyed by id, so the operation is unambiguous. It does not distinguish itself from near-neighbors like get_message or list_drafts, relying on the name alone for that separation.

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?

No guidance on when to use this instead of list_drafts, get_message, or search_threads, and no prerequisites or exclusions. The agent must infer selection purely from the tool name.

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, so the safety profile is covered. The description adds useful behavioral context by noting that the response includes body and attachment metadata, and by warning that PLAIN_TEXT helps avoid context exhaustion. It does not cover error behavior, but with annotations present this is a strong addition.

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 wasted words, with the core purpose front-loaded and the alternative and format recommendation following immediately. Every sentence earns its place.

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 simple read tool with no output schema, the description supplies enough to call it correctly: the id-based single-message scope, the sibling alternative, and a format recommendation. Minor gaps remain around per-format return differences and error behavior, but the schema already covers the format details.

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 would be 3, but the description adds meaning beyond the schema by tying PLAIN_TEXT to a concrete rationale: preventing context exhaustion. The schema itself documents the enum modes thoroughly, so the description complements rather than repeats.

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 ('Retrieves a single email message by id') and explicitly distinguishes this tool from the sibling get_thread by noting that get_thread is for whole conversations. An agent can immediately tell what this tool does and when it differs from the conversation-level alternative.

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 key usage condition directly: use get_thread for whole conversations, implying get_message for single messages. It also gives explicit parameter guidance by recommending PLAIN_TEXT to prevent context exhaustion, which is actionable and reduces misuse.

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 useful behavioral detail beyond annotations by enumerating the returned fields (address, total, unread), which matters because no output schema exists. It doesn't mention authentication requirements or whether counts are scoped to inbox only vs all folders — the unread count is tied to 'inbox' but 'total messages' scope is ambiguous.

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, front-loaded with the return values and followed by the use case. No filler or redundancy.

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 zero-param read tool with no output schema, the description covers the essential return shape and the reason to call it. A slight gap remains around what 'total messages' spans (inbox only, or all folders) versus the explicitly inbox-scoped unread count.

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?

Zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies a no-argument call.

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 ('Returns') and names the exact values returned: connected address, total messages, unread count. This is clearly distinct from every sibling, which are all mail/draft/label mutation or retrieval tools.

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 'Use it to confirm which account is connected' gives a concrete triggering scenario. It stops short of stating when not to use it or naming alternatives, but no sibling overlaps meaningfully (no other account/session tool exists).

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: messages are returned oldest first, folders include inbox/sent/user folders, drafts are omitted, and threads are reconstructed from Message-ID/References headers. It does not cover permissions, pagination, or response shape, but with annotations present this is a strong disclosure.

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?

The description is four compact sentences, front-loads the core action and scope, then adds ordering, draft exclusion, reconstruction behavior, and format advice. Every sentence earns its place with no repetition or 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 read-only tool with fully documented parameters and annotations covering safety, the description gives enough behavioral context to call it correctly: thread scope, ordering, folder coverage, draft omission, and format recommendation. It does not mention pagination or response size limits, and with no output schema those details remain slightly underspecified.

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 schema already documents both threadId and the full messageFormat enum, explicitly labeling PLAIN_TEXT as recommended. The description's 'Use PLAIN_TEXT to save context' largely repeats the schema's recommendation rather than adding new parameter meaning, so the baseline 3 is appropriate.

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 a specific verb and resource: retrieves an email thread with all its messages, oldest first, across folders. The thread-level scope and 'all its messages' distinguish it from single-message tools like get_message and from search-oriented siblings like search_threads without requiring the schema to be opened.

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 description gives no explicit when-to-use or when-not-to-use guidance and does not route the agent to alternatives such as get_message or search_threads. The only directive, 'Use PLAIN_TEXT to save context,' addresses messageFormat selection rather than whether to call get_thread at all.

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=false, idempotentHint=true and destructiveHint=false, so safety is covered. The description then adds genuinely non-derivable behavior: moving a message to a folder changes its id and the new id is returned, and a message can hold only one folder label at a time. It stops short of stating failure behavior for invalid label ids or permission requirements.

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 tight sentences, front-loaded with the action, then the label vocabulary, then the one side effect that matters. No filler, nothing repeated from structured fields except where it aids scanning.

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 mutation with no output schema, the description covers the important gap (the id-changing side effect and the returned value) plus folder semantics. Missing only edge-case behavior: what happens with an invalid label id, and how folder replacement interacts with the existing INBOX label.

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?

Only 50% of the schema is documented: `labelIds` carries a rich enum-like description in the schema (and the description redundantly restates parts of it), while `messageId` has no description anywhere. The description partly compensates by implying the id may change and be re-issued, but the primary identifier's semantics remain undocumented.

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 ("Adds labels to a message") and enumerates what each label class does (STARRED, UNREAD, folder label). However, it never distinguishes itself from the near-identical sibling `update_message_labels`, nor from `label_thread`, leaving real ambiguity about which add-labels tool to pick.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. With siblings `update_message_labels`, `unlabel_message`, and `label_thread` in the same namespace, the agent is left to infer whether this tool replaces, complements, or duplicates them.

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=false, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds useful behavioral context beyond that: labels are applied to every message in the thread, and a folder label moves the conversation. It does not cover permissions or return behavior, but with annotations present the bar is lower.

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?

A single front-loaded sentence with no wasted wording. The key scope, thread-wide labeling, and a representative example are communicated immediately.

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?

The tool is simple, has only two required parameters, no output schema, and annotations that cover safety and idempotency. The description is nearly complete for correct invocation, missing only explicit sibling-routing guidance, 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 description coverage is 50%: labelIds is richly documented with valid values and folder-move semantics, while threadId has no schema description. The description adds examples such as STARRED and folder labels, but does not add meaning beyond what the labelIds schema already provides. Baseline 3 is appropriate for this coverage level.

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 a specific verb and resource: "Adds labels to every message in a thread." This clearly distinguishes thread-level labeling from message-level siblings like label_message, though it does not explicitly name alternatives. The examples (STARRED, folder label) further sharpen the operation.

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 implied by the thread-level scope and folder-label example, but there is no explicit guidance on when to choose this over label_message, update_message_labels, or unlabel_thread. The agent must infer the alternative from the sibling names.

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 and closed-world behavior are covered. The description adds only the query-syntax equivalence; it says nothing about pagination behavior or what fields come back by default, leaving gaps that annotations don't fill.

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?

A single front-loaded sentence with no filler; the filter behavior and the syntax pointer each carry information an agent needs. Nothing is redundant or buried.

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 read-only list tool with four optional params and no output schema, the description is adequate but thin: it omits pagination expectations, the default view, and any statement of what a draft record contains. Those are the details an agent would still have to discover from the schema alone.

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 50%: view and pageSize are documented inline, while query and pageToken are not. The description adds real value by tying 'query' to search_threads syntax, but it does nothing for pageToken and doesn't clarify view defaulting, so it only partly compensates for the coverage gap.

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 ('Lists drafts') plus the optional filter behavior, which separates it cleanly from get_draft (single draft) and search_threads (threads, not drafts). It stops short of noting the draft-specific scope details (which mailbox/account scope) that would pin it down fully.

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 word 'optionally' implies you can call it without a query, and the reference to search_threads hints at the query mechanism, but there is no explicit when-to-use vs. siblings like search_threads or get_draft. Usage is inferable rather than stated.

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 still adds real value by explaining that system labels map to folders while STARRED and UNREAD are flags, preventing misinterpretation of returned ids. It stops short of noting whether system labels are mutable or how counts are computed.

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?

Four short sentences, front-loaded with the purpose, then domain semantics, then the follow-up action. Dense and waste-free, though the folder-mapping sentence is long and could be tightened.

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 return-value burden and does so by naming the fields (id, message count, unread count) and referencing them downstream. It leaves minor gaps such as ordering or whether nested/user-label hierarchy is returned.

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?

The tool takes zero parameters, so the baseline is 4; the description correctly implies an unfiltered, account-wide listing without inventing parameter distinctions.

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 ("Lists labels") plus the payload returned (message and unread counts), which distinguishes it cleanly from the sibling mutators create_label/update_label/delete_label. The Naver-Mail folder semantics further pin down what a "label" is in this domain.

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?

"Use the returned id with label tools" explicitly positions this as the discovery step preceding label_message/label_thread/update_label etc. No exclusion guidance is given (e.g., when to skip listing), so it falls short of a 5.

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 readOnly=false, idempotent=true and destructive=false, so the safety profile is covered. The description adds essentially nothing beyond that: it doesn't say whether the move is reversible, what happens if the message is already in Spam, or that it returns no/limited data.

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?

A single short sentence with the action and destination front-loaded; nothing is wasted, though it is arguably under-specified rather than genuinely concise.

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 mutation tool with no output schema, the description should at minimum pin down the messageId format and note the reversibility/idempotency behavior. It does neither, so an agent must probe or guess before calling.

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 0% for the single messageId parameter, so the schema gives no format information. The description says only 'a message' and never clarifies whether messageId is an internal ID, an RFC 822 Message-ID, or a thread-scoped identifier, leaving the caller to guess.

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 ('Moves') and resource ('a message') with the destination ('the Spam folder'), which distinguishes it from unmark_message_spam and trash_message. It does not explicitly contrast with the sibling mark_thread_spam, so the message-vs-thread distinction must be inferred from the name.

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 intent (message is spam → move it to Spam) is implied clearly enough by the description, but there is no explicit guidance on when to prefer this over mark_thread_spam or when to use unmark_message_spam to reverse it.

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=false, idempotentHint=true and destructiveHint=false, so safety/repeatability is covered structurally. The description adds useful scope context ('every message' of the thread), but says nothing about whether the thread disappears from the inbox, who can perform it, or what happens to already-spammed messages.

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?

A single tight sentence with the action and destination front-loaded and zero 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 simple one-param action tool with no output schema and annotations carrying the idempotency/safety profile, the description covers the essential behavior. Minor gaps (return value, inbox removal semantics) keep it from a 5.

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 is one parameter (threadId) with 0% schema description coverage; the description refers to 'a thread' which lightly implies the parameter, but never confirms it accepts a thread ID or any format. Given the single self-evident parameter, this is adequate but adds little.

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?

A specific verb ('Moves') plus resource ('every message of a thread') and destination ('Spam folder'). The thread-level scope implicitly distinguishes it from the sibling mark_message_spam, but no sibling is named explicitly.

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 by the scope wording: the agent can infer it should use this over mark_message_spam when a whole thread is spam. There is no explicit when/when-not statement or named alternative.

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 establish that this is a non-read-only, non-idempotent, open-world action, and the description adds useful behavioral detail beyond them: the original is quoted below the reply, threading headers are set, and the agent should confirm with the user before sending. It does not cover rate limits or delivery behavior, but the key side effects are disclosed.

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 compact sentences, front-loaded with the core action and scope. Each sentence adds operational value: reply mode, threading behavior, required content, and confirmation guidance.

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 an open-world send action with annotations and a rich schema, the description covers what the agent needs: reply-vs-replyAll behavior, threading, quoted original, required body content, and a user-confirmation safeguard. No output schema exists, but return-value explanation is not necessary for successful invocation.

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 high at 88%, so most parameter meaning is already documented structurally. The description still adds important context not captured by the schema's required list: that body or htmlBody must be supplied, and that messageId for threaded replies should come from get_thread.

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 a specific verb and resource ('Replies to a message') and immediately distinguishes the two modes (sender vs. everyone with replyAll). It also distinguishes this from competing actions like send_message and forward by describing reply-specific behavior such as quoting the original and setting threading headers.

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 explicit routing guidance: use get_thread and the latest message id to reply within a thread. It also states the body/htmlBody requirement and a safety condition ('Confirm with the user before sending'), leaving little ambiguity about when and how to use the tool.

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/openWorldHint, but the description adds critical behavior beyond them: results are previews capped at 5 messages per thread, scoped to the current page, and messageCount reflects only this page. That caveat materially changes how an agent should interpret and trust the output.

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?

The critical preview warning is front-loaded before the purpose statement, which is the right priority ordering. Slightly redundant, since the closing sentence repeats the "read full threads" advice already given in the opening warning, but no sentence is wasted.

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 spells out the shape of each thread and message, so an agent knows what it receives. Combined with the preview limitation and the get_thread escalation path, nothing needed to call this 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 description coverage is 100%, and the query syntax, view enum, pageSize bounds and pageToken meaning are all fully documented in the schema. The description only restates "with pagination" and preview semantics, adding little parameter-level meaning beyond structured fields.

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 ("Lists email threads in the Naver Mail account matching a query"), plus ordering (newest first) and pagination. It also enumerates the returned fields (id, messageCount, messages with sender/recipients/date/labelIds/subject/snippet), which makes it easy to distinguish from get_thread.

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?

Explicitly says "Use it to find thread ids before reading full threads or acting on emails" and names the alternative (get_thread) with the condition that selects it. It also gives a when-not rule: never answer questions about the latest or unread email from previews alone.

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?

Adds context beyond annotations: the send is immediate, a copy is stored in Sent, and user confirmation is expected first — meaningful for a non-idempotent, open-world mutation. It doesn't cover failure behavior, whether drafts are consumed on partial errors (that detail lives only in the schema), or attachment 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?

Four short sentences, front-loaded with the core action, then mode selection, then the safety precondition. No repetition of schema details and nothing wasted.

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 10-parameter, output-schema-less send tool with strong annotations and 90% schema coverage, the description covers the essential decision points (new message vs draft vs thread) plus the confirmation requirement. Missing only post-send/error semantics, which are low-value for selection.

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 90%, so the schema already documents draftId, replyThreadId, replyToMessageId, body/htmlBody, and attachments in detail. The description only restates the draft and threading modes at a higher level, adding no syntax or edge-case meaning beyond the schema. Baseline 3 is appropriate.

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 (sends an email immediately via SMTP, saves a copy in Sent), which cleanly separates it from create_draft. However, the threading instructions ('give replyThreadId or replyToMessageId') blur the boundary with the `reply` sibling, which the description never mentions.

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 routing rules for two modes: send an existing draft via draftId, and thread via replyThreadId/replyToMessageId. It also adds a real safety instruction ('Confirm recipients and content with the user before sending'). It stops short of saying when to use `reply` or `forward` instead of this tool.

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 destructiveHint=false and idempotentHint=true, but that leaves reversibility ambiguous; the description resolves this by labeling the operation a soft delete, implying recovery is possible. It doesn't mention that a sibling (untrash_message) reverses it, which would have closed the loop.

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 operation and the default-selection rule front-loaded; nothing is redundant.

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, non-destructive mutation with no output schema, this covers what it does and when to prefer it. Missing only the reversible counterpart and any note on where the message ID comes from.

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 0% and the single parameter messageId is never described or formatted. 'A message' weakly implies the target, but the description adds no syntax, format, or ID-source guidance beyond the schema's bare string type.

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 ('Moves a message to Trash') plus the soft-delete semantics. It does not explicitly contrast with the sibling trash_thread, though 'message' vs 'thread' is implied by the name.

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?

Explicitly declares this the default tool when the user asks to delete without requesting permanent deletion, which is a clear selection rule. It stops short of naming the permanent-delete alternative, leaving the agent to infer which tool that is.

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 cover safety profile (readOnly=false, destructive=false, idempotent=true), and the description adds the key extra fact that this is a soft delete affecting all messages in the thread — consistent with destructiveHint=false. It stops short of stating recoverability or that thread metadata/labels persist.

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?

A single front-loaded sentence with zero filler; the scope ('every message of a thread') and semantics ('soft delete') are delivered immediately.

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 soft-delete tool with rich annotations and no output schema, this is nearly sufficient. A note on reversibility (via untrash_thread) and any effect on thread labels would close the remaining 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?

Only one parameter (threadId) with 0% schema description coverage, so the description carries the burden. It implies the identifier refers to a thread rather than a message, but adds no format, source, or example for the ID.

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 ('Moves ... to Trash') and resource ('every message of a thread'), plus the 'soft delete' qualifier. The thread-level scope implicitly separates it from trash_message, though no sibling is named outright.

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 by the name and phrasing; the description never states when to prefer this over trash_message (single message) or how it relates to untrash_thread for reversal. No exclusions or prerequisites are given.

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 idempotent=true, destructive=false, readOnly=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait: moving changes the message id and the new id is returned, which an agent cannot get from annotations. It stops short of covering failure modes (e.g., removing a label that is not present).

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 tight sentences, zero waste, with the core action first and the id-change caveat second. Every clause carries information 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 two-parameter, low-complexity mutation with no output schema, the description covers the non-obvious return value (new id) and the label effect. Minor gaps remain around idempotent behavior when a label is absent and the lack of messageId documentation.

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 50%: labelIds is richly documented in the schema while messageId has no description anywhere. The description reinforces label semantics with UNREAD/STARRED examples but adds no messageId guidance or id-format detail, so baseline 3 fits.

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 ("Removes labels from a message") and adds concrete examples (UNREAD to mark read, STARRED to unstar) that make the effect unambiguous. It implicitly contrasts with the sibling label_message but never names it, so differentiation relies on the agent inferring the inverse.

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 examples imply the use case (marking read/unstarring), but there is no explicit when-to-use versus alternatives such as label_message, update_message_labels, or unlabel_thread. Folder-move semantics from the schema suggest editing scenarios, yet the description does not route the agent among these overlapping tools.

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 safe, idempotent, non-destructive mutation, so the bar is lower. The description's real addition is batch scope — that the label change cascades across every message in the thread rather than one message — which is exactly the behavior an agent needs to know before committing.

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?

A single sentence, front-loaded with the action, with the example earning its space by translating the mechanic into a user-visible outcome. 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 two-parameter idempotent mutation with annotations covering safety and no output schema, the description gives action, scope, and a worked example. Minor gap: no mention of behavior when a label is absent from some messages in the thread.

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 sits at 50%: labelIds carries a rich description (allowed values, folder-moving semantics) while threadId has none. The description only echoes 'UNREAD' from the schema and adds no format or constraint detail, so it neither compensates for nor worsens the gap. Baseline 3.

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 ('removes labels from every message in a thread') and the 'every message' qualifier implicitly separates it from unlabel_message. It does not explicitly name the sibling, but the thread-level scope is unambiguous.

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 example ('remove UNREAD to mark the whole conversation as read') gives one concrete use case, which implies when to reach for this tool. It offers no exclusions or comparison to unlabel_message / update_message_labels for single-message or mixed-operation cases.

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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the agent knows this is a safe, repeatable mutation. The description adds the meaningful state change (Spam to Inbox), but does not say what happens if the message is not in Spam, whether failure is silent, or what is returned.

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 sentence, front-loaded with the action and resource, with zero filler. Nothing to remove and nothing redundant.

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, non-destructive, idempotent mutation with annotations covering the safety profile and no output schema, the definition is nearly sufficient. The only missing piece is edge-case behavior when the message is not currently in Spam.

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 is a single required parameter, messageId, with 0% schema description coverage, so the description carries no additional format or semantics guidance. The parameter is self-evident for an email domain and does not require explanation, so this is adequate but unhelpful.

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 (moves out of Spam) and resource (a message), and names the destination (Inbox). This cleanly distinguishes it from mark_message_spam (opposite direction) and unmark_thread_spam (thread-level).

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 implied usage (restore a spam-classified message to the Inbox) is inferable from the description, but there is no explicit statement of when to use it versus unmark_thread_spam or why one would choose the message-level over the thread-level variant. It also says nothing about preconditions, such as whether the message must currently be in Spam.

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=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the effect applies to all messages in a thread rather than one message, but says nothing about permissions, behavior when the thread is not in Spam, or any resulting label/state changes.

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 short sentence with zero filler, and the resource and effect are front-loaded. Nothing could be removed without losing meaning.

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, non-destructive, idempotent tool with annotations and no output schema, this is close to adequate. Still missing are edge-case behavior (thread not in Spam, partial failures) and any hint of the required authorization scope.

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 0% for the single required threadId, so the description carries some burden. Saying 'a thread' implies threadId identifies the thread whose messages are moved, but it adds no format, example, or accepted-ID detail beyond that weak implication.

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 a specific verb ('Moves ... out of') and a specific resource ('the messages of a thread'), and the thread/message distinction implicitly separates it from the sibling unmark_message_spam. It does not explicitly name that sibling, so it stops short of a 5.

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?

There is no guidance on when to use this versus unmark_message_spam or mark_thread_spam, and no stated preconditions (e.g., thread must currently be in Spam). The use case is only inferable from the name.

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=false, destructiveHint=false and idempotentHint=true, so the bar is lower; the description still adds genuine context by disclosing the resulting folder (Sent vs Inbox depending on whether the user was the sender), which annotations cannot express. It omits error behavior when the message is not in Trash, keeping 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?

A single sentence with zero padding, with the core action front-loaded and the conditional outcome parenthetical kept tight.

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, non-destructive, idempotent restore operation with no output schema, the description covers the action and its outcome well enough to call correctly. The only real gap is the undocumented messageId, which is a parameter-semantics issue rather than a missing context.

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 0%, so the description must carry the meaning of messageId, but it never mentions the parameter or its expected format. Only the phrase 'a message' hints at a single message identifier, leaving the sole parameter effectively undocumented across both sources.

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?

A specific verb ('Moves... out of Trash') plus an explicit state transition and destination logic, so an agent knows exactly what effect it has. It also implicitly distinguishes itself from the sibling untrash_thread by operating on a single message, though it never names that sibling.

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 implied by the name and the Trash reference — call it to restore a trashed message. There is no explicit statement of prerequisites (the message must currently be in Trash) and no routing to untrash_thread or trash_message when the agent has the wrong operand.

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 idempotent, non-destructive, non-read-only behavior, so the bar is lower. The description usefully clarifies that the operation acts on the thread's messages rather than the thread container itself, but says nothing about return values, partial-failure behavior, or what happens to messages not in Trash.

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?

A single front-loaded sentence with no filler; the action and resource come first. It is efficient, though it may be slightly too terse for a mutation tool.

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 annotations covering the safety profile and only one parameter, the description is close to adequate, but it omits where to obtain threadId and what state change to expect (e.g., thread no longer appears in trash listings). No output schema exists, so a short note on the effect would have helped.

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 0% and the single threadId parameter has no documented format or source (e.g., obtained from search_threads or get_thread). The description only implies the parameter by saying 'of a thread', leaving the agent to infer the identifier's origin and type.

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 (moves out of Trash) and a specific resource (the messages of a thread), which distinguishes it from the sibling untrash_message. It is clear what the tool does, though it does not explicitly name the sibling it contrasts with.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as untrash_message for single messages. The restore-from-Trash scenario is only implied by the name and description.

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?

Discloses behavior far beyond the annotations: precise merge semantics, the body-only side effect that clears htmlBody, the warning that attachments are NOT merged and are removed if omitted, and the non-obvious fact that the draft id changes and is returned. These are exactly the traps an agent would otherwise hit.

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 dense sentences, front-loaded with the merge rule before the edge cases, and the highest-risk warning (attachments deleted) is capitalized. No filler or restatement of the name.

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 non-idempotent mutation with no output schema, the description covers the destructive edge case, the identity change, and the update contract. An agent has everything needed to call it without silently destroying data.

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 75%, but the description adds real semantics the schema cannot express: per-field overwrite-vs-keep behavior across all 8 parameters, the body/htmlBody interaction, and the attachment replacement rule. It meaningfully reduces ambiguity about how omitted vs. provided values are treated.

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 ("Updates a draft") and immediately qualifies it with the operative semantics ("merge semantics"). This clearly separates it from create_draft, get_draft, delete_draft and list_drafts without needing the schemas.

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 conditions that govern correct use: non-empty fields overwrite, omitted fields are kept, body-only clears htmlBody, and attachments must be re-provided. It never explicitly routes the agent to a sibling (e.g. create_draft for a new draft, or send_message instead of updating), so it stops short of 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 already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only the "(folder)" gloss and says nothing about side effects such as the new name propagating to all messages/threads already carrying the label, and nothing about the response.

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?

A single short sentence with the key information front-loaded and zero waste. It is arguably too terse for a rename operation, but nothing is redundant.

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?

A simple two-parameter mutation whose annotations and schema carry most of the load, so the description is close to sufficient. It nonetheless omits the propagation effect of a rename and any indication of the response, which a caller would want for a mutating tool with no output schema.

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%, with both labelId ("User label id from list_labels") and displayName ("New name") documented. The description adds no meaning beyond that, 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?

States a specific verb (renames) and resource (user label), and the parenthetical "(folder)" clarifies what a label is in this API's vocabulary. It does not explicitly distinguish itself from create_label/delete_label/list_labels, but the verb makes the distinction reasonably evident.

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?

No guidance on when to use this versus create_label or delete_label, nor any prerequisites (e.g., that the label must already exist). The only routing hint, that labelId comes from list_labels, lives in the schema rather than the description.

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 idempotent, non-destructive, and non-read-only, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond that: moving a message between folders changes its id, and the new id is returned. It still omits what a folder move implies for permissions or concurrent access, keeping 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, zero waste, with the core purpose front-loaded and the id-mutation caveat immediately after. Every sentence earns its place.

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?

The single biggest gotcha (id changes on move) is captured, but there is no output schema and the description does not cover the remove path, the required messageId, or what the response looks like beyond the new id. Adequate but with clear gaps for a 3-parameter mutation tool.

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 only 33% and the description adds no parameter-level meaning at all — it does not explain messageId (required), removeLabelIds (fully undocumented anywhere), or the add/remove interaction. It relies entirely on the schema's addLabelIds prose, leaving an agent guessing about removal and the required id.

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: adds and/or removes labels on a message, explicitly combined 'in one call'. That is clear, but it never names the sibling tools (label_message / unlabel_message) it subsumes, so an agent must infer the distinction itself.

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?

'in one call' implies this is the tool to pick when both adding and removing are needed, but there is no explicit when/when-not guidance relative to label_message, unlabel_message, or label_thread, and no stated prerequisites.

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