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

With no annotations, the description carries the full disclosure burden. It does disclose the two most important behaviors: the draft is persisted to the one.com Drafts folder and the email is not actually sent, which rules out the primary risk of accidental delivery. However, it says nothing about return values, duplicate-draft behavior on repeated calls, or authentication requirements — gaps that matter for a create operation with 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?

One 11-word sentence that front-loads the action, names the destination, and closes with the critical non-sending guarantee. There is no filler or redundancy — every element 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 description fully covers the call itself, but with no output schema an agent cannot know whether a draft identifier is returned for later reference (for example, to retrieve or delete the draft via get_email_content or delete_emails). It is adequate for a straightforward create-without-send action, yet the absent return-value guidance and lack of explicit sibling routing leave the post-creation workflow unclear.

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 of 3 applies; all five parameters (to, cc, subject, bodyText, bodyHtml) already carry descriptions in the schema. The tool description adds no parameter-specific 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 ('Create'), resource ('an email draft'), and destination ('in the one.com Drafts folder'). The clause 'without sending' directly distinguishes it from the send_email, reply_email, and forward_email siblings, so an agent can identify the tool's purpose and scope 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 'without sending' phrase implies the use case — composing an email to be stored rather than delivered — which implicitly contrasts with send_email. However, no alternative is named explicitly and no when-to-use versus when-not-to-use guidance is provided, so the routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a folder or mailbox is created; it does not mention side effects, permissions, duplicate-name behavior, reversibility, or what the API returns on success. For a mutation tool, this is a significant transparency gap.

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 a single efficient sentence with the action front-loaded. It avoids unnecessary padding, though the 'folder or mailbox' qualifier could be more precise without making the description longer.

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 only one parameter, the tool is simple, but the description leaves important context unexplained: the difference between a folder and a mailbox, behavior on duplicate names, and expected return values. There is no output schema and no annotations to fill these gaps, so the description alone is not 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%, with the 'name' parameter already documented as 'Name of the new folder or mailbox to create.' The tool description adds no meaning beyond what the schema already provides, so a 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 the action (create) and the resource (folder or mailbox) in the one.com mail account. It is distinct from sibling tools like rename_folder and delete_folder, though the 'folder or mailbox' wording introduces some ambiguity about the exact resource type.

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 intended use is implied by the verb 'Create' and the resource type, but there are no explicit conditions, prerequisites, or exclusions. Since no other sibling tool creates folders or mailboxes, the usage context is reasonably clear, but the description does not guide the agent on when to choose a folder versus a mailbox.

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 no annotations provided, the description carries the burden of behavioral disclosure. It does disclose an important behavioral trait—the default soft delete via Trash versus permanent expunging—which is meaningful for a destructive operation. However, it does not mention potential side effects, authorization requirements, or what happens to the emails after expunging.

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 a single, efficient sentence with the key behavioral distinction front-loaded. Every word earns its place, and there is 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?

For a simple delete tool with well-documented parameters, the description is mostly adequate. However, with no annotations and no output schema, it omits details about return values, error handling, or confirmation of deletion, which an agent might need for confident 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?

The input schema already describes all three parameters (uids, folder, permanent) at 100% coverage, so the baseline is 3. The description adds the 'soft delete' framing, which clarifies the default behavior, but does not meaningfully expand on parameter 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?

The description states a clear verb ('Delete'), a clear resource ('emails'), and distinguishes the two core behaviors: moving to Trash (soft delete) versus permanent expunging. It does not explicitly name or differentiate sibling tools, such as move_emails, but the deletion intent 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?

There is no guidance on when to use delete_emails versus alternatives like move_emails or mark_emails. The description implies general deletion usage but provides no context for choosing this tool, nor does it mention any caveats or 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool deletes a folder/mailbox, but it does not mention whether the deletion is permanent, whether the folder must be empty, whether its contents are also removed, or whether any confirmation or special permissions are required.

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 a single, concise sentence that front-loads the action and target resource. Every word contributes meaning, and there is 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?

For a simple one-parameter delete operation, the description plus schema is minimally viable. However, because it is a destructive action with no annotations or output schema, it would benefit from stating deletion consequences such as irreversibility or cascading removal of contained emails.

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 already fully describes the only parameter: 'Folder name to delete', so schema coverage is 100%. The description adds no parameter-specific meaning beyond what the schema provides, which is acceptable under the baseline for high schema 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?

The description states a specific verb ('Delete') and a specific resource ('folder/mailbox from the one.com mail account'), making it easy for an agent to distinguish this from sibling tools like delete_emails, create_folder, and rename_folder. It clearly identifies the operation and 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?

The description implies when to use the tool: when a folder or mailbox in the one.com mail account needs to be deleted. However, it provides no explicit context about when not to use it, such as preferring delete_emails for deleting individual messages rather than a whole folder.

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?

There are no annotations, so the description carries the full burden. It does disclose that original headers are preserved, which is meaningful forwarding behavior. However, it does not explicitly mention that the tool sends an email, what side effects occur, whether confirmation is returned, or any permission or error considerations.

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

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

A single, front-loaded sentence with no filler. It names the action, the resource, the recipient scope, and the key behavioral trait ('original headers') efficiently.

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 invocable because the purpose and all parameters are clear. However, as a side-effecting operation with no annotations and no output schema, the description is thin on expected results, sent-item behavior, and caution around actually delivering email to recipients. This is adequate but has clear gaps.

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. All four parameters are already clearly documented in the schema, and the description adds no additional parameter meaning. There is no semantic gap, but the description also provides no extra guidance 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 uses a specific verb (forward) and resource (existing email), and adds 'with original headers' to distinguish it from sending or replying. This separates it clearly from sibling tools like send_email and reply_email without needing to inspect 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 implies when to use it: whenever an existing email should be forwarded to new recipients. However, it does not explicitly say when not to use it, nor does it mention alternatives such as reply_email or send_email, so the usage guidance is largely 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a useful behavioral detail: the body is converted to clean Markdown by default to optimize token usage. However, it does not mention error behavior, handling of missing UIDs, attachments, or what parts of the email beyond the body are returned, which limits transparency.

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 only two sentences with no redundant content. The essential information ('Fetch full email content by UID from a folder') is front-loaded, followed by a concise note on the default format 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?

The tool has no output schema and no annotations, so the description needs to compensate. It covers the primary purpose and the default body format, but leaves gaps: the exact structure of the response (headers, subject, attachments) is not specified, and edge cases like missing UIDs or invalid folders are not addressed. Sufficient for simple usage but not 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 the schema already documents uid, folder, and format. The description adds value by clarifying the default format behavior ('converted to clean Markdown') and explaining the rationale ('ollimize token usage'), which gives meaning beyond the enum names. It also reinforces that the folder parameter scopes the fetch.

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 a specific verb ('Fetch'), resource ('full email content'), and key identifier ('by UID from a folder'). This distinguishes it from related siblings like search_emails and get_recent_emails by specifying the retrieval unit (a single email by UID) and scope (full 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 usage context is implied: use when you have a UID and need the full content of a specific email. However, it does not provide explicit when-to-use vs alternative guidance or mention alternatives like get_email_thread or search_emails, even though such context is available from 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?

With no annotations provided, the description carries the full burden, but 'Retrieve' conveys a read-only operation. It does not disclose details like whether the thread includes full message bodies, ordering, or whether the operation marks anything as read, which would improve transparency.

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 a single, information-dense sentence. It front-loads the main purpose and includes the key identifier needed for the operation without any 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 is simple and the schema covers both parameters, but there is no output schema and the description does not explain what a returned thread looks like, how messages are ordered, or whether the folder value is required for a successful lookup. These details would make the description more 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 the baseline is 3. The description reiterates the uidOrMessageId concept but does not add meaningful detail beyond the schema, and it does not clarify the 'folder' parameter's behavior beyond what the schema already states.

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: 'Retrieve the full conversation thread' for a given UID or Message-ID. This clearly distinguishes the tool from siblings like get_email_content or search_emails, which operate on individual emails or search results.

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: when you have a UID or Message-ID and need the entire conversation thread. However, it does not explicitly explain when to avoid this tool or name alternatives, so usage guidance is left mostly 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?

No annotations are provided, so the description carries the full burden. It clarifies the return includes envelope headers and unread status, but it does not explicitly state whether retrieving emails marks them as read or define 'most recent' ordering. This is a moderate disclosure for a read-style tool.

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 a single sentence that front-loads the action and resource, containing no filler or redundant information. It is concise and immediately scannable.

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 read tool with no output schema, the description covers the core return values (envelope headers and unread status) and the schema covers defaults. It could specify how 'most recent' is sorted, but the description is otherwise sufficient 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?

The input schema fully describes both parameters (limit default 20, folder default INBOX), so the baseline is 3. The description adds no meaningful parameter-level details beyond 'mailbox folder', matching the existing 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 a specific action ('Retrieve'), a resource ('emails from a mailbox folder'), and the output contents ('envelope headers and unread status'). This differentiates it from siblings like get_email_content (full content) and search_emails (query-based 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?

The description implies when to use the tool (when recent emails are needed) but does not explicitly name alternatives or exclusion conditions. An agent gets no guidance on choosing between this and search_emails or get_email_content beyond what is 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?

There are no annotations, so the description carries the full burden of explaining behavior. It does make the read-only nature clear and specifies that total and unread counts are included. However, it does not disclose whether hidden or system folders are included, whether the list is ordered, or what identifying information is returned for each folder.

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 a single front-loaded sentence that states the scope, the resource, and the key return data. Every word contributes information, and there is 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?

For a zero-parameter tool, the description is mostly complete: it names the resource scope and the returned counts. Since there is no output schema, it could more explicitly state that folder identifiers/names are returned, which would better support subsequent calls to sibling folder tools, but the description is still sufficient for the tool's simple purpose.

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 has zero parameters and 100% coverage, so there are no parameter details for the description to add. With no params, the description appropriately focuses on what the call returns rather than repeating schema information.

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 ('List') and a specific resource ('all mailboxes/folders in the one.com mail account'), and it adds return-value context ('total and unread message counts'). This clearly distinguishes it from sibling folder mutations like create_folder, rename_folder, and delete_folder, and from email-list operations like search_emails or get_recent_emails.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It is implicitly useful for discovering available folders before calling folder mutations, but it never says this, nor does it contrast with sibling tools such as search_emails or get_recent_emails. The usage context must be inferred 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?

There are no annotations, so the description carries the full burden of disclosing behavior. It clearly states the modifications being made and clarifies that 'flagged' means 'starred'. However, it does not mention permissions, reversibility, partial failures, or how invalid UIDs are handled, which are relevant for a mutation tool.

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 a single, front-loaded sentence that lists all supported actions with no filler or redundancy. Every word contributes to the understanding of the tool's purpose.

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 tool with fully documented parameters and an enumerated action set, the description is nearly sufficient. It lacks an explicit note about return values or when to prefer it over a sibling, but an agent can correctly determine how to invoke it from the schema and description together.

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% parameter coverage with clear descriptions for 'uids', 'action', and 'folder'. The description adds minimal extra meaning, mainly the clarification that flagged equals starred and that multiple emails can be processed at once. This matches the baseline for high schema 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?

The description uses a specific verb ('Mark') and a clear resource ('emails'), then enumerates the exact state changes: read, unread, flagged (starred), or unflagged. This makes it easy to distinguish from sibling tools like move_emails, delete_emails, or get_recent_emails.

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 explicit conditions for use or alternatives are provided. The intended use is implied by the action and resource, so an agent can infer it is for updating email read/flag state rather than searching, moving, or deleting. However, the lack of explicit when-to-use or when-not-to-use guidance keeps it below a 4.

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?

No annotations are present, so the description carries the transparency burden. It discloses the mutating move operation between folders, but it does not mention side effects such as whether the source copy is removed, permission requirements, or whether the destination folder must already exist.

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 a single, front-loaded sentence with no filler or redundancy. Every phrase contributes to understanding the tool's purpose.

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 relatively simple 3-parameter move tool with full schema coverage, the description provides enough context to understand the operation. It lacks guidance on edge cases or prerequisites, but those are not heavily demanded given the tool's simplicity.

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 documents all three parameters. The description adds a little value by clarifying that multiple emails are supported and providing destination folder examples, but it does not add substantial meaning 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 clearly states the verb and resource: move one or multiple emails between folders. It is distinct from sibling operations like delete or mark, though it does not explicitly name or contrast any sibling.

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

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

The description implies this tool is for relocating messages and gives example destination folders, but it does not provide explicit when-to-use guidance or note when alternatives like delete_emails or mark_emails would be more 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'rename' implies mutation, but the description does not state what happens to contained messages, subfolders, or mailboxes, whether the operation is reversible, or whether special permissions or naming constraints apply. The single sentence reveals only the basic action.

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 a single, efficient sentence with no filler or redundancy. It is slightly thin on behavioral context, but as a concise statement of the operation it is well structured and 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?

Given the absence of annotations and output schema, and the mutating nature of the operation, the description is under-specified. An agent is not told about side effects, constraints, or what constitutes a successful rename, so additional context would be needed for confident 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?

The input schema already documents both parameters with 100% description coverage, so the baseline is 3. The tool description adds no additional meaning about oldName/newName beyond what the schema provides, but it does not need to compensate for any schema 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?

The description uses a specific verb ('Rename') and resource ('existing mailbox/folder in the one.com mail account'), making the core purpose immediately clear. It does not explicitly contrast with the sibling create/delete/move tools, 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 gives no guidance on when to use this tool versus alternatives such as create_folder, delete_folder, or move_emails. Context such as 'when renaming an existing folder's label' is only implied; no exclusions or alternative routing is provided.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by stating that it handles In-Reply-To, References, and quoted text formatting, which are meaningful behaviors not visible in the schema. However, it does not state whether the reply is sent immediately or created as a draft, how quoted text is combined with bodyText, or what side effects occur.

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 with no filler. The main purpose is front-loaded, and the second sentence adds relevant email-specific behavior without wasting words.

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 is sufficient to understand the basic operation: reply to an email with a body and optional HTML. However, given the absence of annotations and output schema, it leaves important gaps around send-vs-draft behavior, how quoted content is formatted relative to bodyText, and what the result or failure mode looks like.

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 documents all five parameters, including defaults. The description does not add parameter-specific meaning beyond the general mention of quoted text formatting, so 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 states a specific verb and resource: 'Reply to an existing email.' It also names concrete email behaviors (In-Reply-To, References, quoted text formatting) that clarify what the tool does. It does not explicitly differentiate from siblings like send_email or forward_email, but the reply-focused wording makes the core purpose clear.

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 intended use: replying to an existing email rather than composing a new one or forwarding. However, it provides no explicit condition for when to choose this tool over send_email, forward_email, or create_draft, and gives no exclusions 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (search) but does not disclose whether the operation is read-only, how results are returned, whether the search returns full email content or just metadata, whether filters are combined with AND semantics, or any pagination/limit behavior. This is a significant gap for a tool with 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?

The description is a single concise sentence with no filler. It front-loads the core action and resource, then lists filter categories. It is appropriately sized, though a bit list-like; it could perhaps be restructured to also convey output behavior without significant length cost.

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 10 parameters, no annotations, no output schema, and no explicit return-value description, the tool is under-specified. An agent cannot know what the tool returns (message list? full content? counts?), how filters combine, whether it searches all folders by default or only INBOX (the schema does have a default for folder), or how results are ordered. The description does not compensate for the missing output schema.

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

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

The input schema has 100% parameter coverage, so the baseline is 3. The description adds a high-level grouping of filters (query, from, to, subject, date range, unread/flagged) but does not add new meaning beyond what the schema already provides for each parameter. It does not clarify parameter interactions or examples.

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 a specific verb ('Search') and resource ('emails in one.com mailbox'), and lists the available filter dimensions. It does not explicitly name or distinguish from sibling tools like get_recent_emails or get_email_content, but the search-plus-filters framing is distinct enough for an agent to infer its basic purpose.

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

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

There is no guidance on when to use this tool versus alternatives such as get_recent_emails or get_email_content. The description implies it is for filtered searches, but does not state when it should be preferred, when to avoid it, or how it relates to other email retrieval 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?

With no annotations provided, the description carries the behavioral burden. It discloses the SMTP endpoint, port, implicit TLS, and the automatic save-to-Sent behavior. It does not mention potential side effects like external delivery or irreversibility, but the core send behavior and the Sent-folder copy are clearly stated.

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, immediately front-loads the action and transport details, and includes the most important side effect in the second sentence. Every word earns its place with no fluff or repetition of schema fields.

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 send action with no output schema and no annotations, the description covers the critical operational facts: server, port, TLS, and Sent-folder persistence. It does not describe success/error returns, but the absence of an output schema and the simplicity of a fire-and-forget email send makes this a minor gap.

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

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

The input schema has 100% description coverage for all six parameters, so the schema already documents meanings. The tool description adds no parameter-specific detail beyond the general 'send outbound email' context. This matches the baseline of 3 for full schema 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?

The description states a specific action ('Send a new outbound email'), identifies the exact resource/transport ('one.com SMTP server (send.one.com:465 implicit TLS)'), and notes a behavioral side effect (saves to Sent folder). The word 'new' distinguishes it from sibling tools like reply_email, forward_email, and create_draft.

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 'new outbound email' gives clear context for when to use this tool, and the sibling list makes the contrast with reply/forward/draft tools apparent. However, it does not explicitly state 'use for new emails, not replies/forwards' or name alternatives, so it stops short of full exclusion guidance.

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