Faivelo Email

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds genuinely useful context beyond that: the message is not deleted but reverts to an ordinary draft, and the call fails after the send begins. That corrects the potentially misleading destructive framing and discloses the failure mode, though it says nothing about permissions or idempotency.

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, followed by the outcome and the failure condition. No filler and every sentence 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 mutation with full schema coverage and annotations covering safety, the description supplies the two things structured fields cannot: the resulting state of the message and the failure boundary. Nothing needed to invoke it correctly is missing, and no output schema exists to require return-value 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 description coverage is 100% and both parameters are documented there, including where the scheduled send id comes from (list_scheduled, send_message, send_draft). The description adds no parameter detail, 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 (stop/cancel) and resource (scheduled send) with a clear scope: before the send goes out. An agent can distinguish this from send_message, send_draft, and list_scheduled 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?

The description defines the operative window ('before it goes out') and states the failure condition ('once the send has started or finished'), which tells the agent when the tool will not work. It does not name an alternative tool for already-sent messages, but the timing precondition is 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 the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds a genuine authorization trait not present in structured data – grant-scoped connections can only route to their own mailboxes – though it says nothing about duplicate-alias conflicts, verification of destinations, or return behavior.

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 with zero filler. The core purpose and an example address are front-loaded, and the permission caveat follows where it is easy to catch before invocation.

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 three-required-parameter create tool with no output schema, the description covers purpose, scope limit and an authorization constraint. It omits error/conflict behavior and whether destinations must be pre-verified, which are minor gaps given the schema carries all field-level detail.

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 all three parameters carry their own descriptions with type, pattern and length constraints. The description's only parameter-adjacent detail, the 20-destination cap, merely restates the schema's maxItems, so it adds no meaning beyond structured fields (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 (Create) and resource (alias), and immediately disambiguates the resource by defining it as a forwarding address rather than a mailbox, which separates it from create_mailbox/create_draft siblings. It stops short of naming the sibling tools explicitly, so it is clear but not maximally differentiating.

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?

Provides real context: the alias is for forwarding and the grant-scoped restriction tells the agent when a route is valid ('may only route to their own mailboxes'). It does not explicitly say when to choose an alias over a mailbox or draft, so alternatives are left implicit.

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 openWorldHint=true. The description adds real value beyond them: the write goes to the 'live zone' (immediate effect, not a draft), the response returns the new record's id, and the call requires the dns:write scope — an auth prerequisite the annotations do not convey.

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, front-loaded sentences with zero redundancy: purpose, return value, then prerequisite. Every sentence carries distinct 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 mutation tool with no output schema, the description usefully states what is returned (the new record's id) and the required scope. It is nearly complete, though it omits error/conflict behavior (e.g. what happens if the record already exists) and propagation timing.

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%, so all six parameters are already documented in the schema, including enum values, TTL defaults, and MX/SRV priority. The description adds no parameter-level detail, 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 ('Add') and resource ('DNS record to a domain's live zone'), clearly distinguishing it from siblings like update_dns_record, delete_dns_record, and list_dns_records. An agent can identify the operation without opening the 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?

The description implies when to use it (creating a new record) but never names alternatives or states exclusions — e.g. it does not say to use update_dns_record instead when the record already exists. Usage is inferable from the verb but not explicitly guided.

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 readOnlyHint=false, so the mutation profile is covered. The description adds genuine value beyond that by disclosing the concrete post-condition: mail to the address bounces afterwards, making the consequence of destruction explicit. It omits edge behavior (unknown address, undo/recreate), 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 action and its consequence front-loaded before any elaboration. 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 one-parameter destructive operation with no output schema, the description covers the action and its irreversible effect, which is what an agent most needs. Missing only secondary details such as behavior for a missing address or whether the alias can be recreated.

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 a single required parameter whose format example ("hello@yourdomain.com") is documented in the schema. The description adds no syntax or format detail beyond that, 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 (Delete) and resource (a forwarding address), and immediately disambiguates the alias resource as the tool's target. An agent can distinguish it from create_alias, list_aliases, delete_dns_record and delete_message by the resource 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?

No when-to-use guidance, no mention of alternatives (e.g., use list_aliases to find the address, or create_alias to re-add one). The condition that selects this tool over siblings is left entirely to inference 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 flag destructiveHint=true and readOnlyHint=false, so the description is not obligated to restate that. It does add genuinely useful behavior beyond the annotations: the mailCritical refusal guard, the reason (breaking domain email), and the required auth scope.

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 with no padding: action first, then the guard/threshold, then the auth prerequisite. Every sentence 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 destructive, unannotated-output tool this covers the essentials: scope, refusal behavior, and consequence. It could mention irreversibility or what a successful delete returns, but with no output schema that omission is minor.

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 goes further by explaining the semantics of force as a confirmation for mail-critical deletion, which is the one parameter whose meaning is not obvious from the schema alone.

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 (Delete) and resource (DNS record) and scopes it to a domain's live zone, which distinguishes it from create_dns_record/update_dns_record without requiring the schema. An agent can select it immediately.

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?

Explains a key condition for use: mailCritical records are refused unless force=true, and dns:write scope is required. It does not name an alternative tool (e.g., update_dns_record) for the 'I only wanted to change it' case, but the operating context is clear.

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 readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the default is a recoverable move to Trash, and only Trash/Drafts items or an explicit permanent:true flag cause irreversible deletion.

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 action and then the default-vs-permanent distinction. No filler; every clause carries decision-relevant 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 destructive tool with no output schema, the description covers the key recoverability question (Trash vs permanent) and the trigger condition. It omits permission/auth requirements and any note that restore_message can recover the soft-deleted case, so it is slightly short of fully complete.

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 meaning by explaining how the permanent flag interacts with folder context (Trash/Drafts), which the schema's one-line 'Permanently delete instead of moving to Trash' does not convey.

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+resource ('Delete a message') and immediately clarifies the two deletion modes, which distinguishes it from siblings like move_message, empty_trash, and restore_message. It does not name those siblings explicitly, 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?

Gives an implicit condition for permanent deletion ('from Trash/Drafts or with permanent: true'), which helps an agent choose the right mode, but offers no guidance on when to use this tool versus move_message, empty_trash, or restore_message.

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 valuable behavior beyond annotations: the URL is short-lived, points at raw file content, and works without authentication until expiry. Exact TTL and error behavior remain unspecified, but the added context is strong.

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 tightly written sentences with no filler. The core action and return value are front-loaded, followed by essential behavioral context.

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?

Given a two-parameter, read-only tool with full schema documentation and no output schema, the description is complete enough. It explains how to obtain the input, what is returned, and the important auth-free, short-lived URL behavior.

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%, so both parameters are already documented. The description reinforces that fileId comes from drive_list_files but adds no meaning beyond the schema, and it does not discuss the disposition parameter, so 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: return a presigned download URL for a Drive file. It distinguishes the tool from drive_list_files by naming that sibling as the source of the file id, and the operation is clearly not a list or mutation.

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?

Provides clear context by telling the agent to get the file id from drive_list_files, implying a prerequisite workflow. It does not explicitly name alternatives or when not to use the tool, but the usage context is clear for a simple retrieval 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=true and openWorldHint=false, so the 'Read-only' sentence largely duplicates structured data. The description does add genuine behavior beyond the annotations: the deterministic sort order (folders first, then name-sorted), which an agent needs to interpret result ordering.

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 scope and ordering, then the root/folder branching, then the hand-off to the download sibling. Every sentence carries information; 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?

No output schema exists, so the description partially compensates by noting a returned file id feeds drive_download_file. Pagination defaults and max are left entirely to the schema, which is acceptable, but the return shape (what fields a file entry has) is never sketched.

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%, so parentId, limit, and offset are already documented in the schema. The description's parentId explanation ('omit for root, pass folder id to list inside') restates the schema almost verbatim and adds no new syntax or format detail; baseline 3 is correct.

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 (List) and resource (files and folders in the account's Faivelo Drive) plus the ordering rule (folders first, then name-sorted). It is clearly distinguishable from sibling list_folders (mail folders) and list_messages by naming the Drive scope.

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 explicit conditional usage: 'Omit parentId to list the root; pass a folder's id to list inside it,' and routes the agent forward by naming drive_download_file as the follow-up for a returned file id. Nothing is left 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds the non-obvious behavioral fact that the deletion is irreversible ('Cannot be undone'), which is genuinely useful context beyond the annotations, though it says nothing about permissions or side effects on the mailbox.

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 zero waste; the destructive consequence is front-loaded as the first word of the description.

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, no-output-schema tool whose annotations carry the destructive/read-only profile, the description covers what it does and that it is irreversible. It omits how the target mailbox relates to the operation and any confirmation semantics, but nothing critical 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% and the single 'mailbox' parameter is documented as 'Full mailbox address' in the schema. The description adds no meaning about which mailbox is targeted or how the Trash folder is resolved, 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?

The description states a specific verb and resource ('Permanently delete every message in the Trash folder') and makes the scope (entire Trash folder, not individual messages) unambiguous. It does not name or differentiate itself from siblings like delete_message or restore_message, so it falls 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?

It conveys the bulk scope implicitly, but gives no guidance on when to use this versus delete_message for single messages, nor any prerequisite or confirmation requirement. The agent must infer the selection criteria.

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 non-readOnly, non-destructive, non-openWorld, so the safety profile is covered. The description adds genuinely new behavior: the operation is reversible by re-invoking with the opposite value, and it acts on exactly one flag per call. It omits permission requirements and error behavior, 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?

Three sentences, front-loaded with the core action and semantics, followed by the undo rule and the two sibling escape hatches. No filler and every sentence 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 single-flag mutation with no output schema, the description covers the action, the value semantics, reversibility, and where to go instead for adjacent tasks. Nothing an agent needs in order to invoke 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%, so uid, flag, value, folder and mailbox are already documented, including the enum meaning of 'seen' vs 'flagged'. The description restates the same enum semantics (read/unread, star/unstar) without adding format, default, or addressing guidance beyond the schema. 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 (set or clear one flag on one message) plus the exact scope (single message, single flag). It further disambiguates from siblings by naming label_message and mark_all_read, so an agent can distinguish this from adjacent tools without reading 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?

Explicitly routes alternatives: free-form tags go to label_message, whole-folder read state goes to mark_all_read. It also states the reversibility condition ('calling it again with the opposite value undoes it'), leaving nothing to inference about when this tool is the right pick.

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 real behavioral value by clarifying that monthlySends is the quota send_message draws from while campaigns are metered separately, which is non-obvious accounting behavior. Permission/auth requirements remain unstated, 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?

Three tight sentences, front-loaded with what the tool returns, then the quota-model nuance, then the usage cue. Every sentence carries information; no filler or repetition 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?

With no output schema and no parameters, the description must sketch the return content, and it does so with the key fields plus quota accounting. It stops short of describing response shape or field types, but for a simple read-only summary that is a minor omission rather than a blocker.

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 there is nothing for the description to disambiguate; baseline for a no-param tool applies. The description correctly avoids inventing inputs and instead spends its words on output 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+resource and enumerates the returned content: reachable mailboxes/domains, plan tier, and monthly send quotas. It further disambiguates the two quota concepts (monthlySends vs campaignSends), which no sibling tool covers, so an agent can distinguish it immediately.

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 a clear usage context — 'useful before large sends' — which explains when the agent should call it. It does not, however, name alternatives or exclusions, e.g. how it differs from get_setup_summary or list_domains, so routing among siblings still requires 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 safety is covered. The description adds a real behavioral constraint not in structured data: the ~1.5 MB size ceiling and the fallback of webmail. Return encoding (base64) is also 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?

Two tight sentences with zero filler; the size limit and the read_message dependency are both front-loaded where an agent will see them.

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 four-parameter read tool with no output schema, the description covers purpose, prerequisite, size limit, and return format. It could note what happens when the filename doesn't match, but nothing essential 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%, so all four parameters are already documented, including filename's origin and folder's default. The description's mention of filename provenance merely echoes the schema, adding no new parameter meaning. 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 (fetch) and resource (attachment from a message) plus the output encoding (base64). It is clearly distinguishable from siblings like read_message or drive_download_file.

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 a prerequisite workflow ('use the filename from read_message's attachment metadata') and a when-not condition (files larger than ~1.5 MB must be opened in webmail). It stops short of naming an in-toolset alternative, but the routing guidance is concrete.

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 operational context beyond that: sending runs in the background at the plan's pace, and delivery states lag the send. That timing nuance is exactly the kind of thing an agent needs to avoid polling confusedly.

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, densely packed, front-loaded with the tool's output. The status list and the timing caveat both earn their place; 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 burden of describing returns and does so by enumerating the possible states and noting 'failed (with the reason)'. Combined with the lag caveat, an agent has enough to call and interpret this 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 description coverage is 100%, so both 'from' and 'batchId' are already documented in the schema. The description reinforces that batchId comes from send_batch but adds no format, syntax, or constraint detail beyond the schema — 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+resource ('The state of a batch') and explicitly ties it to the originating sibling, 'started with send_batch'. The enumeration of per-recipient outcomes makes it unmistakable against neighbours like get_delivery_status or list_scheduled.

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 'started with send_batch' and the required batchId, so an agent can infer this is a post-send poll. However, it never says when to prefer this over get_delivery_status, which is a plausible alternative for delivery tracking, nor does it note polling cadence or when the batch is finished.

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 real value beyond them by disclosing the data source ('recent Inbox and Sent messages'), which tells the agent the results are derived/limited rather than a full address book. It stops short of stating any recency window or result cap.

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 well-formed sentence with the resource and returned fields front-loaded and zero filler. Nothing is padded or 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?

With no output schema, the description usefully enumerates the returned fields and the derivation source, which is close to everything an agent needs for a one-parameter read tool. The gap is the undefined scope of 'recent' and any limit on the number of contacts 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?

Schema description coverage is 100% (one parameter, 'mailbox', documented as 'Full mailbox address'). The phrase 'this mailbox' merely confirms the parameter's role without adding format or constraint detail 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?

The description gives a specific verb+resource ('List the people this mailbox corresponds with') and even names the returned fields (name, address, message count). No sibling tool covers contacts, so differentiating it is unnecessary, but it also never states how it relates to search_messages or list_messages, which are the closest conceptual neighbors.

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 alternative tool is mentioned. The clause 'derived from recent Inbox and Sent messages' hints at the retrieval context but does not tell an agent when this is preferable to search_messages or reading a thread.

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 genuine domain context (suppressed recipients are skipped by campaigns), but it says nothing about the shape or fields of the returned status, which matters since 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 tight sentences: the core check is front-loaded and the debugging rationale follows. Every clause earns its place with no restatement of the name or schema.

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-only lookup, the description covers the check's meaning, the suppression consequence, and the agent's likely motivation. It lacks any indication of what the response contains, which is the only notable gap given no output schema exists.

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 a single well-described 'recipient' parameter, so the schema does the heavy lifting. The description adds no semantics beyond it (e.g., behavior with aliases, case sensitivity, or unknown addresses), 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 (check a recipient's delivery status) then enumerates exactly what is checked: bounce, complaint, and suppression-list state. No sibling in the list covers this capability, so an agent can route to it without ambiguity.

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 a concrete use case ('did my email to X arrive?' debugging) that tells the agent when this tool is the right call. It stops short of naming a sibling to use instead when the question is about message content rather than delivery.

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. Beyond that, the description adds real behavioral value: the output is markdown meant to be relayed verbatim, and critically it 'contains no passwords or keys', which reassures the agent about safe forwarding.

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 content is dense and front-loaded – audience, contents list, and purpose come before the delivery instruction. It is slightly long, but nearly every clause (contents enumerated, no-credentials guarantee) 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?

With no output schema, the description fully carries the burden by describing both the content of the return value and its format (markdown). Nothing an agent needs to call and use this tool 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify about inputs.

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+resource (produces a plain-language setup summary) with explicit scope: each domain's live status, mailboxes, webmail link, IMAP/SMTP settings, remaining tasks. It is clearly distinguishable from the sibling get_account_summary by its human-facing, onboarding-oriented framing.

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 clear context: 'show or send to them as-is when you finish setting something up' tells the agent the moment to invoke it. It does not explicitly contrast with get_account_summary or list_domains, 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavior: aggregation across the Sent folder for your own replies, header-based linking, and oldest-first ordering. It doesn't discuss cost or truncation on very long threads, so not 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 compact sentences; the core behavior and the follow-up instruction are both front-loaded with 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?

No output schema exists, and the description compensates by telling the agent what comes back (uids, oldest first) and what to do next (read_message for bodies). Nothing essential for correct invocation is missing for a 3-param read 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 description coverage is 100%, so uid/folder/mailbox are already documented. The description adds that the uid can be any message in the conversation, which is a mild clarification beyond the schema's 'UID of any message in the conversation'.

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 (reconstruct the whole conversation a message belongs to) plus the mechanism (Message-ID/References), which clearly separates it from list_messages/search_messages/read_message.

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 routes the agent to read_message on the returned uids for full bodies, establishing the two-step workflow. It doesn't say when to prefer this over search_messages, but the within-thread context is clear enough.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the mutation risk is known. The description adds the return behavior ('Returns every label the message carries afterwards'), which matters since there is no output schema, but omits idempotency, behaviour when removing a label that isn't present, and the 20-label cap.

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 first and the label-syntax constraint immediately after; the return-value note is a brief trailing clause. 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 mutation tool with annotations covering safety and no output schema, the description covers the action, the label format, and the return value. Minor gaps remain: the maxItems=20 limit and the default folder are only in the schema, and error behaviour on invalid or duplicate labels is unstated.

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, and the description genuinely adds value by specifying the label format (lowercase, letters/digits/dots/dashes/underscores) and giving concrete examples such as 'needs-reply' and 'invoice'. It does not restate the add/remove arrays or the folder default.

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 on a message') and clarifies that a single call can both add and remove. It does not differentiate from near-neighbour siblings like flag_message or move_message, which an agent may reasonably confuse with labelling.

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 phrase 'Useful for keeping track of what has been handled' implies a workflow context, but there is no explicit when-to-use versus flag_message/move_message, and no mention of when not to use it or prerequisites.

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 and locality profile is covered. The description adds that it returns destinations, which is useful, but says nothing about pagination, auth requirements, or result limits. With annotations carrying the operational profile, a 3 is appropriate.

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, front-loaded sentences with zero wasted words. The key information (what it lists, optional filter) is presented 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?

Given a simple read-only list operation with one optional parameter and full schema coverage, the description is mostly complete. It could mention return format or pagination, but for this complexity level it is adequate.

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 purpose ('Only aliases on this domain') is already documented. The description's 'Optionally filter by domain' adds essentially no new meaning beyond what the schema provides.

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 (List) and resource (aliases), and disambiguates the term with a parenthetical '(forwarding addresses)' and mentions destinations. Easily distinguished from siblings like list_mailboxes, list_domains, or list_dns_records.

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 usage for the filter, but the description gives no explicit when-to-use guidance or alternatives. It does not point to get_account_summary or other tools for related info, leaving usage context inferred.

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 value beyond them: the dns:read auth scope requirement and the domain-eligibility limitation. It doesn't mention pagination or rate limits, so it falls 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?

Three tightly packed sentences, front-loaded with the operation and scope, then return contents, then preconditions. Every sentence carries distinct information with 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 usefully previews return content (provider id for update/delete, mailCritical flag with examples) and states both the auth scope and the domain-eligibility constraint. An agent has everything needed to decide and call 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?

Only one parameter, and schema description coverage is 100% ('Domain name, e.g. "yourdomain.com". Must be on the account.'). The description adds nothing about the domain parameter beyond what the schema already states, 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 (list) and resource (live DNS zone records of a domain) with clear scope ('live DNS zone records of a domain on the account'). The resource is unmistakably distinct from siblings like create_dns_record, update_dns_record, and list_domains.

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 preconditions: 'Requires the dns:read scope' and 'Only works for domains with live DNS editing (Faivelo-registered or a connected registrar API key).' It stops short of naming alternatives or when-not-to-use cases, but the constraints clearly frame when the call will succeed.

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 the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds real behavioral value beyond them by disclosing that output varies by auth scope: domains:read keys get verification and mailbox/alias counts, whereas grant-scoped connections only see domains hosting their mailboxes. It stops short of describing pagination or result ordering.

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. The core action is front-loaded and the scope-conditional detail follows as qualifying context.

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 usefully previews what the response contains in each scope case (verification, mailbox/alias counts vs. just domain names). That is a strong substitute for a missing output schema; only the return shape for each scope branch could be more explicit.

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, which sets the baseline at 4. The description adds no parameter information, but there is nothing to document, and the schema is trivially complete.

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 domains this connection can see.' The scoping phrase 'this connection can see' hints at the differentiating factor versus other list_* siblings, but no sibling is named, so an agent must infer that this is the domain-level (not mailbox- or alias-level) listing.

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 rather than stated: the description explains that results depend on whether the connection holds the domains:read scope, which is useful context for interpreting output. However, it never says when to prefer this over list_mailboxes, list_aliases, or get_account_summary, and gives no explicit 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 safety is covered; the description adds value beyond that by disclosing the exact return payload (folder name, message count, unread count) and the cross-tool semantic dependency. It does not mention permissions or rate limits, keeping it out of the 5 band.

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 dense sentences with zero filler: the first defines scope and return values, the second defines how to use them. The most decision-relevant information (what is listed and its scope) is front-loaded.

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 carries the burden of describing return values, and it does so precisely (name, message count, unread count). For a single-param read tool with covering annotations, nothing an agent needs in order 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?

Only one parameter with 100% schema description coverage ('Full mailbox address'), so the schema already does the heavy lifting. The description's 'in one mailbox' reinforces the scope but adds no syntax, format, or example beyond the schema, which is the baseline expectation at full coverage.

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 folder in one mailbox') with explicit scope, and enumerates the folder kinds covered (Inbox, Sent, Drafts, Trash, Junk, custom). It also differentiates from the similarly named list_mailboxes by anchoring to 'one mailbox' and naming the returned folder set.

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 a clear reason to call it: the returned names are 'the valid values for the folder and destination parameters of the other mail tools,' which tells the agent this is a discovery/prerequisite step. It stops short of naming a specific alternative tool or a when-not condition, so it falls just under the top band.

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 structurally. The description usefully clarifies that results are scoped to what the connection can operate and include the domain, but adds nothing about ordering, pagination, or volume.

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, with the what-is-returned content front-loaded before the call-ordering advice.

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 and no parameters, the description does the necessary work by stating that each result carries its domain, and directs first-call usage. Nothing critical is missing for a zero-argument listing 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?

The schema accepts zero parameters, so per the rubric the baseline is 4. The description correctly implies no filtering input is required.

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 mailbox') and adds the result's scope ('this connection can operate, with its domain'). It is clear on its own, though it never explicitly distinguishes itself from the sibling search_all_mailboxes.

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 actionable ordering directive ('Call this first instead of guessing addresses'), which tells the agent when to invoke it. It stops short of naming the alternative search_all_mailboxes as the tool to use when you already know the address.

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 behavior beyond that: newest-first ordering, pagination, and the exact shape of returned summaries (sender, subject, date, snippet, uid, labels), which tells the agent what a result row contains.

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 compact sentences: the primary list behavior and the returned fields are front-loaded, with the draft-folder tip appended. No sentence is wasted or 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?

With no output schema, the description compensates by enumerating the returned fields, and pagination is stated in prose while its parameters are fully specified in the schema. It is close to complete; only the relationship to search tools and any result-count/paging metadata behavior are unaddressed.

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%, so every parameter is already documented, including defaults and the 1-100 limit range. The description only echoes the folder concept ("Drafts") without adding format or constraint detail 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 (List) and resource (message summaries) and enumerates the returned fields, plus ordering and pagination behavior. It does not name or contrast with the closest sibling, search_messages, so an agent must infer the list-vs-search boundary.

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?

One concrete usage hint is given (folder "Drafts" for saved drafts), but there is no guidance on when to choose this over search_messages or search_all_mailboxes, nor any stated prerequisite such as a needed mailbox argument. Usage is only implied for the common case.

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 valuable behavioral context beyond annotations: it explains what is returned (pending sends, last week's finished sends, final statuses sent/cancelled/failed and why) and that each result carries an id and draft uid. It does not mention pagination or auth requirements, but those are minor given the annotation coverage.

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 compact and front-loaded, first stating what the tool returns and then adding the practical detail about the id and draft uid. Every clause earns its place, and there is no redundant repetition of the title or schema.

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 takes responsibility for describing the return shape: pending messages, last week's finished statuses, cancellation ids, and draft uids. For a single-parameter read-only listing tool, this is complete enough for an agent to invoke and interpret results 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 description coverage is 100%, so the mailbox parameter is already fully documented by the schema. The description mentions 'from a mailbox' but adds no new syntax, format, or constraint beyond what the schema provides. Baseline 3 is appropriate when the schema carries 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?

The description clearly states the resource and scope: messages waiting to be sent later from a mailbox, plus the last week's finished ones with their final status. It also distinguishes itself from the sibling cancel_scheduled by explaining that each item has an id used for cancellation. An agent can identify this as the scheduled-sends listing tool without opening the 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?

Usage is implied: this tool is for inspecting scheduled and recently finished sends, and the id field is explicitly linked to cancel_scheduled. However, the description does not state when to prefer this over list_messages or search_messages, nor does it provide any exclusion conditions. The guidance is adequate but not 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 declare readOnlyHint=false and destructiveHint=false, so safety is partly covered. The description still adds real value beyond them: it scopes the mutation ('Only the read state changes; nothing is moved or deleted') and discloses an undo limitation not covered by annotations ('unread state is not remembered').

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 compact sentence with the scoping constraint and the alternative both front-loaded. Every clause earns its place with 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 tool with full schema coverage and annotations covering the safety profile, nothing needed to call it correctly is missing. The lack of an output schema is not a gap since the effect is fully described.

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 mailbox and folder (default 'INBOX') are already documented. The description only echoes 'one folder of a mailbox' and adds no syntax or format detail 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+resource+scope: 'Mark every message in one folder of a mailbox as read in a single call.' It distinguishes itself from the sibling flag_message by naming the single-message alternative, so the agent can tell them apart 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?

Explicitly routes the agent: use flag_message with flag 'seen' for a single message, use this for a whole folder. The when-to-use condition is stated, not 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=false and destructiveHint=false; the description reinforces and extends this by stating the action is reversible via restore_message and that the target folder is located by name rather than a fixed path. It also discloses the return value. It does not add permission/auth details, but the annotation coverage makes the bar 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?

Three short sentences, each doing distinct work: what it does, that it's reversible plus the alternative, and what it returns. Front-loaded with the action and destination, 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 3-parameter, single-message mutation with no output schema, the description covers the destination semantics, the reversibility, the routing alternative, and the return value. Nothing an agent needs to invoke 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 description coverage is 100% (uid, folder, mailbox all documented inline), so the schema carries parameter meaning. The description only implies that uid identifies a single message and adds no format, default, or validation detail beyond the schema. 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 (move), a single message as the resource, and the exact destination (Junk/Spam folder). It explicitly names the sibling tools it is not (move_message for other folders, restore_message for undo), so an agent can distinguish it 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?

Gives explicit when-to-use (any message into Junk/Spam regardless of folder naming) and a named alternative for the adjacent case ('For any other destination folder, move_message is the general move'). It also notes the undo path, covering the reverse operation.

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 and destructiveHint=false, so the agent knows this mutates state without destroying data. The description adds nothing beyond that: no reversibility note (can it be undone? does restore_message apply?), no permission/mailbox-auth requirements, no note on what happens to the source copy.

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 front-loaded and the helper-tool hint appended. 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 non-destructive mutation with no output schema and full schema coverage, the description is minimally sufficient. It omits reversibility and any post-move state expectations, which an agent would benefit from knowing.

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 telling the agent how to obtain a valid destination value. It does not clarify the optional 'folder' source parameter that defaults to INBOX, which is a minor 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 ('move a message') plus the target ('to another folder'), which is unambiguous. It does not distinguish itself from near-siblings like label_message or restore_message, but the action itself is unmistakable.

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 parenthetical '(use list_folders for valid destinations)' usefully routes the agent to a helper tool for resolving the destination value. However, it gives no guidance on when to move vs. label, copy, delete, or restore, which is the harder selection decision among 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the returned content surface (headers, both body formats, attachment metadata), which matters because 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?

Three short sentences, front-loaded with what the tool returns, then the prerequisite, then the motivating use case. Every sentence earns its place with no 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 simple read-only single-item tool with no output schema, the description covers purpose, the source of the required identifier, and the shape of the returned content. Nothing an agent needs to invoke 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 description coverage is 100%, so all three parameters are already documented in the schema, and the description only restates the uid source. It adds no new syntax or format detail for folder or mailbox, 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 (read) and resource (a single message) plus the exact scope of what is returned: headers, plain-text and HTML body, attachment metadata. This cleanly separates it from list_messages (bulk listing) and get_thread (conversation view), so an agent can disambiguate without opening a 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?

Explicitly tells the agent where the required uid comes from (list_messages) and gives a concrete use case (extracting verification codes or sign-up links). It lacks an explicit when-not-to-use or an alternative sibling for full-thread reading, but the context is clear and actionable.

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 and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context that annotations cannot: the operation fails once the message is permanently removed by empty_trash or delete_message. It does not describe auth requirements or the response, but the key constraint is 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?

Two sentences, zero waste, with the core action front-loaded and the durability caveat placed 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 4-parameter mutation with full schema coverage and a clear safety annotation profile, the description supplies the one non-obvious constraint (message must still exist). Return values are not described, but no output schema exists to require it; only minor gaps remain.

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%, so uid, folder, mailbox, and destination are already documented, including the Trash and INBOX defaults. The description only restates the source/target folder behavior, adding no syntax or format detail beyond the schema. 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 ('Undo a delete or a spam mark: move one message out of Trash...back to the Inbox') and clearly distinguishes itself from delete_message, empty_trash, and move_message by framing it as a reversal operation. An agent can identify the tool without opening the 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 clear context on when it applies (only while the message still exists) and the default source/target folders. It stops short of naming move_message as the alternative for non-restore moves, so it is not a full when/when-not/alternatives treatment.

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 readOnlyHint/openWorldHint annotations by disclosing the concrete call limit (up to 15 mailboxes), the traversal order (address order), what happens when that limit is exceeded (response names skipped mailboxes), and how to continue (nextOffset). These operational constraints are not derivable from the schema or 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?

Three compact sentences, each load-bearing: scope first, constraint second, pagination mechanics third. No filler or restated title text.

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 and eight loosely constrained filters, the description supplies what the structured fields cannot: the result tagging ('tagged by mailbox'), the per-call mailbox cap, the skipped-mailbox reporting, and the continuation token. An agent has everything needed to call and paginate 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 description coverage is 100%, so baseline is 3, and the description adds real value on top: it establishes the cross-parameter constraint that at least one filter is required (required parameters is 0 in the schema, so this is otherwise invisible) and explains that offset be consumed as nextOffset from the prior response.

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 with explicit scope: 'Run one search across every reachable mailbox (optionally limited to one domain)'. It also names the sibling search_messages and clarifies the distinction ('same filters', different scope), so an agent can route between them without opening 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 clear operating context: at least one filter is required, the domain parameter narrows scope, and offset should be fed from nextOffset. It implies when to prefer this over search_messages via the 'every reachable mailbox' framing, but never states an explicit exclusion or a direct 'use X instead when Y' rule.

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 two things annotations do not: the 'at least one filter required' rule (which the schema does not enforce, since only mailbox is required) and the shape of the return value (summaries with uids). It still says nothing about result limits or pagination.

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: capability and filter dimensions first, the hard constraint second, return format last. No filler 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 ten-parameter read tool with no output schema, the description covers scope, filter dimensions, the key constraint, and the return shape. It stops short of noting result limits, ordering, or how it relates to list_messages, which keeps it from being fully complete.

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%, so every one of the ten parameters is already documented in the schema. The description groups the filters (from, to, subject, body, date range, attachments), which mirrors but does not extend the schema. 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 and resource (search a mailbox folder) and enumerates the filter dimensions, plus what it returns (message summaries with uids). It implicitly scopes to one mailbox/folder, which differentiates it from the search_all_mailboxes sibling, but it never names that sibling 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?

Gives one real constraint — 'At least one filter is required' — but offers no guidance on when to use this versus list_messages or search_all_mailboxes, nor any prerequisite or exclusion. Usage context is implied 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 only flag it as a write with open-world/destructive characteristics; the description adds substantial behavior: asynchronous queueing at the plan's pace, immediate 'queued' reply plus get_batch_status polling for delivered/bounced, monthly-allowance accounting, all-or-nothing batch acceptance with a per-call cap error (batch.recipientsPerCall), and idempotencyKey making retries safe. This is exactly the kind of context annotations cannot carry.

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 routing decision and the sibling comparison, then layers token mechanics, async behavior, and caps in descending priority. Dense and long (several run-on clauses), but essentially every sentence carries distinct operational information; only minor tightening is possible.

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, so the description carries the return contract itself: immediate batch id, per-recipient 'queued' status, and the get_batch_status follow-up for terminal states. Combined with the cap/error semantics and idempotency behavior, an agent has everything needed to call and follow up on this 9-param 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 100%, so the baseline is 3, and the description still adds real meaning beyond it: how {{field}} tokens flow from subject/text/html to each recipient's fields, that a missing field renders empty (not an error), and that idempotencyKey's repeat returns the original batch. It doesn't cover from/fromName/replyTo precedence depth, but the token and idempotency semantics are genuinely additive.

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+resource+scope ('Send the same email to many recipients in ONE call') and explicitly distinguishes itself from the sibling send_message by contrasting the loop pattern. An agent can route between send_batch and send_message 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 an explicit when-to-use rule ('whenever two or more people get a similar message') and names the alternative it replaces ('instead of calling send_message in a loop'), with concrete examples (announcement, invitations, follow-up). The only missing piece is when-not, but the trigger condition is stated positively and precisely.

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, readOnlyHint=false and openWorldHint=true, so the mutation profile is covered. The description adds real value beyond them: it counts against a monthly send limit, fails when no recipient is set, and sendAt keeps the draft in Drafts until dispatch. It stops short of stating reversibility, but the destructive annotation carries that.

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, zero filler, and the core action plus its side effect (removal from Drafts) are front-loaded before the conditional sendAt behavior.

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, so return values need not be explained; the description covers the mutation, the rate-limit side effect, the failure precondition, and the scheduling variant. Nothing needed 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 description coverage is 100%, so the baseline is 3. The description goes further for sendAt by explaining the behavioral consequence (draft remains in Drafts, sent as it stands then), which the schema does not state, though it adds nothing for uid or mailbox.

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 (send) and resource (draft), plus the crucial scope detail that it sends the draft 'as it stands now (including any edits a person made to it)'. This clearly distinguishes it from update_draft (modify) and send_message (new outgoing mail).

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 clear context for use: it operates on an existing draft, fails if there is no recipient, and with sendAt it schedules rather than sends immediately. It does not explicitly name alternatives such as send_message or update_draft, but the conditions that select this tool are clear.

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 substantial context beyond the destructiveHint and openWorldHint annotations: all fields are replaced, mailCritical records are refused unless force is true, and the call can break the domain's email. It also states the required authorization scope.

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 with no wasted text. The replacement behavior, fetch-first prerequisite, mailCritical guard, and auth scope are all front-loaded and easy to scan.

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?

Complete for a destructive update tool: annotations cover safety profile, and the description supplies prerequisites, replacement semantics, authorization needs, and the mailCritical guard. No output schema exists, so return-value omission is not a meaningful 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 100%, so parameter meanings are already well documented. The description reinforces replacement semantics and explains force's mailCritical interaction, but adds little parameter-level detail beyond what the schema already provides.

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: update an existing DNS record in place. It immediately distinguishes the operation from creation or deletion and specifies replacement semantics, so an agent knows exactly what action is being taken.

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?

Provides clear prerequisites: fetch the current record with list_dns_records first, use force true for mailCritical records, and requires the dns:write scope. It does not explicitly name create_dns_record or delete_dns_record as alternatives, but the existing-record condition is clear.

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 supply the safety profile (readOnly=false, idempotent=true, destructive=false); the description adds real behavior beyond them: the change persists for 'every later send from it, in the API and in mail apps,' and clearing falls back to the domain default name or the bare address. That downstream effect is exactly what an agent needs to reason about consequences.

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, no filler, and the primary effect is front-loaded before the clearing details. Every clause carries information the agent cannot get from the structured fields alone.

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 2-parameter mutation with no output schema, the description covers effect scope, persistence, and the clearing fallback, while annotations cover idempotency and lack of destructiveness. It omits any permission/auth prerequisite, which is a minor but real gap for a write operation.

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 two parameters are already documented, making 3 the baseline. The description earns the extra point by explaining the semantics of the null/empty-string value (fallback to domain default or bare address), which the schema only summarizes as 'clears it'.

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+resource ('Set or clear the name a mailbox sends as') and immediately identifies the concrete effect ('the From display name recipients see'). No sibling tool (create_mailbox, update_draft, etc.) touches this field, so the agent can route unambiguously.

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 clear invocation context, including the trigger for the clearing path ('Pass null or "" to clear it') and what happens after clearing. It does not name a sibling or state when *not* to use it, so it falls short of the explicit routing seen at 5.

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