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

With no annotations provided, the description carries the full behavioral burden. It discloses that cancellation sends a notice with the reason to all attendees and that organizer status is required. This adds valuable context beyond the schema, though it does not discuss reversibility or series side effects beyond what the scope parameter implies.

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 core action, the second adds behavioral detail and a constraint. Information 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 simple three-parameter tool with 100% schema coverage and no output schema, the description covers the essential purpose, behavioral outcome (cancellation notice), and the critical organizer constraint. It is complete enough 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter semantics beyond the schema, which already documents eventId, scope, and reason clearly. The description does not mention parameters explicitly, so it neither helps nor hurts.

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 ('Cancel a meeting you organized') and distinguishes it from sibling tools like delete_calendar_event by mentioning the cancellation notice sent to attendees. The verb+resource combination is specific and 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 explicitly states the key precondition 'Only works if you are the organizer,' providing clear context for when to use the tool. However, it does not name alternative tools for non-organizers or explicitly say when not to use it, so it lacks exclusions but still gives strong usage 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?

With no annotations, the description carries the full burden. It discloses the key side effect that adding attendees automatically sends meeting invitations, which is valuable. However, it does not mention other behavioral aspects such as permissions, default calendar selection, or return/output behavior, leaving room for improvement.

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 core action and immediately captures the most important caveat. Every word earns its place with no filler 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?

Given the tool's complexity (16 parameters, nested recurrence and attendee objects, no output schema), the description is minimal. It covers the primary use case and key side effect, but does not mention the default calendar, return values, or usage nuances. The rich schema compensates somewhat, but a bit more contextual guidance would improve completeness.

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 high (81%), so the baseline is 3. The description adds only the attendee invitation side effect, which is already partially present in the attendees parameter description. It does not add significant meaning 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 ('Create') and resource ('calendar event in Microsoft Outlook'), and the word 'new' distinguishes it from calendar update/cancel/delete/get siblings. It also flags the important side-effect of sending meeting invitations when attendees are added, adding clarity without ambiguity.

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

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

The description makes clear this tool is for creating new events, which is a clear context for use. However, it does not explicitly state when not to use it or mention alternatives like 'use update_calendar_event for existing events', so it 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by noting the draft is saved to the Drafts folder, and the workflow implies it does not send immediately. However, it omits details like whether the tool returns a draft ID or the exact side effects beyond saving, which leaves some ambiguity for a create operation.

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, front-loaded with the core purpose. Every word contributes: it states the action, the folder destination, and the follow-up workflow. No filler or repetition exists, making it exceptionally concise.

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 moderate complexity (7 parameters, no output schema), the description is adequate. It explains the core behavior and the follow-up workflow, which helps the agent understand the tool's role in the larger email process. It does not detail return values, but without an output schema that gap is less critical. Some edge cases (e.g., validation rules, recipient requirements) are not covered, but the description is sufficient for basic selection and 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 schema has 86% description coverage, which is high, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides, such as the required 'to', 'subject', and 'body' fields, leaving the schema to carry the parameter semantics.

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

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

The description clearly states the tool's function: 'Create a new email draft (saved to Drafts folder).' This specifies the verb (create), resource (email draft), and result (saved to Drafts folder), making it distinct from sibling tools like create_reply_draft or create_forward_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 description provides a clear workflow by stating 'Use update_draft to modify, then send_draft to send.' This indicates when to use the tool relative to its siblings, though it does not explicitly exclude alternatives like create_reply_draft or create_forward_draft, which are implied to be for different draft types.

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, the description carries the behavioral disclosure burden. It discloses important behavior: the returned draft has no To recipients, includes quoted body and 'FW:' subject. It also notes the required next steps. It stops short of discussing permissions or failure modes, but for a simple creation tool this is solid 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?

Two sentences: first states purpose, second states return characteristics and workflow. No wasted words, information is front-loaded. Every sentence contributes meaning.

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?

This is a simple tool with one parameter and no output schema. The description fully covers what the tool does, what it returns, and the subsequent steps. It is complete and self-contained within the email/draft context.

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% (messageId description: 'Message ID from get_emails or search_emails'). The description's mention of 'forward of a message' adds little beyond the schema. Since schema already explains the parameter, the baseline 3 applies.

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

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

The description clearly states the tool's action: 'Create a draft forward of a message.' It uses a specific verb and resource, and adds key details (quoted body, 'FW:' subject, no To recipients) that distinguish it from sibling draft-creation tools like create_reply_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 description provides a clear workflow: 'Use update_draft to set recipients, then send_draft to send.' This indicates when to use follow-up tools, but it doesn't explicitly differentiate when to use this tool vs. create_reply_draft or create_draft. Since the name and wording make the forward intent clear, this is strong but not fully explicit about alternatives.

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, the description carries the full burden. It discloses that the tool creates a draft (a mutation) and describes the return value in detail (recipients, quoted body, RE: subject). It does not mention permissions or failure modes, but for a draft-creation tool this is reasonably transparent and provides useful behavioral context.

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 purpose, and every piece of information earns its place. It avoids repetition and is efficient without sacrificing clarity.

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?

This is a low-complexity tool with a single parameter and no output schema. The description fully covers what the tool does, what it returns, and how to proceed (update_draft, send_draft), making it complete for its scope.

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 already provides a complete description for messageId ('Message ID from get_emails or search_emails'), covering 100% of parameters. The tool description adds no additional parameter-specific guidance, so the baseline 3 applies.

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

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

The description uses a specific verb ('Create a draft reply-all') and names the exact resource scope ('all recipients of a message'), which clearly distinguishes it from sibling tools like create_reply_draft. It also states what the returned draft contains (pre-filled recipients, quoted body, RE: subject), leaving no ambiguity about the tool's function.

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 usage context (reply-all to a message) and provides explicit next-step guidance ('Use update_draft to modify, then send_draft to send'). It does not explicitly compare with create_reply_draft or create_forward_draft, but the context is clear enough for an AI to select this tool when a reply-all draft is needed.

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, the description carries the full burden of behavioral disclosure. It reveals the return value (pre-filled recipients, quoted body, RE: subject) and implies that no sending occurs by referencing send_draft as a separate step. This is meaningful context, though it does not mention potential side effects or persistence details explicitly. The workflow hint adds 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 three sentences with no waste. It front-loads the primary action, then describes the return value, then gives the follow-up workflow. Every sentence earns its place and the structure is logical 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 tool with a single parameter and no output schema, the description is complete. It covers purpose, expected output, and subsequent steps. The sibling tool names further disambiguate the exact reply mode. No additional context is needed 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 description coverage is 100% for the single parameter (messageId), which is clearly described as coming from get_emails or search_emails. The tool description adds no extra parameter details beyond the schema, so the baseline of 3 applies – the schema does the heavy lifting and no additional semantics are 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 uses a specific verb ('Create') and resource ('a draft reply to the sender of a message'), clearly distinguishing it from sibling tools like create_reply_all_draft and create_forward_draft. It also specifies key output features (pre-filled recipients, quoted body, RE: subject), leaving no ambiguity about the tool's function.

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 clear workflow guidance: 'Use update_draft to modify, then send_draft to send.' It implicitly differentiates from create_reply_all_draft by specifying 'to the sender.' However, it does not explicitly state when NOT to use this tool versus alternatives, so it stops short of a full when/when-not contrast.

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 reveals a key trait: no notifications are sent, and it can delete events the user did not organize. However, it does not disclose reversibility, permission requirements, or behavior for series vs. single occurrences beyond what the schema already states.

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 deliver the core purpose and usage guidance without redundancy or filler. The description is front-loaded with the action and key differentiator, making it easy for an agent to parse quickly.

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 and schema cover the basics, but the presence of sibling tools like cancel_calendar_event and update_calendar_event creates ambiguity that is not resolved. The description mentions use cases but not the full decision space, leaving an agent to infer distinctions from tool names alone. No output schema reduces the need to explain returns, yet error conditions and side effects remain unaddressed.

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

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

The schema covers all parameters with clear descriptions (eventId and scope with enum values and defaults), so the description adds nothing parameter-specific beyond what the schema already provides. Schema coverage is 100%, warranting the baseline score 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 clearly states the tool removes a calendar event and uniquely specifies that it does so without sending notifications. It provides specific use cases ('remove events you did not organize, or to silently delete your own events') that add context beyond the name, though it does not explicitly distinguish from the sibling tool cancel_calendar_event.

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 direct instructions on when to use it ('Use this to remove events you did not organize, or to silently delete your own events'), implying a context where cancellation with notifications is not desired. However, it does not explicitly mention alternatives like cancel_calendar_event or state when not to use this tool, leaving the distinction 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 explicitly states that deletion does not permanently purge but 'moves to Deleted Items', which is a key behavioral nuance beyond the raw action. It does not mention permissions, error conditions, or side effects, but for a simple delete operation, this level of disclosure is valuable and largely sufficient.

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 adds a crucial qualifier. Every word earns its place; there is 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?

For a tool with one parameter and no output schema, the description provides the essential behavior (delete and move to Deleted Items). It does not explain return values or success/failure outcomes, but for a simple delete action, the description is adequately complete given the low 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?

The schema description for messageId ('Message ID') fully covers the parameter. The tool description adds no additional meaning to the parameter beyond identifying it as the message to delete. Since schema coverage is 100%, 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 states the action ('Delete a message') with a specific resource and clarifies the behavior ('moves to Deleted Items'), distinguishing it from permanent deletion and from sibling tools like move_email. The verb and object are clear and the scope is precise.

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 is implied by the name and description—use this tool to delete an email. However, there is no explicit guidance on when to use it over alternatives (e.g., move_email to Deleted Items, or update_email to change flags) and no mention of prerequisites or exclusions. The guidance is minimal but not misleading.

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 discloses important behavioral traits: the event appears as ShowAs=Free and the organizer is not notified. However, the schema description for the 'comment' parameter says the comment is included in a follow notification to the organizer, directly contradicting the claim that the organizer is not notified. This severe inconsistency undermines trust in the described behavior. Since no annotations exist, the description must be accurate, and it fails.

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 core action. It uses three short sentences that each add distinct information (action, calendar effect, non-notification, Outlook emulation). No filler. Score 5.

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

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

For a mutation tool with no annotations and no output schema, the description should cover prerequisites, result format, reversibility, and side effects. It explains the key side effects (ShowAs=Free, no notification) but omits what happens on success, whether the action can be undone, and any permission requirements. The contradiction with the comment parameter further undermines completeness.

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. However, the description of the 'comment' parameter ('Optional message included in the follow notification to the organizer') directly conflicts with the tool description's 'organizer is NOT notified'. This makes the parameter semantics confusing and misleading. The tool description itself adds no further clarification for parameters, so the score is reduced to 2.

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+resource ('Follow a calendar event') and immediately distinguishes it from formal RSVPing. It mentions key effects (ShowAs=Free, no organizer notification) and ties to a known Outlook feature, making the purpose unmistakable.

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

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

The description implies when to use it: when you want to follow an event without committing to an RSVP. It does not explicitly name sibling tools like respond_to_calendar_event but contrasts with 'formally RSVPing', which is sufficient context. No explicit exclusions are given, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the disk write and return value, which is essential, but lacks details on file naming, overwrite behavior, or error handling. This is a notable gap for a tool with a side effect.

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 primary action and a clear return statement. No filler or redundant 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 2-param tool with no output schema and no annotations, the description adequately covers the purpose and return value. It does not mention absolute vs relative path or potential file conflicts, but these are minor for a basic download tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra param semantics beyond the schema's minimal descriptions, which already indicate that attachmentId comes from get_email. The description itself does not explain 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 the specific action (download), the resource (email attachment), the target (to disk), and the return value (file path). This distinguishes it from sibling email tools, none of which handle attachment 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?

Usage is implied by the unique purpose, but there is no explicit when-to-use or alternative guidance. The schema notes that attachmentId comes from get_email, which is a useful hint, but the description itself doesn't provide prerequisites 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?

With no annotations provided, the description must carry the full behavioral burden, but it only states that events are returned within a range. It does not disclose whether recurring events are included, how timezone affects results, whether results are sorted, or any permissions/side effects. This is minimal behavioral information beyond the basic function.

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 verb, and contains no redundant information. Every word earns its place, making it highly efficient and easy to parse.

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 adequate for a simple read operation but has clear gaps. It does not explain return value structure (no output schema), lacks usage alternatives to distinguish from sibling tools, and omits edge-case behavior like timezone handling or event ordering. For a tool with four parameters and many siblings, this is minimally complete but not thorough.

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 descriptions for all four parameters, so the description need not explain them. The description only mentions startDateTime and endDateTime, but adds no extra meaning beyond what the schema already conveys. Thus, the schema does the heavy lifting and 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 clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('calendar events from Microsoft Outlook'), and explicitly scopes it to events between startDateTime and endDateTime. This distinguishes it from mutation siblings like create_calendar_event and delete_calendar_event.

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 by describing the time-based retrieval function, but it provides no explicit guidance on when to choose this tool over alternative calendar tools like get_series_master or list_series_instances. No exclusions are stated, and the broader context of sibling tools is not referenced.

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. The verb 'Read' implies a non-destructive operation, and the description discloses what is returned (full body and attachment metadata). However, it does not explicitly state lack of side effects (e.g., not marking as read) or mention authentication/rate limits, which are common for read operations.

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 conveys the essential purpose without any fluff. Every word contributes value, and it is appropriately sized for the tool's simplicity.

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 tool with two well-documented parameters, the description is complete: it states the result (full body content and attachment metadata). It does not explain error handling or return format details, but no output schema is expected, and the schema covers parameters. The context is sufficient for straightforward 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 description coverage is 100%, and the schema already documents both parameters (messageId and format) with clear descriptions. The tool description adds no additional meaning about parameter usage beyond what the schema provides, so the 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 'Read a single email' with a specific verb and resource, and further specifies what is included ('full body content and attachment metadata'). This distinguishes it from sibling tools like get_emails (plural list) and get_attachment (attachment-specific).

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 for retrieving a single email's full content, but it does not explicitly reference alternatives or state when not to use the tool. Sibling tools like get_emails and search_emails are not mentioned, so guidance relies on the name and 'single email' phrase.

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, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior (despite a pageToken parameter), default ordering, whether full email content or metadata is returned, or any rate limits. This is a significant gap for a retrieval 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, focused sentence that avoids redundancy and front-loads the core purpose. Every word contributes meaning.

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 4 optional parameters and no output schema or annotations. While the schema covers parameters, the description does not explain return value structure, pagination, or error behavior. The guidance is adequate but leaves notable gaps for a list-retrieval tool.

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

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

Schema description coverage is 100%, so the schema documents all parameters (limit, filter, folderId, pageToken). The description adds only a general notion of 'filtering' and folder scoping, which maps to existing schema descriptions. 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 verb 'Get', the resource 'emails', and the scope 'from a specific mailbox folder' with 'optional filtering'. This distinguishes it from siblings like get_email (single email) and search_emails (likely cross-folder 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?

The phrase 'from a specific mailbox folder' provides clear context for when to use this tool, implying a folder-scoped listing. However, it does not explicitly mention alternatives or exclusions, such as 'use search_emails for cross-folder search'.

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 disclosing behavior. It clearly states the operation is an 'Inspect' (read-only), and adds valuable context: returns recurrence pattern and cancelled occurrences, and automatically resolves any series event ID to the master. However, it does not explicitly state that no modifications are made or mention any permissions required, though the inspect verb strongly implies read-only.

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 extremely concise: two sentences that front-load the core purpose ('Inspect the master event of a recurring series') and then provide essential details in the second sentence. No redundant words or 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 read-only tool with two well-documented parameters and no output schema, the description adequately covers the key aspects: what the tool does, what it returns, and the flexibility of the input. It could benefit from a note about timezone handling or a mention of read-only side effects, but overall it is sufficiently complete given the simplicity of 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema: the eventId parameter description in the schema already explains that it accepts any event ID and is resolved automatically; the timezone parameter is fully described in the schema. Therefore, the description does not compensate 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 ('Inspect') and resource ('master event of a recurring series'), clearly differentiating it from sibling tools like list_series_instances or get_calendar_events. It also specifies the return payload (recurrence pattern, cancelled occurrences, full event details), leaving no ambiguity about the tool's function.

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: when you need details about the master event of a recurring series, including recurrence pattern and cancelled occurrences. It also clarifies the flexible input (any event ID from the series), but it does not explicitly contrast with alternatives like list_series_instances or mention when not to use it.

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, the description carries the full burden of disclosing behavior. It accurately describes the scoping behavior (all vs. child folders) but does not mention potential limitations like pagination, sorting, or the exact return structure. The read-only nature is implied by the word 'list' but not explicitly 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 a single, well-structured sentence that front-loads the action and resource. It contains no filler or redundant information, making it highly concise.

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 simple nature of the tool (one optional parameter, no output schema), the description sufficiently covers its core purpose and behavior. The absence of an output schema means return values are not described, but the tool name and typical usage make the return type (a list of folders) fairly obvious. Minor gaps around pagination or details of returned folder objects are acceptable for a listing 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?

The schema already provides a 100% description for the only parameter (parentFolderId), so the description adds no extra detail about the parameter itself. It only reiterates the child-folder behavior already captured in the schema, keeping the baseline score at 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 clearly states it lists all mail folders or child folders of a specific folder, using a specific verb ('list') and resource ('mail folders'). It distinguishes itself from sibling email/calendar tools by focusing solely on folder management.

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: for exploring folder hierarchies. It clearly defines two modes (top-level or child folders) but does not explicitly mention when not to use it or name alternative tools. The absence of exclusions is acceptable for a straightforward listing tool.

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

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

With no annotations provided, the description carries the full burden. It discloses a key behavior: 'Accepts any event ID from the series (resolved to master automatically).' However, it does not mention return format, error cases, or side effects (though listing implies read-only). This is partial 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 concise, using two sentences that front-load the primary action and then add a key usage detail. 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 listing tool with no output schema and no annotations, the description is adequate but leaves gaps. It explains the core purpose and the eventId resolution but does not describe what the response contains (e.g., list structure, fields) or edge cases like empty results. More detail would improve completeness.

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% description coverage for all four parameters. The tool description adds no additional parameter meaning beyond what the schema already states (e.g., eventId resolution). Baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the tool's function: 'List all occurrences of a recurring series within a date range.' It uses a specific verb ('List'), specific resource ('occurrences of a recurring series'), and the date-range scope distinguishes it from sibling tools like get_series_master or get_calendar_events.

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 clear context: use this tool to list occurrences of a recurring series within a date range, and it accepts any event ID from the series. While it doesn't explicitly name alternatives or exclusions, the purpose is clear enough to infer when to use it versus other calendar 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, the description carries the transparency burden. It discloses that the moved message is returned with a new ID, which is useful behavioral context. However, it does not mention whether the action is reversible, requires specific permissions, or what happens to the original message beyond the move. This is acceptable but not comprehensive.

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 with no redundant content. It front-loads the core action and then adds the return value detail, making it efficient and easy to parse.

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 tool with full schema coverage, the description is nearly complete. It states the action and the return value. A minor gap is lack of notes on edge cases (e.g., moving to the same folder) or permission requirements, but overall it's sufficient for an AI agent to understand the tool's behavior.

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

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

Schema coverage is 100% and both parameters have descriptions ('Message ID' and 'Destination folder ID or well-known name...'). The description adds no extra parameter semantics beyond the schema, 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 uses a specific verb ('Move') and resource ('a message') with a clear target ('to a different folder'). It distinguishes from siblings like 'update_email' (which implies modifying metadata) and 'delete_email', 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?

The description implies the tool is for moving emails to another folder, but provides no explicit when/when-not guidance or mention of alternatives. For example, it does not clarify when to prefer this over 'update_email' or 'delete_email'. The context is clear but not fully elaborated.

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 disclose behavioral traits. It mentions optional comment and alternative time proposal but omits key side effects like organizer notification (covered by 'sendResponse' in schema) and constraints on proposed times (only for tentative/decline). This lack of transparency could mislead an agent.

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 concise sentence that front-loads the action and options, with 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 has 7 parameters and no output schema, the description is brief but the schema fills in parameter details. However, it lacks outcome transparency (e.g., event status change, notification behavior) and constraints on proposed times, leaving some gaps for an agent.

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 7 parameters with 100% coverage, so the baseline is 3. The description adds minor context by mentioning comment and alternative time proposal, but doesn't elaborate 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 action ('RSVP') and the resource ('meeting invitation'), enumerating the three response types (accept, tentatively accept, decline). This distinguishes it from sibling calendar tools like create_calendar_event or update_calendar_event.

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 context—when a user needs to respond to a meeting invitation. It doesn't explicitly name alternatives, but the specificity of 'RSVP' differentiates it. No exclusions are mentioned, but the context is clear.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states that query and structured filters are mutually exclusive, which is a key constraint. It also differentiates between natural language search and structured matching, giving the agent behavioral insight. However, it does not describe return format, pagination, or read-only nature, so it's not fully comprehensive.

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, two sentences, and front-loads the core purpose. Every clause adds value, explaining the two modes and offering usage hints 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?

Given no output schema and moderate complexity with 7 parameters, the description is minimally complete but omits details like result structure, pagination, and any side effects. It covers the essential search modes but lacks context on what to expect in the response or how to handle edge cases like both query and filters being provided (which is implied to be invalid).

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 descriptions for all 7 parameters, including constraints on query exclusivity and limit defaults. The description reinforces the mutual exclusivity but adds no new information beyond the schema. With 100% schema coverage, 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 clearly states the tool searches emails and distinguishes between two modes (full-text query vs structured filters). The verb 'search' and resource 'emails' are specific, and the mention of mutually exclusive modes clarifies scope, differentiating it from simple retrieval tools like get_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 provides guidance on how to use the tool ('Use query for natural search, or structured filters for precise field matching'), but it does not explicitly state when to choose this tool over alternatives like get_emails or get_email. The usage context is implied by the search-focused wording but lacks explicit exclusions or alternative recommendations.

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, the description carries the full burden of disclosing side effects. It explicitly states 'The draft is moved from Drafts to Sent Items,' which is a clear behavioral consequence beyond a simple 'send' action. It does not mention permissions or error conditions, but for a simple mutation, the disclosed folder transition is valuable.

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, front-loaded with the primary action and immediately followed by the key behavioral outcome. Every word earns its place with no unnecessary 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?

For a simple one-parameter tool with no output schema and well-documented parameter in the schema, the description adequately covers purpose and side effect. It could mention the expected return value or success/failure behavior, but the tool is simple enough that the current description is largely 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 already provides 100% coverage for the single parameter messageId, including a descriptive explanation listing the exact draft-creating functions. The description adds no additional parameter semantics, 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 uses a specific verb and resource: 'Send a draft message,' and further clarifies the action by stating the draft is moved from Drafts to Sent Items. This clearly distinguishes it from sibling tools like send_email, which sends a composed message not necessarily a 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 description clearly indicates this tool is for sending draft messages, providing context that it should be used when a draft needs to be sent. It does not explicitly mention alternatives or exclusions, but the draft-specific language and folder behavior effectively communicate when to use it.

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 indicates the action is direct sending in one step and implies no editing before send, but it does not disclose consequences like irreversibility, permission requirements, or behavior on failure. This is a moderate 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?

Two sentences, highly concise and front-loaded. The first sentence states the purpose, the second gives an alternative. 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 tool with 8 parameters and no output schema, the description provides the essential purpose, usage, and alternative. It does not describe return values or failure modes, but given the schema's richness and the tool's simplicity, it is reasonably 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 high (88%), so the schema already explains most parameters. The description itself does not add parameter-level detail beyond implying the core fields (to, subject, body). Baseline 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states the tool composes and sends a new email in one step, with a specific verb and resource. It also distinguishes from sibling tools by contrasting with the multi-step draft flow, making its 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 tells when to use this tool (for one-step sending) and when not to, recommending the draft alternatives (create_draft + update_draft + send_draft) when more control is needed. This provides clear usage guidance and differentiation from siblings.

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

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

With no annotations provided, the description carries the full burden. It does disclose that updates are automatically sent to attendees for organizers, which is a meaningful behavioral side-effect. However, it misses other important behaviors like how recurrence changes apply only to series masters, the risk of overwriting Teams join links, or permission requirements.

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 the main purpose front-loaded and no filler. Every sentence adds value: one defines partial update scope, the other explains attendee notification 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?

This is a complex tool with 13 parameters, nested objects (recurrence), and no output schema. The description provides only minimal context and does not mention return values, special cases (e.g., recurrence only applies to master events), or the Teams join link warning that exists in the schema. It is not sufficient for an agent to fully understand the tool's behavior and prerequisites.

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 description explicitly states 'Only include fields you want to change', which clarifies that omitted parameters are preserved. This adds critical meaning beyond the schema's property definitions, especially for a tool with many optional parameters. It compensates for the moderate schema coverage (69%) by explaining the update semantics.

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

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

The description begins with 'Update an existing calendar event', which uses a specific verb and resource, clearly distinguishing it from creating, canceling, or deleting events. It also explicitly says 'existing', which differentiates it from create_calendar_event.

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 'Only include fields you want to change' gives clear guidance on partial updates, and 'If you are the organizer, updates are sent to attendees automatically' explains a key behavior. However, it does not explicitly name alternatives or scenarios where another tool should be used, though this is implied by the tool name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not reveal that recipient fields 'Replace all' recipients (as indicated in the schema), nor does it mention what happens to the draft after modification (e.g., whether it auto-saves, returns an updated draft, or requires the draft to be in a certain state). This lack of behavioral detail is a significant gap for a mutation tool with no 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, with the primary action front-loaded. The first sentence states the tool's core purpose, and the second provides usage context. Every word contributes meaning; no filler 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?

For a tool with 8 parameters, no annotations, and no output schema, the description gives a clear purpose and usage context but lacks critical behavioral details such as replacement semantics and post-modification behavior. It is not completely inadequate, but it leaves the agent to infer important execution implications from 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?

Schema description coverage is high (88%), so the schema already documents most parameters. The description groups them into categories (subject, body, recipients, importance) but does not add deeper semantics beyond that, such as the replace-all behavior for recipients. It adds marginal value, meeting 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 opens with 'Modify a draft message before sending,' which clearly states a specific verb ('modify') and resource ('draft message'). It further lists what can be changed (subject, body, recipients, importance), effectively distinguishing it from siblings like update_email or send_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 description provides explicit context by stating 'Use with create_draft, create_reply_draft, create_reply_all_draft, or create_forward_draft.' This tells the agent when this tool is appropriate (after creating a draft). It doesn't explicitly mention exclusions, but the draft-specific context and sibling names imply the boundary clearly.

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 for behavioral disclosure. It only states what can be updated ('read/unread, flag/unflag') but does not explain side effects, required permissions, whether both properties can be set in a single call, or what the response looks like. This is insufficient 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 sentence, front-loaded with the primary action 'Update email properties', followed by specific examples. There is no fluff, and every word earns its place. It is appropriately sized for the tool's simplicity.

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

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

With no annotations and no output schema, the description needs to cover more context. It omits the full flag status range, whether isRead and flagStatus can be set independently or together, and any information about the response or side effects. This leaves meaningful gaps for an agent to 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 schema has 100% coverage, so the baseline is 3. However, the description's phrase 'flag/unflag' is misleading because the schema includes a third enum value 'Complete'. This under-represents the flagStatus parameter and could cause an agent to believe only two states are possible. Thus, the description detracts from parameter clarity.

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 identifies the tool as updating email properties, specifically read/unread and flag status. It distinguishes from sibling tools like move_email and delete_email. However, it does not mention the 'Complete' flag status option, which slightly limits the clarity of the full 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?

The usage is implied by the examples: if you need to mark an email read/unread or flag/unflag, this is the tool. There is no explicit guidance on when to use this tool versus alternatives like move_email or update_draft, nor any exclusions or prerequisites. This makes it minimally adequate.

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