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 core behavior (move to Archive folder) but does not mention side effects, reversibility, permissions, or what happens to the message in other folders. For a mutation tool, this is a significant gap.

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

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

The description is a single concise sentence that front-loads the core action and destination. It earns its place, though it could add a brief note about optional parameters without becoming verbose.

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, no output schema, and 0% parameter coverage, the description is too thin. It does not explain the role of mailbox or include_raw, nor the result/return value, leaving an agent to guess at invocation details.

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 0%, and the description does not explain the parameters. The schema shows message_id is required and mailbox/include_raw are optional, but the description adds no meaning about what mailbox does, what include_raw controls, or how they affect archiving.

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 ('Archive') and resource ('a message'), and clarifies the action as moving it to the Archive folder. It is clear and distinguishes from siblings like delete_message and move_message, though it does not explicitly name those alternatives.

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 archiving a single message, which is distinct from batch_archive_messages and delete_message, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites (e.g., message must exist, mailbox context).

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 clearly discloses that the operation moves messages into the Archive well-known folder, a concrete and useful behavioral trait. It does not address reversibility, partial failures, permissions, return behavior, or batch limits, and no annotations compensate for these gaps.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase—'list', 'bulk move', and 'Archive well-known folder'—adds meaningful selection and invocation 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?

With no annotations, no output schema, and 0% parameter schema coverage, the short description leaves crucial context missing. An agent cannot reliably infer the role of the optional mailbox parameter, expected return values, failure behavior, or whether the operation is atomic.

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 0%, so the description must compensate, but it only maps 'list of messages' to message_ids. The optional mailbox parameter is left entirely unexplained, and the description does not clarify whether it is a source, destination, or scope parameter.

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 ('Archive') and resource ('list of messages'), and clarifies the operation as a bulk move to the Archive well-known folder. This clearly distinguishes it from singular archive_message and from generic batch_move_messages even without naming 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 words 'list' and 'bulk' imply this tool is for archiving multiple messages at once, which separates it from archive_message. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as archive_message or batch_move_messages.

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 behavioral disclosure burden. It does state the exact mutation ('set followup flag to flagged'), which is useful, but it omits other traits such as idempotence, whether prior flags are overwritten, authorization needs, and result/error 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?

One sentence that front-loads the action and adds a precise parenthetical about the flag value. Every word earns its place with no redundant 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 two-parameter flagging tool, the description is mostly sufficient: the agent knows what tool to call and what the core action does. Gaps remain around the optional mailbox parameter, batch behavior details, and return/error semantics, but these are not severe for routine 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 0%, so the description needed to compensate. It only loosely maps 'list of messages' to message_ids and says nothing about the optional mailbox parameter, its meaning, or the expected format of message IDs. Most parameter understanding is left to inference.

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

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

The description states a specific action (flag) and resource (a list of messages), and clarifies the exact flag state being set ('followup flag to flagged'). This clearly distinguishes it from single-message flag_message, unflag_message, and batch_unflag_messages.

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

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

The phrase 'a list of messages' implies this is the batch variant for flagging multiple messages, but the description never explicitly says when to prefer this over flag_message or when to avoid it. Usage context is implied rather than stated.

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

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

No annotations are provided, so the description carries the full disclosure burden. It only states the basic mutation action and does not cover partial-failure behavior, response shape, reversibility, or mailbox-scoping 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?

The description is a single, front-loaded sentence with no filler. It is appropriately concise, though brevity comes at the cost of useful detail captured in other dimensions.

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 batch operation with no output schema and no annotations, the description omits mailbox semantics, acknowledgment/return behavior, and batch edge cases. It communicates intent but not enough for an agent to call it with full confidence.

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 0%, so the description should compensate by explaining the parameters. 'A list of messages' maps reasonably to message_ids, but the mailbox parameter is entirely undocumented.

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 ('Mark'), a clear resource ('messages'), and a batch/list scope. It distinguishes itself from siblings like mark_read (single message) and batch_mark_unread (opposite direction).

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 'a list' implies a batch use case and sibling names suggest single-message alternatives, but the description does not explicitly say when to choose this tool over mark_read or when not to use it. Usage context is implied rather than stated.

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

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

No annotations are present, so the description carries the entire burden of disclosing behavior. It only states the action without mentioning side effects, permissions, or reversibility. For a batch mutation, it does not clarify whether existing read flags are overridden or simply set to unread, nor does it note any limits or consequences. This leaves the agent uninformed about the operation's impact.

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

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

The description is a single concise sentence with no unnecessary words. It front-loads the core action and meets the standard for efficiency. While it may be too brief for full clarity, it is not verbose or repetitive.

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 two parameters (one required, one optional) and no output schema, the description is insufficient for correct invocation. It does not explain the purpose of 'mailbox', any constraints on 'message_ids' (e.g., length, format), or what the tool returns or affects. The minimal description leaves significant gaps that an agent needs to fill through inference.

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 0%, and the description offers no explanation of the parameters. The schema shows a required 'message_ids' array and an optional 'mailbox', but the description does not clarify what 'mailbox' represents or how the IDs are used. The agent must work with raw schema fields without any added meaning.

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: 'Mark a list of messages as unread.' It specifies the verb (mark), resource (messages), and the word 'list' implies batch operation, distinguishing it from the singular 'mark_unread' sibling. However, it does not explicitly differentiate from other batches like 'batch_mark_read' beyond the unread direction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'mark_unread' for single messages or 'batch_mark_read' for the opposite operation. It does not mention any context, prerequisites, or conditions that should trigger this tool. The agent must infer usage solely from the name and sibling list.

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 present, the description carries the full burden, and it delivers: it discloses the pass-through behavior ('Graph resolves well-known names server-side, so we pass through without local resolution'), flags a spec deviation from Spec §6.3, cites the reference implementation, and even records the contingency for a future failure mode. This is unusually rich behavioral context for 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 front-loaded: purpose first, then destination semantics, with the spec-deviation context placed at the end. The deviation paragraph is somewhat verbose for an AI agent (the file path and contingency plan are developer-oriented), but every sentence about behavior 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?

Against a backdrop of no annotations and no output schema, the description covers purpose, destination semantics, pass-through behavior, and its relation to move_message. It does not, however, explain return behavior or partial-failure semantics for a $batch operation, which an agent would want to know for a list-based mutation.

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 0%, so the description must compensate. It thoroughly specifies the destination parameter — folder id OR the enumerated well-known names 'archive', 'inbox', 'junkemail', 'deleteditems', 'sentitems', 'drafts' — which is exactly the ambiguity the schema leaves open (no enums, no descriptions). The mailbox parameter, however, gets no semantic explanation beyond its string|null type and default.

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

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

The opening sentence 'Move a list of messages to the given folder' states a specific verb (move), resource (a list of messages), and target (folder). This cleanly distinguishes the tool from its single-message sibling move_message and from batch_archive_messages, which targets only the archive folder.

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 ties the tool's destination semantics to the existing move_message ('the well-known names that move_message already supports'), signaling behavioral consistency with that sibling. However, it never explicitly states when to choose this batch tool over move_message or batch_archive_messages — the selection criteria are only implied by the name and the phrase 'a list of messages.'

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 behavioral burden. It discloses the precise flag value set ('notFlagged'), which is useful, but it does not describe failure behavior, partial application, idempotence, or whether the operation is reversible. It is minimally adequate but not rich.

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

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

The description is a single, front-loaded sentence with no filler. The parenthetical adds the exact flag state without bloating the text, so 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 two-parameter batch tool with no output schema, the description plus input schema is mostly sufficient to invoke the tool. However, it lacks guidance about mailbox semantics and fails to differentiate when the batch variant should be chosen over the single-message sibling.

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 0%, so the description must compensate for undocumented parameters. It only maps 'a list of messages' to `message_ids` implicitly and says nothing about the `mailbox` parameter, its default, or when it should be provided.

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

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

The description states a specific action and resource: 'Unflag a list of messages', which clearly distinguishes this batch operation from the sibling `unflag_message`. The parenthetical '(set followup flag to 'notFlagged')' further clarifies the exact state change.

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 batch usage through 'a list of messages', but it does not explicitly say when to use this tool versus `unflag_message` or mention any exclusions. An agent can infer the intended context, but guidance is not 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?

With no annotations, the description must carry the behavioral disclosure burden. It does reveal an important side effect—sending a cancellation notice to attendees—which goes beyond the tool name. However, it does not say whether the event is deleted or only marked canceled, whether the action is reversible, or what authorization is required.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the primary action and the key side effect efficiently.

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

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

For a mutating calendar tool with no annotations helper and no output schema, the description is too thin. It omits parameter semantics, behavioral implications, and guidance about how this differs from delete_event. The agent cannot fully judge side effects or preconditions from the provided 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 description coverage is 0%, so the description should compensate by explaining the parameters. It only implies that event_id identifies the event to cancel; it gives no meaning for the optional 'comment' or 'mailbox' parameters. This is a substantial gap for an agent trying to use the tool correctly.

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 action ('Cancel an event') and a notable outcome ('send a cancellation notice to attendees'), so an agent can tell what the tool does. It does not explicitly distinguish this from sibling delete_event, which is likely the closest alternative, so it falls short of a 5.

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

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

The description gives no guidance on when to use cancel_event instead of delete_event, update_event, or respond_to_event. There are no stated prerequisites such as organizer permissions, calendar access, or whether the event is a single instance or a recurring series.

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 full behavioral burden. It does disclose a key safety trait ('not sent') and the return behavior ('Returns the trimmed draft'), but it omits details like whether the draft is persisted, permission requirements, or side effects on existing drafts.

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

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

The description is two sentences with no filler. The primary action is front-loaded, and the return behavior is stated concisely. 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?

Given 9 parameters, no annotations, and no output schema, this description is too sparse to fully prepare an agent. It lacks parameter guidance, usage context, and explanation of what 'trimmed' means, leaving significant gaps for a tool of this complexity.

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

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

Schema description coverage is 0%, and the description adds no information about any of the 9 parameters. It does not explain the semantics of to, subject, body, cc, bcc, body_type, attachments, mailbox, or include_raw, leaving the agent to infer everything from bare schema titles.

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

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

The description clearly states the action ('Create'), the resource ('a draft message'), and the crucial qualifier 'not sent', which distinguishes it from send_message. Adding 'Returns the trimmed draft' further clarifies the tool's output.

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 'not sent' implies this is for preparing messages without delivering them, and the sibling list includes send_message, but no explicit when-to-use or alternative guidance is given. The usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden. It discloses several behavioral nuances: attendees are 'treated as required', is_online_meeting adds a Teams link, default time_zone is UTC, and it returns a 'trimmed created event'. It does not mention side effects like automatic invitations, but for a creation tool this is reasonably transparent. The 'trimmed' wording is vague but not misleading.

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 well-structured list that is easy to scan. Each parameter is explained in one line, and the purpose is front-loaded. Despite the length, every sentence earns its place; there is no fluff. The format is optimal for an agent 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 13-parameter tool with no annotations and no output schema, the description is quite complete. It covers most parameters, defaults, and return value. The only omissions are include_raw (not mentioned) and the exact meaning of 'trimmed'. These are minor and do not prevent correct invocation. Overall, it is sufficient for an agent to call 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 0%, so the description must compensate. It explains 12 of 13 parameters (all except include_raw) with meaningful context, including datetime format, time_zone pairing, body_type options, and attendee semantics. Missing include_raw is a minor gap. Given the high number of parameters and zero schema descriptions, this is a strong compensatory effort.

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 'Create a calendar event.' which is a clear, specific verb+resource statement. It distinguishes itself from sibling tools like update_event, delete_event, cancel_event, etc., by clearly indicating creation. There is no ambiguity about what the tool does.

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

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

The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative routing. It implies creation by its name and purpose, but it lacks explicit guidance such as 'use this for new events; for existing events use update_event.' Since the sibling list includes many event tools, this is a missed opportunity.

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 behavioral burden. It states the mutating effect, parent/child placement semantics, shared-mailbox support, the include_raw option, and the return value ('trimmed new folder'). It omits error/conflict behavior and permission requirements, but for a simple create operation the disclosed behavior 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?

The description is concise, structured with Args and Returns, and front-loads the core purpose before parameter details. Every sentence earns its place 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?

With no output schema, the description appropriately states the return value. It covers all parameters and the main behavioral choices. Missing details like error handling or response field structure would be nice but are not essential for correctly invoking this straightforward create 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 0%, so the description must explain all parameters, and it does. It clarifies that display_name is required and non-empty, parent_folder_id accepts a folder id or well-known name, mailbox targets shared mailboxes, and include_raw controls the raw Graph payload. This adds real meaning beyond the bare schema types.

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

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

The description opens with a specific verb and resource: 'Create a new mail folder (top-level or child).' This clearly distinguishes it from sibling folder operations like update_folder, delete_folder, and list_folders. The scope is unambiguous.

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

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

The description gives clear in-tool usage context: parent_folder_id determines top-level vs child creation, and mailbox is for shared mailboxes. It does not explicitly name alternatives or exclusion conditions, but the purpose is clear enough that an agent knows when creation is the appropriate operation.

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 behavioral burden and does so well. It explains condition semantics, action effects (including that delete moves to Deleted Items), rule ordering via sequence, stop_processing_rules behavior, and the default for is_enabled.

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 long but well-structured with clear sections for conditions, actions, other args, and return value. Every sentence adds useful information, and the most critical constraint (condition AND action required) 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?

For a complex tool with 15 parameters, no annotations, and no output schema, the description is remarkably complete. It covers valid rule construction, parameter semantics, behavioral effects, ordering, and the return value, leaving little for an agent to infer or guess.

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?

Despite 0% schema description coverage and 15 parameters, the description explains nearly all parameters with practical examples and meanings. It even covers how to obtain a folder id via list_folders/create_folder. Only display_name is left implicit, but that is self-explanatory.

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

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

The description opens with a specific verb and resource ('Create an inbox mail rule') and is clearly distinct from sibling tools like update_rule, list_rules, and delete_rule. The purpose is unambiguous and immediately actionable.

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 essential usage constraints: at least one condition and one action are required, conditions are AND-ed, and multiple values produce OR behavior. It does not explicitly contrast with alternatives, but the create-oriented semantics and sibling set make the use case 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 must carry the behavioral transparency burden. It does disclose a meaningful behavior—no cancellation notification is sent to attendees—which goes beyond the verb 'delete.' However, it does not mention whether the deletion is permanent, whether special permissions are required, or what other side effects might 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, front-loaded sentence with zero filler. Every word contributes meaning, and the most important distinguishing behavior is placed upfront.

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 tool with no annotations and no output schema, the description provides the essential differentiator from cancel_event but omits operational details such as irreversibility, permission requirements, and return behavior. It is minimally sufficient but leaves several practical details for the agent to infer.

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 0%, so the description must compensate for the undocumented parameters. It mentions 'an event' but never explains event_id or mailbox, their formats, or their roles. Without this, the agent gains no additional parameter meaning beyond what the raw schema field names provide.

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

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

The description states a specific verb ('Delete') and resource ('an event'), plus the key qualifier 'without sending a cancellation to attendees,' which clearly differentiates it from sibling tools like cancel_event. An agent can immediately understand what this tool does and how it differs from related operations.

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

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

The phrase 'without sending a cancellation to attendees' implies that a tool exists for canceling with notifications, and it tells the agent when to choose this tool over that alternative. However, it never explicitly names cancel_event or provides explicit when-to-use/when-not-to-use guidance, leaving some inference to the agent.

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

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

With no annotations present, the description carries the full transparency burden and does so well. It discloses that the tool reads the folder first, aborts when totalItemCount or childFolderCount is greater than zero, warns about a race window, and specifies the exact return payload.

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 well-structured: an immediate purpose statement, a safety detail, a concise Args section, and a Returns section. Every sentence earns its place, and there is no redundant filler.

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

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

Given that there are no annotations and no output schema, the description is remarkably complete. It explains both parameters, the exact return shape, the safety preconditions, and the failure mode, so an agent can call the tool with clear expectations.

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 itself has 0% description coverage, so the Args section in the description is essential. It adds useful meaning beyond the raw schema by explaining that folder_id is a Graph folder id and that mailbox is optional, for shared mailboxes, and can be an email or user id.

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

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

The description opens with a specific verb and resource: 'Delete a mail folder.' The follow-up about refusing non-empty folders clarifies the tool's scope and behavior, making it easy to distinguish from sibling tools like delete_message or delete_rule.

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

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

The description gives clear context for when the tool applies and explicitly states a key precondition/refusal condition: non-empty folders will not be deleted. It does not explicitly name alternatives, but the resource-specific wording and the empty-folder requirement provide sufficient 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It does this well by clarifying that the operation is non-destructive and specifying the destination folder. It stops short of mentioning permissions, recoverability, or side effects, but the core behavioral trait is clearly communicated.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the operation and its most important behavioral nuance in just nine 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 simple two-parameter delete operation, the description conveys the essential behavior and outcome. However, it lacks explicit guidance on the optional mailbox parameter and does not state what happens if the message is already in Deleted Items or does not exist, leaving some ambiguity for the 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?

Schema description coverage is 0%, so the description needed to compensate by explaining how message_id and mailbox are used. It does not mention either parameter, leaving the agent to infer from the schema property titles alone. The only implicit link is the word 'message', which suggests message_id identifies the target.

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

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

The description states a specific action ('Soft-delete') and resource ('a message'), and adds a concrete behavioral detail: it moves the message to Deleted Items. This clearly distinguishes it from sibling tools like archive_message or move_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 'soft-delete' phrasing implies the appropriate use case: removing a message while retaining it in Deleted Items rather than permanently deleting it. However, it does not explicitly describe when to prefer this over sibling tools like archive_message or move_message.

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 the destructive nature, the optional mailbox behavior, and the exact return shape, which is useful. However, it does not mention permissions, irreversibility, error behavior, or behavior when the rule_id does not exist.

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

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

The description is tightly structured with Args and Returns sections, contains no filler, and front-loads the core action. Every line contributes either invocation semantics or return 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?

Given no annotations or output schema, the description covers the core action, both parameters, and the response format, which is solid for a simple two-parameter delete operation. It could be more complete by mentioning error cases or confirmation of irreversibility, but nothing essential for a basic correct invocation is missing.

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 0%, but the description compensates fully: rule_id is explained as a Graph rule id and marked required, and mailbox is explained as optional and used for shared mailboxes with accepted value types. This adds real meaning beyond the bare schema properties.

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

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

States a specific action ('Delete') and resource ('inbox mail rule') and identifies the id-based selection mechanism. This clearly differentiates it from siblings like delete_message, get_rule, or update_rule without requiring schema inspection.

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 the deletion intent explicit and includes the optional shared-mailbox qualifier, giving clear context for when this tool applies. It does not explicitly name alternatives or state when not to use it, but the verb and resource leave little ambiguity.

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

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

With no annotations provided, the description carries the disclosure burden and does a solid job: it explains the file-writing side effect of save_path and details the three possible return modes, including the native image block behavior. It does not mention auth, rate limits, or error cases, but the key behavioral variations are transparent.

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 well-structured with an opening summary, an Args section, and a Returns section. It is somewhat lengthy but each bullet earns its place by clarifying distinct return behavior, so there is minimal wasted text.

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 there are 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is not complete enough. It explains return shapes and save_path behavior well, but omits include_raw semantics, mailbox behavior, required identifier meaning, and any differentiation from download_hosted_content.

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 0%, so the description must compensate for all parameters. It gives useful detail only for save_path, while message_id, attachment_id, mailbox, and especially include_raw are left unexplained anywhere, leaving their semantics to inference.

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 'Download a single attachment,' which clearly identifies the verb and target resource. It is understandable on its own, though it does not explicitly differentiate itself from the sibling tool download_hosted_content.

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

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

The description explains how save_path changes the download behavior but gives no guidance about when to choose this tool over list_attachments or download_hosted_content, and offers no exclusion criteria 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 behavioral burden and does so thoroughly. It discloses three distinct return shapes, the save_path side effect (writes to disk and suppresses content payload), include_raw behavior, and the fact that content_type is sniffed and may be None. This is far beyond what an agent could infer from the schema.

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

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

The description is organized into clear, scannable sections: one-line summary, location constraint, ID sourcing, Args, and Returns. Every sentence carries useful operational information, and the most important disambiguation is front-loaded. 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?

This is a relatively complex tool with 7 parameters, no output schema, and no annotations. The description covers all parameters, all return variants, edge cases (image blocks, file saving, unknown content types), and the exact source of required IDs. Nothing needed to invoke it correctly is missing.

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 0%, but the Args section adds rich meaning to every parameter: the exclusivity constraint on chat_id/team_id/channel_id, the source of hosted_content_id, the effect of save_path (file path vs directory, return shape), and include_raw's conditional behavior. This fully compensates for the empty schema descriptions.

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

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

States a specific verb ('Download'), a precise resource ('one inline hosted-content item'), and differentiates it from sibling attachment tools by clarifying it handles hosted-content items typically referenced in message hosted_content_refs. The first sentence alone is sufficient to disambiguate it from download_attachment.

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

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

Gives explicit usage context: how to locate the message, the mutually exclusive location options (chat_id vs team_id + channel_id), and where to source message_id and hosted_content_id. It does not explicitly name when to prefer sibling download_attachment over this tool, so it falls just short of full alternative-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?

With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the tool returns suggestions with a specific structure, including suggestions and an empty_reason field, but it does not explain what 'confidence' or 'order_hint' mean, nor does it clarify whether attendee calendars are read or if this is a read-only operation. This is partial transparency but lacks important semantic detail.

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 efficient and well-structured: a one-sentence purpose followed by clearly labeled Args and Returns sections. Every line contributes necessary information for a tool with seven parameters and no schema descriptions, and the return shape is valuable because there is no output schema.

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

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

The description covers most parameters and the return structure, which is critical given the absence of schema descriptions and output schema. However, it leaves gaps: semantics of confidence/order_hint/empty_reason are undefined, mailbox and include_raw are not described, and there is no guidance on when to use this relative to sibling scheduling tools. It is usable but not fully complete.

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

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

Schema description coverage is 0%, so the description's Args section is essential. It clarifies five parameters well (e.g., attendees as email addresses, duration in whole minutes, ISO 8601 windows, max_candidates default), but it omits two schema parameters, mailbox and include_raw, leaving them unexplained. This partial coverage keeps it from being complete.

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 ('Suggest'), a clear resource ('meeting times'), and a target audience ('given attendees'), making it immediately clear what the tool does. This also distinguishes it from sibling calendar tools like list_events or create_event, which focus on retrieving or creating actual events rather than suggesting availability.

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 a scheduling use case and specifies the required inputs, but it does not explicitly say when to use this tool versus alternatives such as create_event or list_calendars. It provides context but no exclusions or comparative guidance, so an agent must infer the appropriate scenario.

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 full responsibility for behavioral disclosure. It only says 'set the follow-up flag,' implying mutation, but does not disclose whether the flag is idempotent, reversible, requires permissions, or what the response looks like. This is a significant gap for a mutating 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 a single short sentence with no extraneous words. It is appropriately concise and front-loaded with the core action.

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 three parameters, zero schema coverage, no annotations, and no output schema, the description is critically incomplete. It omits parameter semantics, behavioral details, and any guidance on integration with sibling operations, leaving the agent to guess.

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 0%, so the description must explain parameters, but it does not. The parameters mailbox, message_id, and include_raw are not described beyond their schema names/types. The agent has no additional meaning to decide how to fill them.

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 and resource: 'Set the follow-up flag on a message.' It distinguishes the core action but does not mention any sibling tools like unflag_message or batch_flag_messages, so it lacks differentiation. Still, the purpose is unambiguous.

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

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

No guidance on when to use this tool versus alternatives such as unflag_message or batch_flag_messages. No mention of prerequisites, context, or exclusions. The description simply states the action without usage context.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state whether forwarding sends immediately, creates a draft, preserves attachments, or requires specific permissions. The one-sentence description only names the action without operational 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 a single efficient sentence with no fluff or repetition. It is slightly under-specified, but what is present is well structured and front-loaded.

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

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

For a tool with no annotations, no output schema, and 0% schema description coverage, this description is incomplete. It leaves key behavioral details—like the effect of the optional comment and mailbox parameters, and whether forwarding includes attachments—unexplained.

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 0%, so the description must compensate, but it only maps 'new recipients' to the 'to' parameter. It adds no meaning for 'comment', 'mailbox', or 'message_id' beyond their schema titles, leaving optional parameters underspecified.

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 action and resource: 'Forward a message to new recipients.' It is specific enough to be distinguished from siblings like reply_message or send_message, though it does not explicitly name or contrast those alternatives.

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

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

No guidance is given about when to use this tool versus send_message, reply_message, or create_draft. The tool name implies forwarding, but the description does not clarify the intended scenario or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Fetch a single event by id' and doesn't disclose what happens with include_raw/include_body, whether the event is returned in a specific format, or any side effects. For a read operation this is a moderate gap, but the lack of any behavioral context beyond the basic action is notable.

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 that is front-loaded with the key action and resource. Every word earns its place; there is no fluff.

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

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

With no annotations, no output schema, and 0% schema description coverage, the description is too thin. An agent doesn't know what the response looks like, what include_raw/include_body do, or how this relates to list_events. For a tool with 4 parameters, this is incomplete.

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 0%, so the description must compensate. It mentions 'by id' which maps to event_id, but doesn't explain mailbox, include_raw, or include_body. The description adds minimal meaning beyond the schema's property names, so it doesn't fully compensate for the 0% coverage.

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

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

The description states a specific verb ('Fetch') and resource ('a single event by id'), which clearly identifies the tool's core function. It doesn't explicitly distinguish it from sibling tools like get_message or list_events, but the resource and id-based lookup are clear enough.

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

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

The description implies usage: use this when you need a single event by its ID. It doesn't explicitly state when not to use it or mention alternatives like list_events for browsing events, but the context is reasonably clear for an agent.

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

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

With no annotations, the description carries the behavioral burden. It discloses meaningful behavior: include_body=False returns a snippet, include_body=True returns full body, include_raw embeds the raw Graph payload under 'raw', and the result is a trimmed message object. It stops short of describing error behavior or what 'trimmed' means exactly.

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 one-line summary followed by a compact Args/Returns block. Each line adds information and no filler is present, and the parameter documentation is easy to scan against the schema.

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 get-by-id tool with 4 params and no output schema, the description covers the purpose, all parameters, and the return concept. The main gap is that 'trimmed message object' is vague without an output schema, and mailbox's purpose is not explained beyond 'Optional mailbox'.

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 0%, but the Args section gives each parameter real meaning: message_id is the Graph message id, mailbox is optional, include_body toggles snippet vs full body with default, and include_raw controls raw payload inclusion. This fully compensates for the bare 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?

Opens with 'Fetch a single message by id' – a specific verb, resource, and identity-based scope. This clearly distinguishes get_message from list_messages/search_messages, which are also in the sibling list.

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 right use case (you have a message_id and need one message), but it never says when to prefer this over list_messages/search_messages or sibling batch operations. No exclusions or alternative routing are provided beyond 'by id'.

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 add meaningful context: the return is a 'Trimmed rule dict' (indicating processed/truncated output) and include_raw toggles the untrimmed Graph payload. However, it omits failure behavior, permission/auth needs, and what 'trimmed' concretely removes, so the behavioral picture is partial.

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: a one-sentence purpose, then a tidy Args block, then a Returns line. Each line earns its place and provides information absent from the schema, with no filler or repetition.

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

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

The tool is simple (3 flat parameters, no output schema, no annotations), and the description covers purpose, all parameters, and the return shape. The 'Trimmed rule dict' return note is slightly vague and error behavior is unaddressed, but for a low-complexity get-by-id tool the essentials are present.

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 0%, so the description must compensate, and it does for all three parameters: rule_id is identified as a Graph rule id, mailbox gains format (email or user id) and purpose (shared mailboxes), and include_raw is explained as exposing the raw Graph payload. This adds real meaning beyond the bare schema types, names, and defaults.

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?

"Get a single inbox mail rule by id" states a specific verb, resource, and scope in one sentence. The qualifier "single ... by id" distinguishes it from the sibling list_rules and from the mutating rule tools (create_rule, update_rule, delete_rule) without needing to open any schema.

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

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

The description provides no guidance on when to choose this tool over alternatives. It never mentions that list_rules should be used to enumerate rules, that a rule_id must first be obtained elsewhere, or when the mailbox parameter is warranted. The only usage-adjacent hint is buried in the mailbox parameter description ('for shared mailboxes'), which is parameter semantics rather than tool-selection 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 usefully discloses that the tool returns metadata only and never content, but it does not explain the behavior controlled by include_raw or any side effects. This is partial disclosure, not full 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?

One sentence with a parenthetical that earns its place, front-loading the key distinction (metadata only, no content). 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 low-complexity list tool, the description covers the core scope, but it leaves gaps: include_raw is ambiguous, mailbox is unexplained, and there is no output schema or annotation context. Adequate yet incomplete.

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 0%, so the description needed to compensate, but it explains none of the three parameters explicitly. Only 'on a message' hints at message_id; mailbox and include_raw receive no semantic clarification.

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

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

The description uses a specific verb and resource: 'List attachments on a message,' and sharpened by 'metadata only — no content.' This clearly distinguishes it from content-returning siblings like download_attachment and download_hosted_content without needing to open their schemas.

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 'metadata only — no content' caveat gives clear context for when to choose this tool over alternatives, implying that content retrieval should go elsewhere. It does not explicitly name the alternative tool, but the guidance is 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states what the tool lists. It does not explain whether the mailbox parameter changes scope, whether include_raw affects output, what happens with a null mailbox, or any other behavioral details.

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 with no filler or redundant phrasing. It is efficiently front-loaded with the action and target resource, and every word contributes to 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?

For a tool with two parameters and no output schema or annotations, the description is too sparse to be fully actionable. An agent would need parameter semantics and behavioral context to invoke it confidently, especially regarding mailbox and include_raw.

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 0%, so the description must compensate, but it adds no information about the 'mailbox' or 'include_raw' parameters. Their names give hints, but the description does not clarify how to use them or what values are expected.

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 the specific verb 'List' with a clear resource, 'the user's calendars'. It distinguishes this tool from siblings like list_events because it targets calendar entities specifically, leaving no ambiguity about what it returns.

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

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

No guidance is provided about when to use this tool versus related tools such as list_events or get_event. The description gives no context for prerequisites, typical workflow, or situations where an alternative should be chosen.

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 return format, pagination via next_page_token, the effect of include_body and include_raw, the default limit, and the Graph cap of 50. It also notes that card text feeds the snippet, which is a non-obvious behavior. No contradictions with annotations (none present).

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 efficiently structured with clear Args and Returns sections. Each parameter gets a single line, and the overall text is compact yet thorough. No redundant sentences; every clause adds 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?

The tool has no output schema, but the description fully specifies the return object shape and pagination. It covers all parameters, defaults, and constraints, and even clarifies a sibling tool for replies. It is complete for an agent to call it correctly without additional lookup.

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 0%, so the description fully compensates by explaining every parameter: team_id, channel_id, limit (with range and default), page_token, include_body (with detailed effect), and include_raw. It adds constraints and context far beyond the schema's bare type definitions.

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

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

The description clearly states the tool lists root messages in a channel, newest first, and explicitly distinguishes itself from replies by noting they are fetched separately. The verb 'list' and resource 'channel messages' are specific, and the sentence 'Replies are not included here' differentiates it from sibling tools like list_message_replies.

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

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

It explicitly states when not to use it (for replies) and provides the alternative tool (list_message_replies). It also references how to obtain the channel_id (from list_channels), giving clear context on prerequisites. This meets the 'explicit when/when-not/alternatives' standard.

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 behavioral burden. It usefully discloses that limit is applied client-side and causes channels beyond the limit to be dropped, and that include_raw embeds the raw Graph payload under 'raw' on each item. It also outlines the return shape. It does not discuss authentication, rate limits, or side effects, but for a simple listing tool this is reasonably transparent.

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 and well-structured with an Args and a Returns section. It opens with a clear one-sentence purpose, then each parameter earns its place with essential details. There is no fluff or redundant repetition of schema 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?

Given no output schema, the description appropriately documents the return format with items and next_page_token. It covers all four parameters and important behavior such as client-side limits. The only minor gap is that 'trimmed_channel' is not expanded, so an agent may not know exactly which fields are present without further inference.

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

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

The input schema has 0% description coverage, so the description is the sole source of parameter meaning. It explains team_id as a Graph team id from list_joined_teams, specifies the limit range and default, clarifies that page_token is a continuation token, and defines include_raw behavior. This fully compensates for the empty schema descriptions.

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

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

The description states a specific verb and resource: 'List channels in a team.' It is clear that this tool retrieves channels for a given team and even identifies the team_id source. However, it does not explicitly differentiate itself from sibling tools such as list_channel_messages or list_joined_teams, so it stops short of full sibling-level distinction.

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 its usage by explaining that team_id comes from list_joined_teams and describes the parameters. It also indicates that limit is applied client-side and channels beyond it are dropped. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions, leaving usage context mostly 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?

With no annotations, the description carries the behavioral burden and does so well: it states newest-first ordering, page_token continuation, snippet vs full body behavior, include_raw semantics, and the exact return shape. It does not mention authorization or error behavior, but for a read-only list operation the disclosed behavior is substantial.

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 well-structured with a one-line summary, labeled Args, and a Returns section. Every line adds useful information beyond the schema, and there is no filler or repetition.

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 five-parameter tool with no output schema, the description is unusually complete: it documents all parameters, defaults, optional behaviors, and the return contract. It stops short of explaining error conditions or explicitly routing between chat and channel message tools, but nothing essential is missing for a correct call.

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 0%, so the description must fully compensate. It does: every parameter is explained with meaningful semantics—limit range/default, page_token as continuation, include_body's snippet vs card payload behavior, include_raw's 'raw' property, and chat_id provenance from list_chats.

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 'List messages in a chat, newest first,' which clearly identifies the verb, resource, and ordering. It also anchors chat_id as 'Graph chat id (from list_chats),' distinguishing this from the channel- and message-list siblings, though it never explicitly names the alternatives.

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

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

There is no explicit guidance on when to choose this tool over list_channel_messages, list_message_replies, list_messages, or search_messages. The only contextual hint is 'chat_id: Graph chat id (from list_chats),' which implies a prerequisite but does not explain selection criteria 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 carries the full burden of behavioral disclosure. It clearly explains the two timestamps and their semantics, warns against misusing metadata_updated, discloses the default ordering, and describes how members are expanded. It also states the effect of include_raw. This is exemplary transparency beyond what a schema could convey.

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

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

The description is structured with clear sections (Args, Returns) and front-loaded purpose. Every sentence adds value: the timestamp clarification and member expansion note prevent common misinterpretations. There is no filler or redundancy; it is dense yet readable.

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, the description explicitly defines the return format (items array and next_page_token). It covers all parameters, explains edge cases (1:1 chats, timestamp misuse), and discloses pagination. For a list tool with no annotations, this is a complete and self-sufficient description.

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 0%, meaning the schema offers no parameter descriptions. The description fully compensates by documenting each parameter: limit (range and default), page_token (pagination continuation), and include_raw (payload inclusion). It adds meaning beyond the schema's bare type definitions, making it highly effective.

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

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

The description states a specific verb ('List') and resource ('Teams chats') and enumerates the chat types (1:1, group, meeting). It distinguishes from siblings like list_chat_messages (messages inside a chat) and list_joined_teams (teams), leaving no ambiguity about what is returned.

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 for interpreting results (e.g., member expansion for 1:1 chats) and explains the ordering (most recent message activity first). However, it does not explicitly mention when to choose this tool over alternatives, though the sibling names make the distinction obvious. It lacks explicit 'when not to use' guidance, so a 4 is appropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains recurring-instance expansion, pagination via page_token and next_page_token, optional mailbox targeting, and the include_raw flag. It omits auth or error-behavior details, but the core behavior of a read-only list operation is transparent.

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 well-structured with a one-line summary, a behavioral note about calendarView, an Args list, and a Returns line. Every sentence carries useful information, and the most important scoping 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?

Given no annotations and no output schema, the description provides a complete operational contract: what the tool does, how parameters should be formatted, how pagination works, and what shape the return value takes. An agent has enough information to select and call this 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 0%, and the description compensates by enumerating and explaining all seven parameters: calendar_id discovery, required ISO 8601 start/end datetimes, limit range and default, page_token continuation, optional mailbox, and include_raw. It adds concrete format and constraint information well beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'List events in a calendar within a date range.' It further clarifies behavior by noting that it uses Graph's calendarView and expands recurring events into instances, making it clearly distinct from siblings like get_event, list_calendars, and create_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 clear context for when to call the tool and instructs the agent to use list_calendars to discover calendar_id. It does not explicitly exclude alternatives such as get_event for single-event lookups, but the date-range listing scope strongly implies the appropriate use case.

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 must disclose behavior itself. It reveals the return shape and notes next_page_token is None, which is useful, but it does not define 'trimmed_folder' or what changes when include_raw is set. The read-only nature is inferable from the verb 'List' rather than 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 text is appropriately short, front-loaded with the primary purpose, and the pseudo-return value is compact and structured. It wastes no words, though it could be slightly expanded with parameter clarifications without becoming bloated.

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, no-annotation tool, the description supplies the core operation and return shape but omits parameter semantics and the meaning of 'trimmed_folder.' An agent is left to guess what include_raw actually changes and whether pagination always returns None.

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 0% and the description does not compensate: neither 'mailbox' nor 'include_raw' is explained. The return shape mentions 'trimmed_folder', but the description never connects it to include_raw, leaving the agent without enough meaning to choose parameter values confidently.

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?

Description uses a specific verb and resource: 'List the user's mail folders (top level).' This clearly distinguishes it from sibling tools like list_messages, list_calendars, and delete_folder, and the parenthetical 'top level' adds an important scope qualifier.

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 a clear context (top-level mail folders for the current user), which implies when the tool is relevant. However, it does not state when not to use it or name alternatives for nested folders or other folder operations, leaving some selection inference to the agent.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It transparently explains client-side limit behavior with dropped teams, continuation-token pagination, the include_raw effect, and the exact return envelope. Minor gaps like sorting and errors are not critical for this read-only listing.

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 well-organized with a one-line summary followed by Args and Returns sections. Each line adds value. The phrase 'Applied client-side (see below)' is slightly vague, but overall the structure is efficient.

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 optional-parameter list tool, the description covers inputs, output envelope, pagination, and optional raw data. The main gaps are the specific fields inside trimmed_team and explicit loop-until-page-end guidance, but next_page_token makes that largely inferable.

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 0%, but the description fully documents all three parameters: limit includes range, default, and client-side trimming; page_token is identified as a continuation token; include_raw is tied to the raw Graph payload. This adds substantial meaning beyond the bare schema.

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

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

The description states a specific action ('List') on a specific resource ('teams the signed-in user is a member of'), which clearly distinguishes it from sibling tools focused on messages, calendars, chats, and channels. No ambiguity remains about what the tool does.

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

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

Usage context is implied: use when the signed-in user's team memberships are needed. However, there is no explicit when-not-to-use guidance or comparison with alternative tools, so the guidance is adequate but not strong.

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, and it does well: it states ordering (newest first), pagination ('Graph caps reply pages at 50'), default snippet-only output, and the effect of include_body/include_raw. It does not mention error behavior or auth, but the read-only nature is strongly implied by 'List' and the detailed return contract.

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 tightly organized into a one-line purpose, an Args block, and a Returns line. Every sentence adds operational value, with no filler or repetition of schema defaults.

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 a 7-parameter tool with no output schema and no annotations, the description supplies the missing contract: it defines each parameter, clarifies default behavior, and provides the exact return shape {'items': [...], 'next_page_token': str | None}. This is sufficient 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 0%, so the description must fully compensate. It does, explaining every parameter: team/channel/message ids, limit with its 1-50 range and Graph cap, page_token semantics, include_body's effect on body/attachments, and include_raw's raw payload inclusion. This is far beyond what the bare input schema offers.

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 a specific verb and resource: 'List replies to a channel message (the thread under a root post), newest first.' It clearly distinguishes this tool from generic message-listing siblings like list_channel_messages and list_messages by scoping it to thread replies under a root post.

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 for when the tool applies (thread replies under a root channel message) and even references list_channel_messages as the source of the root message id. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion guidance.

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

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

With no annotations, the description carries the full behavioral burden, and it mostly succeeds: it states ordering ('newest first'), server-side filtering, pagination mechanism, and the shape of the return value. It does not explicitly state 'read-only' or mention authentication/rate limits, but the read-only nature is strongly implied and no destructive side effects are suggested.

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 well-structured with a one-line summary, an Args block, and a Returns block. Every parameter earns its place, and the filter examples are useful rather than filler. It is concise despite the large number of parameters.

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

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

Despite no output schema, the description fully defines the return format and pagination token. It covers defaults, parameter semantics, filter interactions, and the one key limitation ($search) with a pointer to the right alternate tool. An agent has everything needed 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 0%, so the description must fully compensate. It explains every one of the 7 parameters in detail, adding default values, valid ranges (limit: 1-100), well-known folder names, OData filter syntax with examples, and the behavior of unread_only. This goes well beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'List messages from a mail folder, newest first.' It clearly distinguishes itself from sibling search_messages by noting that $search cannot be combined with filter and that search_messages should be used instead. The scope (folder, mailbox, pagination) is unambiguous.

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

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

The description gives concrete usage context: default folder, default mailbox, pagination continuation, and filter behavior. It explicitly warns that filter cannot be combined with $search and points to search_messages as the alternative. It does not cover every sibling relationship (e.g., get_message for a single message), but it provides enough for correct tool selection.

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 usefully discloses the return shape and the presence of a next_page_token, and mentions 'trimmed_rule.' However, it does not state whether the operation is read-only, how mailbox selection works, what include_raw does, or how pagination is intended to be used.

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 and front-loaded: one clear purpose statement followed by a compact return-type snippet. Every element earns its place with no filler.

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

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

The tool is simple, but without annotations, output schema, or parameter explanations, the agent is missing essential invocation details. The description covers what the tool does and roughly what it returns, but not how to use its options or when to prefer it over related tools.

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 0%, so the description must explain the parameters, but it does not. 'mailbox' and 'include_raw' are left completely opaque, and even the return note about 'trimmed_rule' only weakly hints at what include_raw might control.

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

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

The description states a specific verb and resource: 'List inbox mail rules.' It clearly distinguishes from sibling get_rule, which targets a single rule, and is not a mere restatement of the tool name.

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

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

No guidance is given about when to use list_rules instead of get_rule, search_messages, or other list tools. There is no mention of alternatives, exclusions, or conditions that would select this 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the state change and does not mention idempotency, permissions, effects on unread counts, or why include_raw exists. There is no contradiction, but the disclosure is minimal.

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

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

The description is a single, front-loaded sentence with no filler, making it easy to parse. However, its brevity partly stems from omitting necessary behavioral and parameter details.

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 3 parameters, no annotations, and no output schema, this description is too thin. It does not explain how to target the message, whether mailbox is needed, or what include_raw does, leaving an agent under-informed.

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 0% and the description names no parameters. message_id, mailbox, and include_raw are left completely unexplained, with include_raw being especially non-obvious for a 'mark as read' operation.

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 action ('mark') and resource ('a message') with an explicit resulting state ('read'), so an agent can immediately understand the tool's function. It does not explicitly differentiate from siblings like mark_unread or batch_mark_read, but the read/unread distinction is evident from the name and description.

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

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

There is no guidance on when to use this tool versus mark_unread, batch_mark_read, or other message-related tools. The required singular message_id implies single-message use, but the description never states this or any 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?

There are no annotations, so the description must carry the full behavioral disclosure burden. It states that the tool changes a message to unread, but does not mention idempotency, whether the message must already be read, any permissions, or expected response behavior. The description largely restates the tool name rather than adding 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 a single terse sentence with no filler and the action is front-loaded. It is concise, though slightly under-sized relative to the three-parameter schema and the need for sibling differentiation.

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, no output schema, and no parameter explanation, the description is incomplete. It does not distinguish this from related batch/read-state tools, nor does it clarify the optional parameters. An agent would need external knowledge to use it confidently.

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 0%, and the description names no parameters. It does not explain the roles of message_id, mailbox, or include_raw, leaving non-obvious fields like include_raw completely unexplained. The phrase 'a message' weakly implies message_id, but the description adds no real parameter meaning.

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 clear verb-resource pair: 'Mark a message as unread.' It identifies the target entity and the state change, and it is not a tautology. It does not explicitly differentiate from siblings like batch_mark_unread, but the singular 'a message' provides reasonable distinction.

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

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

No guidance is given about when to use this tool versus mark_read, archive_message, flag_message, or batch_mark_unread. The description simply states the action without conditions, exclusions, or alternatives. Given the large sibling set, this is a notable gap.

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 behavioral burden. It discloses the core mutating effect (move), optional include_raw behavior, and the return value. However, it does not mention permissions, source-copy deletion, or other side effects beyond the move itself.

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, front-loaded with a one-sentence purpose, and organized with Args/Returns sections. Every line 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?

Given no output schema and no annotations, the description covers all parameters and the return shape, but omits usage alternatives and potential side-effect caveats. The return type 'trimmed moved message' is descriptive but not fully specified.

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 0%, and the description compensates fully. It explains message_id as a Graph message id, enumerates valid well-known destination names, clarifies mailbox as optional, and defines include_raw. This adds meaning well beyond the raw 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 opening sentence 'Move a message to another folder' clearly states the action, resource, and goal. It does not explicitly distinguish this tool from batch_move_messages or archive_message, but the singular focus is apparent.

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

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

There is no guidance on when to use this tool versus alternatives like batch_move_messages or archive_message. The destination description enumerates well-known folders but does not state selection criteria 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?

There are no annotations, so the description is the sole source of behavioral information. It conveys that the tool performs a reply action, but it does not say whether this sends immediately, creates a draft, requires authentication, modifies the original, or what happens on failure. For a mutation tool, this is a significant transparency gap.

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

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

The description is a single tight sentence with no filler, repetition, or unnecessary detail. It front-loads the action and resource, and the parenthetical efficiently adds the key scope distinction. 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?

With no output schema, no annotations, and three parameters, the description should explain when to choose this tool, what side effects occur, and what comment and mailbox mean. It covers only the core action and recipient scope, leaving an agent guessing about optional parameters and operational behavior. This is a minimal definition rather than a complete one.

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 0%, yet the description does not explain the comment or mailbox parameters, nor does it explicitly map message_id to the 'message' it references. The optional parameters' semantics are absent from both the schema and the prose. The description provides no parameter-level value to compensate for the low 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 names a specific action ('reply-all'), a target resource ('a message'), and precisely defines the recipient scope ('sender + everyone on the to/cc lines'). This clearly distinguishes it from sibling reply_message and forward_message. The parenthetical adds important precision beyond the tool name.

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 parenthetical tells an agent the recipient set, which implicitly suggests when to pick this over reply_message, but it never names alternatives or states when-not-to-use conditions. No explicit exclusion or alternative guidance is provided, so the agent must infer usage from the recipient-scope definition alone.

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. 'Reply' implies sending a response, but the description does not state whether this sends immediately, how it handles threading, whether attachments are carried over, or what side effects occur.

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

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

One clear sentence with no filler. The essential action is front-loaded and every word contributes to the 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?

For a 4-parameter tool with no annotations, no output schema, and no parameter descriptions, a single purpose statement is not enough. The agent lacks guidance on optional recipients, mailbox selection, comment handling, and the tool's relationship to reply_all_message.

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 0%, so the description should compensate by explaining the parameters. It does not. The core parameter message_id is implied by 'sender of a message', but comment, mailbox, and extra_to are left entirely unexplained.

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 ('Reply') with a clear resource ('the sender of a message'). It immediately differentiates this tool from siblings like reply_all_message, forward_message, and send_message by anchoring the action to the original sender.

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

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

No guidance is given about when to choose this tool over reply_all_message, forward_message, or create_draft. There are no exclusions, alternatives, or contextual conditions, leaving the agent to infer usage purely from the tool name and sibling list.

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 burden. It usefully discloses that send_response=False records the response without emailing the organizer, implying the default sends email. However, it does not explain the mailbox parameter, permission requirements, or what happens after a response is recorded.

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 opening sentence is front-loaded and the Args section is compact with no wasted words. It earns a strong score, though the Args list is incomplete since it omits event_id and mailbox, which slightly weakens the structure as a standalone guide.

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 5 parameters, no annotations, and no output schema, the description leaves notable gaps: event_id and mailbox are undocumented, and there is no indication of return values or effects beyond the send_response note. This is adequate for a simple call but not complete for confident autonomous 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 0%, so the description must compensate. It adds meaning for response, comment, and send_response, especially clarifying the send_response side effect. However, it omits event_id (a required parameter) and mailbox entirely, leaving their semantics to be inferred from names only.

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

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

The description states a specific action ('Respond to a meeting invite') on a clear resource, and the phrasing differentiates it from sibling tools like update_event, delete_event, and cancel_event. An agent can tell this is the invitation-response tool rather than a general event mutation tool.

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 'Respond to a meeting invite', but there is no explicit guidance about when to choose this over alternatives, such as update_event, or when not to use it. No exclusions, prerequisites, or alternative tool mentions are provided.

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

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

With no annotations, the description carries the behavioral burden, and it does so well: it discloses that the query is passed through untouched, that the caller must supply quoting, and that Graph imposes search limitations. It stops short of stating read-only safety, error/empty-result behavior, or output shape, so a small gap remains.

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 longer than average, but every paragraph earns its place: purpose, essential Graph query caveats, alternative routing, and parameter explanations. The critical usage constraints are front-loaded before the arg list, and no content is redundant with the schema.

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 complex search tool with no output schema and no annotations, the description covers the main invocation risks: query syntax, quoting, Graph limitations, and the alternative path for filtered searches. It does not describe the shape of returned message objects or pagination continuation details beyond naming page_token, but this is a minor gap given the otherwise thorough guidance.

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 0%, so the description must define every parameter, and it does: query gets a full explanation with token, phrase, and KQL field:value semantics; limit gets its range; mailbox, page_token, and include_raw all get meaningful one-line explanations. This adds substantial meaning beyond the bare schema titles.

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 first sentence names a specific verb ('Search'), a concrete resource ('messages'), and a clear scope ('across all folders'), and identifies the underlying mechanism (Graph $search). This is enough to distinguish it from sibling list_messages and other mail operations without inspecting the schema.

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

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

The description explicitly explains when this tool is the right choice (keyword search via Graph $search), states restrictions (cannot combine with $filter/$orderby, no isread/unread/flag/in KQL predicates), and names list_messages with an exact filter pattern as the alternative for filtered keyword searches. This is direct when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses immediate sending, the save_to_sent_items default, the 3 MB attachment size limit, the mailbox default, and the exact return payload. It does not cover auth requirements, rate limits, or failure modes, but the main side-effects and constraints are visible.

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 opens with a one-sentence purpose, then uses a compact, scannable Args list with defaults and constraints, followed by the return shape. Every line adds useful information; there is no filler or repetition of schema-only details.

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

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

Despite having no output schema and no annotations, the description is complete enough for an agent to invoke the tool correctly: it explains every parameter, key constraints, defaults, and the expected return. The only omissions are error/edge-case behavior and explicit sibling routing, which are handled by other dimensions.

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 0%, and the description compensates by documenting all nine parameters: required non-empty 'to', defaults for body_type and save_to_sent_items, optional cc/bcc, attachment object shape with size limit, and mailbox default. This adds substantial meaning beyond the bare schema.

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

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

The description states a specific verb and resource: 'Send a new message immediately.' The qualifiers 'new' and 'immediately' distinguish it from draft, reply, forward, and scheduled-message siblings, so an agent can tell what the tool does without needing to inspect other definitions.

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 opening sentence gives clear operational context: use this when you want to send a new message immediately. It does not explicitly name alternatives like create_draft, reply_message, or forward_message, nor does it give when-not-to-use guidance, so it falls short of a full 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?

No annotations are provided, so the description carries the full burden. It only states the action itself; it does not disclose whether unflagging is idempotent, what happens if the message isn't currently flagged, whether other flags are affected, or what the response looks like. For a mutation tool this is a notable 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?

A single, direct sentence with the verb front-loaded. No wasted words; it conveys the essential action immediately and 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 3-parameter tool with no annotations and no output schema, the one-line description leaves important gaps: it doesn't explain mailbox or include_raw, doesn't say when to use single versus batch unflagging, and provides no behavioral caveats. The description is too minimal to be fully actionable.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only weakly implies that message_id identifies the message to unflag; mailbox and include_raw are not addressed at all. The added meaning over the schema's bare parameter names is minimal.

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 ('Clear') and resource ('follow-up flag on a message'), making the core action clear and distinguishing it from tools like mark_read or archive_message. However, it does not differentiate from closely related siblings such as flag_message or batch_unflag_messages.

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

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

The description gives no guidance on when to use this tool versus alternatives like batch_unflag_messages or flag_message. There are no conditions, exclusions, or context signals to help an agent choose between the single-message and batch variants.

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 burden of behavioral disclosure. It reveals that passing None leaves a field unchanged and imposes a time_zone requirement when changing datetime fields. Yet it does not disclose what happens if fields are omitted (as opposed to passed as None), whether the operation is destructive, or how errors are handled (e.g., invalid event_id). The disclosed behaviors are useful but incomplete for a mutating 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 sentences long, with the purpose front-loaded and a critical constraint following. It avoids redundancy and uses precise language ('Pass None to leave a field unchanged'). The structure is efficient and easily parsed, though it could include more detail without sacrificing conciseness.

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 12 parameters, no annotations, and no output schema, the description is severely under-specified. It does not explain return values, error conditions, or provide usage examples. It covers only the null semantics and the time_zone rule, which is insufficient for an agent to reliably invoke the tool across all scenarios. The complexity demands far more contextual detail than provided.

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

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

Schema description coverage is 0%, so the description is the only source for parameter meaning. It adds the null semantics for all fields and the time_zone dependency, but it does not explain the format of start_datetime/end_datetime, the meaning of body_type, is_all_day, is_online_meeting, or include_raw. Many parameters are self-explanatory by name, but the description provides minimal additional value beyond the null behavior, leaving agents to guess at specifics.

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

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

The description states a specific verb and resource: 'Patch fields of an existing event.' This distinguishes it from create_event and delete_event by focusing on modification of an existing entity. However, it does not enumerate which fields can be patched, leaving some ambiguity about scope. Sibling tools like list_events, get_event, and create_event are clearly separate in 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 description provides a specific usage rule: 'If you change start_datetime or end_datetime, you must also pass time_zone.' This is a conditional instruction for correct invocation. However, it does not explicitly guide the agent on when to choose this tool over create_event (e.g., when the event already exists) or when to avoid it. The usage guidance is limited to a single dependency and lacks alternative selection context.

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 behavioral disclosure burden. It does well by specifying that at least one of display_name or parent_folder_id is required, that Graph rejects mutations of well-known folders, that None means unchanged, and that the result is a trimmed updated folder. This goes meaningfully beyond the bare schema.

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

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

The description is front-loaded with the core purpose, then organized into Args and Returns sections. Every sentence provides needed operational information—required fields, constraints, parameter semantics, and return value—with no filler.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers purpose, required parameters, constraints, optional parameters, and return value. The only minor gap is not explaining what 'trimmed' means or the default mailbox behavior when mailbox is null, but the essential information needed to call the tool correctly is present.

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 0%, so the description must compensate, and it does thoroughly. Every parameter is explained with operational meaning: folder_id is a Graph id, parent_folder_id accepts well-known names, mailbox targets shared mailboxes, and include_raw returns the raw Graph payload. This is exactly the kind of semantic detail the schema lacks.

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 first line states a specific action ('Rename and/or reparent') on a specific resource ('mail folder'), which clearly distinguishes it from sibling tools like create_folder, delete_folder, and update_message. The purpose is immediately obvious 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 implies when to use it by defining the operation, and it usefully warns that well-known folders cannot be renamed or moved. However, it does not explicitly name alternatives or state when a different folder/message tool should be preferred, leaving usage selection mostly to inference.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add useful context: 'patches in-place,' the parent_folder_id caveat, and 'Returns the trimmed updated message.' Still, it does not explain what null/default values do to existing fields, whether categories are replaced or appended, or any permission/reversibility implications for this 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?

Three short sentences: the purpose is front-loaded, the routing caveat is compact, and the return behavior is stated last. There is minimal filler, and the structure makes the key information 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?

The description is adequate for the happy path but not complete for this tool's complexity. It omits clear explanations of mailbox and include_raw, does not distinguish from read/flag convenience siblings, and 'trimmed updated message' is vague about the response shape. Given no output schema and no annotations, these are notable gaps.

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

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

Schema coverage is 0%, so the description must compensate. It only maps four high-level fields (read state, flag, importance, categories) and adds no semantics for mailbox, include_raw, message_id, or how parent_folder_id behaves beyond 'works but is not the primary path.' The schema titles and enums do some work, but the description does not add enough meaning for the full 8-parameter surface.

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

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

The description opens with a specific verb and resource: 'Patch a message's read state / flag / importance / categories.' It also explicitly distinguishes itself from move_message, which is the main sibling that could be confused for this tool.

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 gives explicit routing guidance for folder movement: 'prefer move_message' and clarifies that parent_folder_id works but is not the primary path. However, it does not guide the agent toward or away from the specialized siblings mark_read, mark_unread, flag_message, or unflag_message, which overlap directly with this tool's stated purpose.

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 fully explains the Graph PATCH replacement behavior: passing any condition arg rebuilds the conditions block from only the args passed, dropping others, and the same for actions. It also discloses that passing no condition/action args preserves existing blocks, and mentions the 'trimmed' return value and the include_raw option. This is critical behavior an agent must know before calling.

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 long but every section earns its place. The replacement semantics are front-loaded and explained in a dedicated block, the Args list is organized with grouping and clear phrasing, and the Returns line is brief. It's not verbose for the complexity, though it could trim some redundancy in the repetition of 'None = unchanged' across individual args.

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 16 parameters and complex nested-block behavior, the description covers everything an agent needs: the replacement semantics, the workaround to preserve existing values, the optional mailbox for shared mailboxes, include_raw for raw payload, and the return value. No critical behavior is left to inference.

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 0%, so the description must compensate – and it does. Each parameter is explained with its semantic role: rule_id is required, optional fields default to None meaning unchanged, and the condition/action args are grouped and explicitly tied to the replacement behavior. It adds meaning far beyond the raw types and defaults 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 opens with 'Patch fields of an existing inbox mail rule' – a specific verb and resource that clearly distinguishes it from create_rule, delete_rule, and get_rule. The phrase 'existing' implies the rule must already exist, and the 'Pass None to leave a field unchanged' adds precision.

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 explains when to use this tool versus alternatives. It details the replacement semantics – that passing any condition/action arg rebuilds that block, dropping unspecified values – and directly advises 'If you want to add to a block without losing the rest, call get_rule first and re-supply the existing values.' This is concrete, actionable guidance that prevents data loss.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses the trimmed return shape, the optional raw Graph payload behavior, and the authentication-checking nature of the call. It does not detail error behavior or rate limits, but for a simple read-only profile tool the disclosed behavior is reasonably complete.

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 tight and well-organized: purpose, secondary use, argument behavior, and return object are each covered in a few concise lines. There is no filler, and the core purpose 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?

The tool is simple, has one optional parameter, and no output schema; the description fully compensates by enumerating the exact return fields and explaining the raw payload option. An agent has enough information to call the tool and interpret its result without ambiguity.

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 only parameter, include_raw, is explained meaningfully: 'when True, include the raw Graph payload under raw.' The schema only provides a title and default, so this description adds the actual behavior an agent needs to invoke the tool correctly.

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

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

The description states a specific action and resource: 'Return the signed-in user's profile.' It also adds the secondary use as an authentication smoke test, which makes the tool's purpose unmistakable. None of the sibling tools overlap with profile retrieval, so it is clearly differentiated.

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

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

The description gives clear context by positioning the tool as 'a smoke test that authentication is working,' which tells the agent when it is appropriate to call it. It does not explicitly name alternative tools or exclusion conditions, but no sibling tool serves the same purpose, so explicit exclusions are unnecessary.

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