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

With no annotations provided, the description must convey behavioral traits on its own. It clearly discloses that the email is not sent and is instead stored in the Drafts folder. While it does not mention potential side effects (e.g., overwriting existing drafts) or required permissions, these are not critical for a draft-creation tool. The disclosure is sufficient for a simple operation, earning a 4 rather than 3.

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: the first states the core purpose, the second gives usage guidance. It is front-loaded and every word earns its place. No fluff or redundancy.

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

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

The tool is relatively simple with six well-documented parameters and no output schema. The description provides the essential purpose and usage context. It could mention what the tool returns (e.g., draft ID) but that is not crucial for the agent's selection decision. The description covers the action, location, and when to use it, making it mostly complete for this tool's complexity.

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 input schema already documents all six parameters (to, cc, bcc, body, subject, bodyType) with their types and semantics. The description adds no additional parameter details, but it also does not need to because the schema is complete. 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 clearly states the action: 'Create a draft message in the mailbox's Drafts folder without sending it.' It specifies the verb (create), the resource (draft message), the location (Drafts folder), and the key distinction from sending. This unambiguously differentiates it from its sibling send_message.

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

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

The description explicitly says 'Prefer this over send_message whenever the user should review the email first.' This directly instructs when to use this tool versus an alternative, making the usage context crystal clear.

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

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

No annotations are provided, so the description carries the burden. It states the tool fetches full content, which implies a read operation, but does not disclose any side effects, permissions, or limitations. It adds some context (what is included in the content) but lacks details like whether it marks messages as read or requires specific scopes.

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, front-loaded with the action and resource, and includes the key detail about where the ID comes from. No wasted 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?

Given the tool is simple (one parameter, no output schema, no nested objects), the description is complete enough. It explains what the tool does, what the parameter is, and how to obtain it. It could mention return format, but the absence of an output schema and the simplicity of the tool make this acceptable.

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 description coverage is 100% (the only parameter messageId is described as 'The Graph message ID.'). The description adds that the ID is 'as returned by list_messages or search_messages', which provides useful context beyond the schema. However, the schema already covers the parameter meaning, so the description adds marginal value.

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

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

The description clearly states the tool fetches full content of a single message by its Graph message ID, specifying the resource (message) and the action (fetch full content including body, recipients, sender). It also distinguishes from siblings by referencing list_messages or search_messages as sources for the ID.

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 usage: use this tool when you have a message ID from list_messages or search_messages and need full content. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to decide.

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 implicitly indicates a read-only operation via 'list', but lacks an explicit statement about no side effects or modifications. Since no annotations are provided, the description carries full burden, and this is a minor omission.

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 conveys the essential information without 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?

While the description mentions IDs and item counts, it does not specify the exact return format (e.g., array, object) or potential errors. Given the absence of an output schema, a bit more detail on the return structure would be helpful, but the current level is adequate for a simple list operation.

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

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

There are no parameters, so the description correctly omits any parameter details. The schema is empty, and no additional explanation is needed.

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 lists top-level mail folders with IDs and counts, and it distinguishes itself from sibling tools by focusing on folder enumeration rather than message operations.

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 instructs to use the returned folder ID with list_messages or search_messages, providing clear when-to-use and how to chain with other 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?

No annotations are provided, so the description carries the burden. It does not explicitly state side effects or read-only nature, though listing is implicitly non-destructive. It lacks details on error handling or edge cases.

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 concise sentences, well-structured, and free of redundant 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?

No output schema exists, so return format is not required. The description covers main behavior and parameters, though it omits details like pagination mechanics beyond the parameters, but this is sufficient given the 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?

All parameters are described in the schema, and the description adds helpful context about folder IDs and defaults, enhancing understanding 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?

Clearly states the tool lists messages from a folder, specifies default folder and ordering, and distinguishes from siblings by focusing on listing instead of searching or getting individual messages.

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 explicit guidance to use list_folders when needing a folder ID, and mentions filtering capabilities, but does not explicitly compare with search_messages or get_message for when to use them.

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

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

No annotations are provided, so the description must carry the behavioral disclosure. It adds notable behaviors: full-text scope across fields, relevance ranking, optional folder scoping. It does not mention page limits, but the top parameter is documented. The description gives enough context for a search operation without contradicting any 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 sentences, front-loaded with the core function, and no redundancy. Every clause earns its place, making it an exemplar of concise tool documentation.

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 search tool with a simple parameter set and no output schema, the description covers the main functionality, adds an explicit alternative, and clarifies optional folder scoping. It omits pagination details, but the top parameter is documented in the schema, so the description is sufficiently complete for practical use.

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 context by noting 'Optionally scope the search to one folder,' giving extra meaning to the folder parameter. It does not elaborate on top or query beyond schema, but the added folder context justifies a 4.

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 it performs full-text search across mail fields (subject, body, sender, recipients, attachments) and specifies the ranking mechanism (relevance). It also distinguishes itself from sibling list_messages by contrasting free-text search against structured filtering, making the purpose 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?

Explicitly states when to use (free-text search) and when not to (structured filtering without free-text) and names the preferred alternative (list_messages). This gives the agent clear decision-making 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?

No annotations are provided, but the description discloses that sending is immediate and non-confirmatory: 'this sends right away — there is no confirmation step.' It also implies irreversibility by advising careful consideration. It does not mention failure handling or permissions, but it covers the core behavioral trait.

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, front-loaded with the purpose, and each sentence adds value: the first states the action, the second explains the immediate nature and gives an 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 simple send action with full schema and no output schema, the description covers the purpose, usage context, and behavioral nuance. It provides sufficient context for an agent to decide when to use this tool versus create_draft.

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 parameters with 100% coverage, so the description adds no additional parameter meaning. The description doesn't mention any parameter specifics, but the schema suffices.

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 function: 'Send a new email immediately from the signed-in mailbox.' It distinguishes from sibling create_draft by referencing alternative usage, making the purpose 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?

It explicitly provides when-not to use: 'Use create_draft instead if the message should be reviewed before sending.' It also advises certainty before calling: 'only call this once you (and the user, if appropriate) are sure about the recipients and content.'

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