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

Annotations indicate destructive, non-read-only, non-idempotent behavior. The description adds valuable behavioral context: auto-detection of the Archive folder via RFC 6154 flag with fallback to common names, and that partial results report per-ID status without automatic retry. This goes beyond the annotations, though the annotations already set expectations for destructiveness.

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 concise with two sentences, no fluff. Front-loads the purpose immediately, then adds key behavioral details. Every sentence adds value.

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 the tool's complexity (archiving with folder detection, partial results, prerequisite step), the description covers all essential aspects: what it does, prerequisites, behavior on partial failures, and no need to explain return values since an output schema exists. Fully 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?

The input schema describes all three parameters (mailbox, email_ids, account_name) with 100% coverage. The description adds meaning by specifying that email_ids come from list_emails_metadata and mentioning the folder detection logic, which complements the schema. However, the schema already does most of the work.

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 core action: 'Archive one or more emails by moving them to the account's Archive folder'. It uses a specific verb and resource, and the tool name itself matches the description, distinguishing it from sibling tools like list_mailboxes and download_attachment.

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 advises to 'Use list_emails_metadata first' as a prerequisite step. It also describes the result reporting behavior for partial/ambiguous effects, implying when to check results. However, it does not explicitly state when not to use the tool or mention alternatives, but given the siblings, the context is sufficient.

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

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

The description adds significant behavioral context beyond the annotations: it discloses the deletion method ('UID EXPUNGE'), the possibility of partial or ambiguous effects, the per-ID succeeded/failed/unknown status reporting, and that operations are not retried automatically. This is exactly the kind of nuance an agent needs to handle a destructive, non-idempotent operation correctly.

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 exactly two sentences, front-loaded with the primary purpose and method, followed by a concise caveat about partial failures and non-retry. Every sentence earns its place with no redundant or filler content.

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

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

The description covers the essential context for a destructive tool: what it deletes, how it deletes (UID EXPUNGE), the prerequisite for obtaining email IDs, and the failure semantics. An output schema exists, so detailed return-value documentation is not needed. The description is complete and self-sufficient for an agent to use the tool 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 all parameters are already well-documented in the schema. The description's reference to 'email_id' aligns with the email_ids parameter, and 'Use list_emails_metadata first' matches the schema note, but it adds little new meaning beyond what the structured schema provides. Thus the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Delete one or more emails by email_id using target-scoped UID EXPUNGE.' This clearly states the operation and distinguishes it from sibling tools like move_emails and archive_emails. It also includes a prerequisite ('Use list_emails_metadata first') that reinforces the tool's specific role.

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 provides a clear usage prerequisite: 'Use list_emails_metadata first.' This tells the agent when it is appropriate to call this tool (after listing metadata). However, it does not explicitly state when not to use this tool or compare it with alternatives such as moving or archiving, which prevents a 5.

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

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

Beyond annotations (readOnly=false, destructiveHint=true), the description discloses the safe randomized naming, the default directory, the support for explicit paths, and the security-driven settings requirement. This adds meaningful behavioral context not present in the annotations alone.

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

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

Three sentences, each with a distinct purpose: what the tool does, default/explicit path behavior, and the settings requirement. No redundancy or irrelevant detail.

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

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

Covers the essential context for a download operation: the feature must be enabled, default save location, explicit path support, and source parameters. Output schema exists so return values are not needed. Lacks information about edge cases like file overwrite behavior, but is otherwise complete for an agent to proceed.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the behavior of save_path (safe randomized name, default directory) and the enable_attachment_download setting, which relates to parameter semantics even though it is not a parameter itself.

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 immediately states 'Download an email attachment' with a specific verb and resource. It clearly distinguishes this from sibling tools like get_emails_content by focusing on attachment download rather than email content retrieval.

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 on how to use the tool (default save path vs explicit path) and a prerequisite (must be enabled in settings). Does not explicitly mention alternatives or when not to use, but the context is sufficient for an agent to decide when this tool is appropriate.

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

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

The description extensively discloses behaviors beyond annotations: the IMAP-read-first atomicity guarantee (call fails before any SMTP session opens), subject derivation without stacking a second 'Fwd:' prefix, plain-text re-composition with the caller's note placed above, MIME-type-preserving attachment re-attachment, per-recipient succeeded/failed/unknown delivery reporting with separate Sent-copy outcome, and no automatic retry of ambiguous effects. Annotations only declare non-read-only/non-idempotent; the description explains what that means in practice.

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 dense (~95 words) but every sentence covers a distinct behavioral facet: failure atomicity, subject/body/attachment composition, and delivery reporting. It is front-loaded with the core purpose and contains no filler, though its length demands careful reading.

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

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

For an 8-parameter mutation tool, the description covers the critical operational concerns: when the call fails, how content is composed, attachment semantics, delivery-status reporting, and retry policy. Combined with 100% schema coverage, an output schema, and annotations, little is missing; only an explicit pointer to allowed-recipient checks or send_email routing would make it 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 genuine value: it clarifies include_attachments re-attaches with original MIME types unless false, explains the body's placement above a re-composed plain-text block, and reveals the auto-derived subject prefix that affects the delivered message. Most parameter meaning still comes from the schema, hence not a 5.

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 opening sentence states a specific verb + resource + target: 'Forward an existing message to new recipients using the specified account.' This clearly differentiates it from siblings like send_email (composing a new message) and get_emails_content (reading), and the required email_id (source UID) makes the resource unambiguous.

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

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

The description implies the use case — forwarding requires an existing source message, so an agent must first obtain an email_id — but it never explicitly contrasts this with send_email for composing new messages or names alternative tools. The distinction is inferable from the first sentence but not stated as concrete guidance.

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

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

Annotations already mark the operation as read-only, idempotent, and non-destructive; the description adds genuinely useful behavior beyond that by disclosing the embedded-resource transfer mode and the required configuration flag. It does not describe error behavior when the configuration flag is false, but this is a minor gap given the annotations.

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

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

Two short sentences front-load the core action and the key contrast, then add the prerequisite. Every sentence earns its place, and there is no filler.

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

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

For a low-complexity, read-only transfer tool, the description covers the resource type, the no-local-file behavior, and the required configuration. The main gap is the unresolved account_name meaning in the schema, but the description itself is otherwise 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?

The tool description provides no parameter-level guidance. Although schema coverage is nominally 100%, the schema's account_name description is a copy-paste error ('The email ID obtained from list_emails_metadata or get_emails_content.'), so a required parameter's meaning is not actually conveyed, and the description does not compensate.

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

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

The description opens with a specific verb ('Read') and a precise resource ('one email attachment as an MCP embedded binary resource'), so the tool's function is immediately clear. It also contrasts with writing a local file, which distinguishes it from the sibling download_attachment.

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

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

It states the key context: use this mode when the attachment content should be transferred as an embedded binary resource without creating a local file, and it gives a prerequisite (enable_attachment_content=true). It does not explicitly name download_attachment as the file-based alternative, but the contrast is strong 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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining why it is non-read-only: mark_as_read=true changes remote flags. This goes beyond the annotations and helps the agent anticipate side effects.

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 with no filler: the first states the action and scope, the second gives the prerequisite, and the third explains the key side-effect. The most important guidance is front-loaded and each 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 tool with six parameters, the input schema already documents pagination, limits, and defaults, and an output schema exists, so the description does not need to repeat those. It successfully adds the prerequisite and side-effect warning, making the definition complete for correct invocation.

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

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

Schema description coverage is 100%, and each parameter already has detailed meaning: email_ids explains its source, body_offset and max_body_length explain pagination and truncation, and mark_as_read explains failure behavior. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific action ('Get the full content') and resource ('one or more emails by their email_id'), and specifies exactly what is included: body and reply-thread headers. This clearly distinguishes the tool from list_emails_metadata and get_attachment_content without needing to inspect sibling tools.

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

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

It explicitly provides a prerequisite: 'Use list_emails_metadata first.' It also warns that the tool is not read-only and identifies the exact condition that causes mutation (mark_as_read=true). It does not explicitly name alternatives like get_attachment_content, but the stated scope is enough for most routing decisions.

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?

Beyond the annotations (readOnly=true, idempotent=true, non-destructive), the description adds the edge-case behavior 'Returns an empty list when unrestricted' and spells out which operations the allowlist constrains. This is useful behavioral context that annotations alone 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?

The description is two short sentences. The first fronts the action and resource and uses an appositive to add scope; the second handles the unrestricted case. Every word adds value, with no repetition or fluff.

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

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

For a read-only, idempotent, zero-parameter list tool with an output schema present, the description covers the resource, the governing operations, and the key empty-list edge case. There is no missing information needed for an agent to select and invoke it correctly.

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

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

With zero parameters and a schema_description_coverage of 100%, there is nothing semantic to add. The description correctly omits parameter details, so the baseline of 4 for a zero-parameter tool 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 uses a specific verb and resource ('List the configured recipient allowlist') and further explains what the allowlist governs by naming the send_email, forward_email, and save_to_mailbox operations. This unambiguously distinguishes it from the sibling list_allowed_senders.

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

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

The description gives clear context on what the tool is for: retrieving the addresses permitted as recipients for three named operations. It does not explicitly point to list_allowed_senders as the alternative, but the recipient-focused framing makes the intended use clear enough, and the zero-parameter interface removes routing ambiguity.

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, idempotentHint=true, and destructiveHint=false, and the description adds valuable context beyond that: it returns an empty list when unrestricted, and it explains the allowlist's practical effects on many sibling tools. This gives the agent a clear behavioral model without contradicting 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?

The description is slightly long due to the enumerated sibling tools, but that list is functional: it explains which tools are affected by the allowlist. The main purpose is front-loaded, and every clause contributes useful operational 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 zero-parameter, read-only, idempotent tool with an output schema, the description is complete. It explains the return value in the unrestricted case, defines the allowlist, and maps its impact onto the relevant sibling tools. There are no significant gaps an agent would need to resolve elsewhere.

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

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

With zero parameters and 100% schema coverage, the schema leaves nothing undocumented. The description appropriately does not need to explain parameters; the tool is parameterless and the action is straightforward.

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 ('List'), a precise resource ('configured inbound sender allowlist'), and differentiates from the sibling by focusing on inbound senders rather than recipients. It also clarifies the operational meaning of the allowlist, leaving no ambiguity about what the tool does.

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 clearly indicates when this tool is relevant: it controls which senders' mail is visible and eligible across the listed read and mutation tools. Though it does not explicitly say 'use this when you need to verify visibility or eligibility,' the context is strongly implied and the scope is well-defined relative to siblings like list_allowed_recipients.

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

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

The description adds meaningful behavioral context beyond the annotations: accounts are 'stable' and 'non-secret', and the tool should never trigger credential requests. It also covers the empty-result behavior, which is important for agent decision-making. This significantly exceeds what readOnlyHint and idempotentHint already 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?

The description is three concise sentences with no filler. The first sentence states the core purpose, the second gives usage rules, and the third covers fallback behavior. Every sentence contributes distinct value and the structure is 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?

For a simple zero-parameter tool with an output schema and strong annotations, this description is complete. It covers the tool's purpose, how to interpret its records, how to respond to an empty result, and what not to do. Nothing essential is missing for an agent to select and invoke the tool 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?

The tool takes zero parameters, so there is no parameter semantics to document in the description. The schema is trivially complete at 100% coverage. The description appropriately focuses on output interpretation instead of parameters, matching the baseline for a no-parameter tool.

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: 'List configured accounts'. It further characterizes them as 'stable non-secret capability records', which clarifies both the object and the nature of the returned data. This is clearly distinct from all sibling tools, which focus on recipients, senders, emails, or 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?

The description gives explicit operational guidance: use can_receive=true accounts for mail reads and can_send=true accounts for send_email and forward_email. It also provides a clear fallback instruction for empty results and explicitly forbids asking for credentials in chat. This is strong, actionable context for an agent.

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?

Beyond the readOnly/openWorld/idempotent/non-destructive annotations, the description discloses a subtle and important behavioral distinction: time filtering and ordering use provider INTERNALDATE, while the returned date is the RFC 5322 Date header. It also clearly states the tool omits body content, which is behaviorally important for agents deciding whether to call get_emails_content.

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, each earning its place: what the tool returns, the key date semantics caveat, and the integration path to get_emails_content. There is no redundant restatement of the schema or annotations.

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 tool with 18 parameters, annotations fully cover safety, an output schema exists, and all parameters are documented in the schema, the description supplies the missing qualitative context: metadata-only scope, date semantics, and the link to a sibling tool. No critical gap remains for an agent to invoke 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying the relationship between INTERNALDATE-based filtering/ordering and the RFC 5322 Date header returned in results. This helps an agent understand why date filters may not match the displayed date.

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

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

The description uses a specific verb and resource: 'List email metadata' and enumerates the exact fields returned (email_id, subject, sender, recipients, date). It also explicitly states what it does NOT return ('without body content'), immediately distinguishing it from content-fetching siblings like get_emails_content.

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

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

The description gives clear workflow context by noting 'Returns email_id for use with get_emails_content', which implies a metadata-first workflow. However, it does not explicitly state when not to use this tool or name alternatives, so it stops short of fully explicit routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds behavioral context beyond those: it explains that tags support natural-language selection and that writable is false unless explicitly enabled in account configuration. This adds useful information about configuration-dependent behavior that the annotations alone 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?

The description is two sentences with no wasted words. The core action is front-loaded, and the second sentence adds the most important behavioral nuance about writability, which is directly relevant to an agent deciding whether to call this tool or a mutating alternative.

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

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

For a read-only tool with a single documented parameter and an output schema present, the description provides sufficient context for correct invocation. It identifies the account scope, the kind of data returned, and the writability nuance, leaving no significant gap for an agent to misinterpret the 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 fully documents the single account_name parameter with 100% coverage, so the description does not need to repeat parameter details. The description adds context by indicating the tags are account-scoped, but it does not add meaningful parameter-level semantics 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?

The description uses a specific verb and resource ('List the configured semantic IMAP tags for one account'), making it immediately clear what the tool does. It is easily distinguished from sibling tools such as set_email_tags, which writes tags, and get_email_metadata, which targets email content rather than configured tags.

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 clearly indicates this is for reading configured tags for one account, implying it should be used to inspect tag configuration rather than modify it. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to select it over the write-focused sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns folder names, hierarchy delimiters, and flags, which is useful behavioral context beyond 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?

The description is two sentences long, front-loads the purpose, and contains no extraneous information. Every sentence adds value.

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 an output schema exists (implied), the description adequately covers purpose, use case, and return content. It could mention account prerequisites, but overall is sufficient for a simple 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?

Schema coverage is 100% with all parameters described. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states 'List available mailboxes/folders for an email account' with a specific verb and resource. It distinguishes itself from sibling tools (archive_emails, download_attachment) by focusing on listing rather than modifying or downloading.

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 mentions 'Useful for discovering folder names before moving emails,' providing explicit context for when to use. However, it does not explicitly state when not to use or compare to alternatives, but the purpose 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?

With annotations already indicating mutating (readOnlyHint=false), idempotent, non-destructive, and open-world behavior, the description adds valuable specifics: 'Partial or ambiguous effects report per-ID succeeded/failed/unknown status and are not retried automatically.' This goes beyond the structured annotations by explaining failure semantics and lack of auto-retry, though it does not discuss auth or rate limits.

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

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

Three sentences, front-loaded with the core action, then a useful alternative equivalence, a prerequisite, and a concise note on partial/failure behavior. Every sentence earns its place with no redundancy or filler.

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

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

The tool has a modest parameter set, clear annotations, and an output schema (signaled by 'has output schema: true'), so the description need not restate return structure. It covers the key workflow step (list first), the behavioral nuance (partial statuses, no retries), and the relationship to set_email_flags, making it sufficiently complete for an agent to invoke 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 schema already fully documents each parameter. The description adds context by saying 'by email_id' and instructing to use list_emails_metadata first, reinforcing where email_ids come from, but it does not add new semantic detail beyond the schema.

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

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

The description opens with a specific verb and resource: 'Mark one or more emails as read by email_id.' It clearly distinguishes from sibling tools by noting it is the 'common-workflow equivalent of adding \Seen with set_email_flags,' and references list_emails_metadata as a companion. This leaves no ambiguity about what the tool does.

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

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

The description gives an explicit prerequisite: 'Use list_emails_metadata first.' It also names an alternative (set_email_flags) and positions this tool as the common-workflow convenience, implying when to choose it. It lacks explicit 'when not to use' exclusions, but the 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 convey destructiveness and non-idempotency, so the bar is lower. The description adds useful context beyond annotations: partial or ambiguous effects are reported per-ID with succeeded/failed/unknown status, and operations are not retried. This gives the agent a clear picture of outcome handling.

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 two sentences long, front-loaded with the core action, and every sentence contributes value (prerequisites and outcome behavior). No redundant or extraneous content.

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?

Despite having no output schema visible, the description covers the key operational aspects: the action, the required prior calls, and how failures are reported. For a mutation tool with partial effects, this is complete and actionable.

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 does not add significant parameter-level meaning beyond what the schema already provides (e.g., IDs come from list_emails_metadata). It is adequate but not exceptional.

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 action (move) on a specific resource (emails) with a destination (between IMAP folders). This clearly distinguishes it from siblings like delete_emails, archive_emails, and set_email_flags.

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 explicitly directs users to call list_emails_metadata and list_mailboxes first, establishing clear prerequisites. However, it does not explicitly contrast with alternatives (e.g., when to delete vs. move), so it earns a 4 rather than a 5.

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

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

Annotations already carry readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context: default folder is Drafts with \Draft and \Seen flags, it requires no SMTP configuration, and an ambiguous APPEND is reported as unknown and not retried. No contradiction with 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?

Four sentence, each with a distinct purpose: core action, relationship to sibling, default behavioral details, and error handling. Information is front-loaded and no sentence is wasted.

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

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

With all parameters documented in the schema and an output schema present, the description covers the essential operational traits: defaults, SMTP independence, and ambiguous APPEND behavior. Minor omissions include folder-creation behavior and permission prerequisites, which are not addressed.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meta-level parameter semantics by noting the shared parameter set with send_email, the added mailbox/flags, and the unsupported reply_to, which helps the agent reason about parameter relationships. However, individual parameter syntax is already fully documented in the schema.

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

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

The description clearly states the tool composes an email and saves it to an IMAP folder, with a concrete example (Drafts). It distinguishes itself from send_email by noting shared parameters, added mailbox/flags, and the lack of reply_to support, so an agent can tell it apart from siblings.

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 identifies send_email as the key sibling and explains the difference: this tool adds mailbox and flags, lacks reply_to, and works purely via IMAP without SMTP. This implies the primary use case of creating drafts, but it does not explicitly state 'use when saving a draft' or provide exclusions beyond reply_to.

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

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

The description goes well beyond the annotations by disclosing critical runtime behavior: per-recipient succeeded/failed/unknown status, a separate Sent-copy outcome, and no automatic retry of ambiguous effects. It also notes reply threading support. These details are essential for correctly interpreting results and avoiding duplicate sends.

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 with the primary action in the first sentence. The second sentence is dense but packs valuable behavioral facts. Minor awkward phrasing ('reports per-recipient succeeded/failed/unknown status') prevents a perfect score.

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

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

The description covers core behavior and delivery-report semantics, but omits usage context such as account validation, allow-list restrictions, and when to prefer forward_email or save_to_mailbox. Given the tool's complexity and the presence of an output schema and detailed parameter descriptions, these gaps leave the definition only moderately 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?

The input schema provides 100% coverage with detailed descriptions for all 11 parameters, including attachment path resolution and RFC bracket behavior for message-IDs. The tool description adds no additional parameter-level information, 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?

The description clearly states the verb and resource: 'Send one email using the specified account.' It also mentions reply threading, which adds useful specificity. However, it does not explicitly distinguish this from the sibling forward_email, which also ultimately sends messages, so it falls just short of full differentiation.

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 provides no guidance on when to use send_email versus forward_email or save_to_mailbox, and does not mention prerequisites such as validating the account via list_available_accounts or checking recipient/sender allow-lists. Usage context is left entirely 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?

Beyond annotations, the description discloses unsupported flags (\Deleted, provider-specific), partial/ambiguous effects with per-ID status reporting, and no automatic retries. These are valuable behavioral traits that help the agent anticipate edge cases and errors.

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 three compact sentences: the first states the core action and scope, the second lists supported/unsupported flags, and the third covers prerequisite and failure behavior. Every sentence is informative and there is 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?

Given the output schema and annotations, the description covers essential purpose, constraints, prerequisites, and failure modes. It is complete for a mutation tool with partial effects, and it does not need to explain return values because the output schema is provided.

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 every parameter has a clear description. The tool description adds only the prerequisite to use list_emails_metadata first, which indirectly relates to email_ids, but does not significantly enrich parameter semantics beyond the schema.

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

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

The description states 'Add or remove approved IMAP flags on one or more emails by email_id' with a specific verb and resource. It lists the supported flags, clearly distinguishing it from siblings like mark_emails_as_read.

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 provides a clear prerequisite ('Use list_emails_metadata first') but does not explicitly contrast with sibling mark_emails_as_read for \Seen flag operations. Usage is implied rather than explicitly differentiated, so a model might be unsure whether to use this tool or mark_emails_as_read for read/unread.

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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds the key constraint that only configured writable semantic tags are accepted—this tells the agent that arbitrary tag names may be rejected, and that standard flags/unrelated provider keywords will not be touched. This goes beyond the schema and annotations. Known limitations like 'configured' and 'preserved' are conveyed. A 5 would require more detail about failure modes or the exact set of configured tags, but the description handles the main behavioral nuances well.

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 with no filler. The first sentence states the action and resource; the second clarifies the key constraint. The most important operational nuance—semantic tags vs. flags—is front-loaded. Every word earns its place.

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

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

The tool is a straightforward mutation with clear parameters, a complete schema, annotations covering idempotency and destructiveness, and an output schema present. The description adds the only missing piece: the semantic-tag constraint. Nothing an agent needs to call it correctly is left out, especially with 100% schema coverage and the openWorldHint annotation indicating other tags may exist but aren't enumerated.

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 parameters are already documented in the schema. The description adds the important semantic nuance that the tags array values must be 'configured writable semantic tag names' and not arbitrary strings, which is valuable context for the tags parameter. However, it doesn't explain the precise meaning of the operation enum beyond what the enum names suggest, nor does it detail the email_ids format (though the regex does). Since the schema does the heavy lifting, 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 ('Add or remove') and resource ('configured writable semantic tags on emails'), and distinguishes from standard flags ('Only semantic names are accepted; standard flags and unrelated provider keywords are preserved'). This differentiates it from the sibling set_email_flags, which likely handles standard flags. Purpose is unambiguous.

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

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

The description implies when to use this tool: for semantic tags on emails, not for standard flags or unrelated provider keywords. It explicitly excludes alternatives by saying standard flags are preserved and only configured writable semantic tags are accepted. It doesn't name sibling tools like set_email_flags or list_email_tags, but the distinction is clear enough for an agent to select this tool over flag-related siblings. A slightly higher score would require an explicit reference to a sibling.

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