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

The description goes beyond annotations by explicitly stating that the draft is not sent and that sending requires user confirmation in Outlook. Annotations only indicate readOnlyHint=false, which is vague. This behavioral detail is crucial for an agent to avoid assuming the email is sent, so the description adds meaningful value.

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 that front-load the primary action ('create a draft') and immediately clarify the non-sending behavior. Every word adds value, with no redundant phrasing.

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 tool with three clearly documented parameters and no output schema, the description covers the essential behavioral context (draft, no send). It does not mention return values or error conditions, but these are not strictly required for calling the tool correctly given the lack of an output schema. The description is sufficiently complete for 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 coverage is 100% with descriptions for all three parameters, so the schema already documents the parameters well. The description does not add any extra meaning about parameter syntax or semantics, so it stays at the baseline of 3.

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

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

The description states a specific verb ('create') and resource ('email draft'), and clarifies that it is saved to drafts and not sent. This distinguishes it from the sibling create_reply_draft, which is for replies, by emphasizing 'new email draft'. The purpose is unambiguous and well-scoped.

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 conveys the tool's use case (creating a draft) and implicitly distinguishes it from reply drafting, but it does not explicitly mention alternatives or conditions for when not to use it. It provides clear context without explicit exclusions, 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 are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false) and provide no safety details. The description adds key behaviors: it won't send, it saves to drafts, and it positions reply content above the quoted original while maintaining the thread. This goes beyond annotations and helps the agent understand 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?

Two concise sentences, front-loaded with the main action, then adds the no-send guarantee and formatting behavior. 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?

For a two-parameter tool with no output schema, the description covers the essential behaviors: generation, saving, no-send, and thread maintenance. It's complete enough for an agent to call it correctly, though it doesn't mention error handling or return values, which are not required given the 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%, with both 'id' and 'body' described. The tool description repeats the placement detail for 'body' but adds no new meaning beyond the schema. Baseline 3 is appropriate when schema fully documents parameters.

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 generates a reply draft for a specific email and saves it to drafts, with the explicit behavior of not sending. It distinguishes from generic create_draft by being specifically for replies, though it doesn't explicitly name the sibling as an alternative.

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

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

It implies usage for replying to an email and creating a draft, but doesn't explicitly provide when-to-use vs alternatives like create_draft, nor any exclusions. The context is clear but lacks 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=true and openWorldHint=true, and the description is consistent with them. It adds useful behavioral context beyond annotations: the returned content includes the body and that overly long content will be truncated. This is exactly the kind of caveat an agent needs before invoking the 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?

One compact sentence that front-loads the core action ('读取单封邮件的完整内容') and adds the key caveat in parentheses. Every element earns its place, and there is no redundant repetition of the tool name or 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 two-parameter read-only tool with strong annotations and fully documented schema, the description is sufficiently complete. It covers the main return expectation (full email content including body) and the critical truncation behavior. No output schema exists, so an agent must infer the exact return shape, but the description gives enough 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%, so the baseline is 3. The description adds value by saying '超长会截断' (long content is truncated), which gives behavioral meaning to maxBodyChars beyond its numeric min/max/default. The id parameter is already well documented in the schema as coming from list_emails or search_emails.

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 ('读取' / read) and resource ('单封邮件的完整内容' / a single email's full content), and clarifies it includes the body. This visually separates it from sibling tools like list_emails and search_emails, which are about finding or listing messages rather than retrieving one full 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 implies 'use this when you need the complete content of one email,' but it does not explicitly state when not to use it or name an alternative. The id field's schema hint ('来自 list_emails 或 search_emails') provides indirect routing, but the description itself gives no explicit when-to-use vs. alternatives 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=true and openWorldHint=true, so the safety profile is covered. The description adds the UTC timezone and default 7-day window, which is useful behavioral context, but it does not mention ordering, pagination limits beyond the schema, or any other runtime behavior.

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

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

The description is one short, front-loaded sentence that conveys the core action, timezone, and default behavior with zero wasted words. 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?

For a simple read-only list tool with optional parameters, the description plus the fully documented schema and readOnly/openWorld annotations give an agent everything needed to call it correctly. No output schema is present, but none is required to understand the basic return of calendar events.

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

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

Schema description coverage is 100%, so every parameter is already documented with type, format, and default. The description only restates the default time range concept, adding no meaningful meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool reads calendar events within a specified time period and specifies the timezone (UTC). The verb '读取' (read/list) plus the resource 'calendar events' makes the purpose obvious, and the email-focused sibling tools are clearly distinct.

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

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

The description explains the default behavior when no time parameters are passed, which gives useful context on when to call the tool. However, it does not explicitly state when to use this over siblings or provide exclusions/alternatives, so guidance is implied rather than explicit.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds the key behavioral trait of returning metadata only (no body), which is not evident from the name alone. It doesn't mention sorting or pagination, but with annotations covering safety, the added value is solid.

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, focused sentence that leads with the primary action and resource, then clarifies the return scope. No wasted words and the metadata-only constraint is front-loaded.

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

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

Since there is no output schema, the description adequately covers the return format (metadata fields). It does not specify ordering or pagination behavior, but for a list tool with an optional limit, this is acceptable. Combined with the annotations, the agent has enough to call 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?

Schema description coverage is 100%, so all three parameters (limit, folder, unreadOnly) are fully documented in the schema. The description adds no additional syntax or format details, matching the baseline of 3 when the schema carries the parameter burden.

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

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

The description clearly states the verb (list), resource (emails), scope (inbox or specified folder), and explicitly notes it returns only metadata (sender, subject, time, read status), not body. This differentiates it from get_email (full email) and search_emails (search).

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 implies usage: use this for listing recent metadata, use get_email for full content, use search_emails for complex queries. However, it does not explicitly state when not to use it or name alternatives, so it's clear context but lacks explicit exclusions.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false), is idempotent, and is not destructive. The description adds the useful detail that it can set an email to either read or unread, rather than just 'read', but it does not disclose other behavioral aspects such as whether a missing id causes an error or whether any 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 a single short sentence with no filler. It could be slightly more front-loaded by naming the tool's effect more explicitly, but it is efficient and easily parsed.

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

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

For a simple two-parameter mutation with full schema coverage and clear annotations, the description is basically sufficient. It lacks explicit notes about default behavior or error conditions, but the schema documents isRead defaults and the annotations cover safety semantics.

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

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

Schema description coverage is 100%, so both id and isRead are already documented precisely. The description adds no new parameter meaning beyond confirming the state change, but the schema carries the semantic weight.

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 ('mark') and a specific resource ('an email'), and explicitly names the two possible outcomes (read or unread). It is unambiguous and distinct from siblings like list_emails/get_email (read-only) and create_draft (composing), though it does not name them.

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 description: use this tool when the agent needs to change an email's read state. It does not explicitly say when to prefer it over alternatives or provide exclusion criteria, but the sibling set makes the use case fairly inferable.

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=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond annotations: it states the Microsoft Graph KQL query syntax and explicitly declares that only metadata is returned (no body content). These are valuable behavioral disclosures.

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

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

Two short sentences, front-loaded with the core purpose ('按关键词搜索邮件'), followed by the syntax and return-behavior caveat. Zero waste; every clause earns its place.

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

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

For a simple two-parameter read tool with annotations covering the safety profile and a fully documented schema, the description covers the essentials: search scope, query syntax, and return behavior. It lacks detail on the exact metadata fields returned, but no output schema exists and the tool's simplicity keeps this minor.

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

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

Schema coverage is 100%, so both query and limit are already documented, putting the baseline at 3. The description adds value beyond the schema by revealing the KQL syntax and the searchable fields (subject, body, sender) that constrain how query should be formed — information not present 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 names a specific verb (search) and resource (emails), and states the searchable fields (subject, body, sender). It distinguishes from siblings in spirit — get_email retrieves a single email, list_emails lists — but doesn't explicitly name the sibling it is not. Clear enough for an agent to separate it from the other tools.

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

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

The description implies usage (keyword search across subject/body/sender via Microsoft Graph KQL) but gives no explicit when-to-use vs alternatives, and no exclusions or guidance on choosing search_emails over list_emails. The context is implied, not stated.

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