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

Annotations only declare readOnlyHint=false and destructiveHint=false, so mutation is already known; the description adds nothing about whether the item is appended to the end, whether duplicates are prevented, or what errors occur for an invalid task_id.

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

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

A single front-loaded sentence with zero filler; concise, though the brevity is partly under-specification rather than economy.

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?

A write tool with no output schema and undocumented parameters should at least say whether the created item's identifier is returned (needed for the follow-up update/delete checklist item calls) and how list_id relates to task_id; neither is covered.

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% across three parameters, and the description mentions none of them — notably list_id, whose purpose and relationship to task_id is entirely unexplained by either the description or 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?

States a specific verb ('add') and resource ('checklist item (sub-step)') scoped to a To Do task, which cleanly separates it from sibling update_checklist_item and delete_checklist_item by operation type.

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

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

No guidance on when to use this versus outlook_update_task or outlook_update_checklist_item, and no prerequisite stated (e.g. that the target task must already exist in a task 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?

Beyond the permissive annotations (readOnlyHint=false, destructiveHint=false), it discloses the 3MB auto-switch threshold, the attachments_dir resolution rule, that out-of-directory paths are refused, the 3MB per-inline-file cap, and the return value (new attachment IDs). That is exactly the operational context annotations cannot express.

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 purpose and the 3MB rule are front-loaded in the first sentence, and every subsequent clause carries real information. Minor deduction for the mid-sentence line wrapping that slightly fragments the `attachments` clause.

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 and no schema descriptions, the description still covers all three parameters' meaning and the return value, which is sufficient to invoke it correctly. Residual gaps: whether attachments append to or replace existing ones, and any total-size limit across multiple files.

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% and the inline `attachments` schema is only an untyped additionalProperties object. The description compensates by spelling out the item shape ({name, content_base64, content_type?}), the per-item size limit, and the path-resolution/security semantics of `attachment_paths` — far more than the schema alone conveys.

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 and resource ("Add attachments to an existing draft") plus a notable behavioral trait (auto-switching to upload-session above 3MB). This clearly separates it from outlook_create_draft, outlook_send_with_attachments, and outlook_attach_to_event without opening 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 target resource (an existing draft) makes the applicable context clear, and the return-value sentence points to outlook_remove_draft_attachment as the paired follow-up tool. It stops short of stating when-not to use it (e.g., attaching to a task or message, or creating a draft with attachments in one step).

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

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

Annotations only declare readOnlyHint=false and destructiveHint=true. The description adds real behavior the annotations cannot convey: transparent upload-session switching above 3MB, path resolution scoped to `attachments_dir`, deferred delivery to attendees, and the return of new attachment IDs. It stops short of saying whether existing attachments are replaced or whether anything is destroyed, which is notable given destructiveHint=true.

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 with no filler; the core action and the size-threshold behavior are front-loaded. The cross-reference to another tool for path semantics is economical but pushes detail out of the definition.

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

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

For a two-parameter mutation tool with no output schema, the description covers the size-dependent upload path, path scoping, delivery timing, and the return value. The remaining gap is the destructiveness/mutation semantics implied by the annotations, which an agent would want spelled out.

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 carries the burden for both parameters. It partially does so: `attachment_paths` is explained as resolving inside `attachments_dir` (with a cross-reference to a sibling tool for the exact rules), but `event_id` is never addressed. Half-compensation for a low-coverage schema puts it at a middling score.

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 clause states a specific verb and resource ('Attach files to an event') and immediately notes the >3MB upload-session switch. It is clearly distinguishable from the mail-attachment and draft siblings, though it does not explicitly say when to prefer this over outlook_attach_to_draft.

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

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

The mention of 'as for outlook_attach_to_draft' and the note that attendees receive the files on the event's next update implies the event context but gives no explicit when-to-use or when-not guidance. The agent must infer that this is the calendar counterpart to the draft attachment 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description usefully adds a remediation path for the failure case, but says nothing about what the status reflects (token expiry, account, scopes) or what happens when unauthenticated.

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

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

Two short sentences, front-loaded with the purpose and followed by the actionable fallback. No 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?

With no output schema, the description ideally would say what a status result contains (e.g., authenticated true/false, account, expiry). For a simple diagnostic tool the gap is minor but real, and the sibling overlap with outlook_whoami remains unresolved.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

States a specific verb and resource ('Check authentication status'), which is clear on its own. However, it does not differentiate itself from the sibling outlook_whoami, which plausibly also reports identity/auth information, leaving the agent to guess which to call.

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 remediation hint ('Run `outlook-mcp auth` on the host if needed') implies this is a pre-flight/diagnostic check, but the description never states when to call this versus outlook_whoami or other tools, nor any exclusion conditions.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds the meaningful batch constraint (single $batch call, 20-message cap), but says nothing about partial-failure behavior, ordering, or error handling for a multi-item mutation, which is the main behavioral question here.

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?

Front-loaded with the core capability, then action values, then a concrete example, then value semantics and the hard cap. No filler sentences; each line adds information the schema lacks.

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 three-required-param batch mutation with no output schema and no enum enforcement, the description covers inputs well but omits any indication of what comes back (per-message results? aggregate success?) and how over-cap or invalid action inputs are handled.

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 carry the load, and it does: it names the valid action values (move/flag/categorize/mark_read) and explains that `value` is the action target with per-action meaning, plus an inline example showing message_ids usage. Weakness: "status for flag/mark_read" is vague and no action enum exists 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?

States a specific verb (triage) and resource (up to 20 messages in one $batch call) and enumerates the four supported actions. It is distinguishable from per-message siblings like outlook_move_message or outlook_flag_message by the batching scope, though it never explicitly says so.

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 batch framing and the "hard cap of 20" imply when to reach for this over single-message tools, but no explicit rule is given (e.g., use this instead of outlook_move_message when handling multiple messages). No prerequisites or exclusion conditions are 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description is not the only source of safety information. It does add real value by disclosing the overwrite semantics ("replaces the full list"), which is the single most important behavioral fact here. However it says nothing about whether unknown category names are auto-created, rejected, or silently ignored, which materially affects how the agent should construct the argument.

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

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

Two lines total, with the overwrite constraint front-loaded before the illustrative call. Nothing is padded, and the example is compact enough to earn its place as a parameter-shape demonstration.

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

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

For a two-parameter mutation with no output schema, the definition covers the core behavior but leaves out the return value and the validation/creation rules for category names. An agent can call it, but may produce wrong results if it passes new category names or omits existing ones, so it is adequate rather than 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 must carry the parameter burden. The inline example does clarify the shape of both parameters (a message_id string and a categories string array), which is better than nothing. It still leaves open the accepted format of message_id and the rules for category strings, so it only partially compensates for the coverage gap.

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

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

The description names a specific verb and resource ("Set categories on a message") and adds the crucial qualifier that the operation replaces the full list. It is clearly distinct from read/flag/move siblings, though it does not explicitly differentiate itself from outlook_reclassify_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?

Usage is implied: because the operation replaces the full list, the agent can infer it must gather existing categories first, but this is never stated as a prerequisite. No mention of when to use this instead of outlook_reclassify_message, nor of outlook_list_categories as the way to find valid category names.

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?

Regardless of the readOnlyHint annotation, it discloses behavior an agent could not infer: stateful token lifecycle, token independence per resource, auto-resync on Graph 410/syncStateNotFound, and that has_more means one resource stopped early. It also defines the derived fields (urgent_flagged = high-importance OR flagged; by_sender = top 5) and flags known empty fields (calendar organizer_email, modified[]).

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?

Front-loaded with purpose and routing before the operational detail, and nearly every sentence carries unique operational value. It is dense and runs long, with the calendar caveats tacked onto the end where they are easy to lose, but nothing is truly redundant.

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?

There is no output schema, so the description must describe return values and it does: counts, urgent_flagged, by-sender rollup, new/cancelled events, contacts counts, the returned delta_tokens dict, has_more, and _meta.resync. Combined with the token lifecycle and known-gap disclosures, an agent has everything needed to call it correctly across a multi-turn loop.

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% and delta_tokens is an untyped nested object, yet the description fully specifies its semantics: omit on first call, pass back the value from the prior response, replace rather than merge stored tokens, drop individual stale tokens without re-syncing others. It also explains fallback_window_hours (default 24, window size on the first call), which the schema leaves 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 first sentence names a specific verb and scope: one structured 'since last call' digest across mail, events, and contacts. It immediately lists the concrete payload (counts, urgent_flagged, by-sender rollup, new/cancelled events, contacts counts), so an agent can distinguish it from the per-resource delta siblings without reading 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?

It states the trigger use case explicitly (recurring agent loops: morning brief, hourly inbox sweep) and names the alternatives with the condition that selects them: the three delta tools when raw item lists or per-resource control are needed. That is when/when-not plus named alternatives, the full 5 bar.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/non-destructive profile is covered structurally. The description adds nothing beyond that: it does not say whether completion is reversible, what happens if the task is already completed, or how the task is located (by id alone or within list_id).

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 short sentence with the action front-loaded and no filler. It is appropriately sized for the operation, though its brevity is partly under-specification rather than true economy.

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

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

For a two-parameter mutation tool with 0% schema description coverage and no output schema, the description is too thin — the meaning and necessity of list_id, and the result of the call, are left entirely unaddressed.

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

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

Schema description coverage is 0%, so the description carries the burden and fails: it never explains task_id's format or whether list_id is required to disambiguate the task lookup. At best 'a To Do task' weakly implies task_id identifies the target, which is a marginal addition over 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?

States a specific verb and resource ('Mark a To Do task as completed'), which is unambiguous about the effect. It does not distinguish itself from the sibling outlook_update_task, which could plausibly also set completion status, so an agent has no basis for choosing between them from the text alone.

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 when-to-use guidance, no mention of prerequisites (does the task need to exist in a specific list?), and no reference to alternatives such as outlook_update_task. The agent must infer everything about selection from the tool name.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds real value by spelling out the duplicate-and-leave-source semantics, but it says nothing about whether attachments, categories, or flags carry over to the copy, which is the main behavioral ambiguity for a copy 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?

Two tight sentences with the core semantics front-loaded in parentheses and the sibling pointer after. No filler, and the folder-format note is compact enough to justify its space.

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

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

For a two-param, non-destructive tool with no output schema, this covers the decision and the invocation. The remaining gap is what the resulting copy retains versus the original, which an agent might reasonably want before copying a message with attachments.

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 carry the load, and it does for the non-obvious parameter: `folder` accepts display names, well-known names, or Graph IDs, with a stated preference. `message_id` is left implicit, which is defensible since its meaning is self-evident, but the format is never confirmed.

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 and resource ("Copy a message to another folder") and immediately clarifies the key semantic distinction: duplicates, source unchanged. This separates it cleanly from outlook_move_message, which appears among its siblings.

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

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

Explicitly routes the agent: use outlook_move_message to remove from source, use this to duplicate. It names the alternative and the condition that selects each, leaving nothing 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/safety profile is covered. The description adds genuine disambiguation value ("title ... is not the job"), but says nothing about duplicate handling, required permissions, or what happens on partial input.

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

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

Two tight sentences, front-loaded with the operation before the field clarifications. The parenthetical and the title/phone_type notes each earn their place, though slightly telegraphic phrasing pushes it just shy of a 5.

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

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

With 12 zero-documented parameters and no output schema, a complete definition would have to explain the undocumented fields or at least the creation result. Given the moderate complexity, the current coverage is adequate but with clear gaps.

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

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

Schema coverage is 0% across 12 parameters, so the description must compensate. It clarifies birthday format (YYYY-MM-DD), the title-vs-job_title trap and phone_type values, but leaves categories, middle_name, last_name, personal_notes and default phone_type semantics (only the default value is given) 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 opens with a specific verb and resource ("Create a new contact"), then enumerates the addressable fields, so an agent can tell it apart from outlook_update_contact or outlook_delete_contact without opening the schema.

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

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

The create semantics are self-evident, but the description never says when to reach for this versus outlook_update_contact (e.g. contact already exists) or whether duplicates are checked. Usage is only implied by the verb.

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

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

Annotations already declare readOnly=false and destructive=false. The description adds meaningful behavior beyond that: drafts are for later review/send, deferred_send_datetime schedules server-side holding after outlook_send_draft, and Graph's reply auto-fill can be overridden by passing [] versus omitting a recipient.

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 dense but front-loaded: it leads with purpose and alternative, then uses compact parentheticals for scheduling and reply/forward semantics. For a 13-parameter tool with no schema descriptions, the length is justified and no sentence is 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 13 parameters, no output schema, and minimal annotations, the description covers the non-obvious threading, forwarding, and scheduling behavior well. It is less complete on basic formatting flags and some recipient fields, but an agent can still call it correctly for common draft creation.

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?

With 0% schema description coverage across 13 parameters, the description compensates for several non-obvious ones: reply_to_message_id, reply_all, forward_message_id, deferred_send_datetime, and reply_to. It also explains the subtle [] versus omitted behavior for reply recipients. However, it leaves bcc, is_html, is_markdown, importance, and body format semantics undocumented, so coverage remains partial.

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 ('Create a draft email') and explicitly distinguishes the draft workflow from immediate sending by naming outlook_send_message and outlook_send_draft. An agent can identify the tool's role without inspecting siblings.

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 when-to-use guidance: choose this when a human should review before sending, and use outlook_send_message for immediate send without review. It also says to pair with outlook_send_draft, covering the follow-up action.

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?

Goes well beyond the annotations: it warns that `is_online` is silently ignored on consumer mailboxes (with the exact failure shape Graph returns), that Teams meetings need a work/school account, that `recurrence` produces a series rather than a single event, and that omitting `show_as` defaults to busy. These are non-obvious backend behaviors an agent could not get from `destructiveHint: true` alone.

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?

Front-loaded with a one-line summary plus a concrete call example, then ordered by parameter importance. It is long, but the length is earned by 13 undocumented parameters and several genuinely surprising behaviors; a few sentences (the full Graph JSON example, the repeated noEnd warning) could be tightened without losing information.

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

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

No output schema exists, so the description would ideally say what comes back (an event ID? retrievable via outlook_find_event_by_key using `key`?) — that link is left implicit. Otherwise it covers the mutation semantics, account-type constraints, and defaulting behavior needed to call 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?

With 0% schema coverage across 13 parameters, the description does the heavy lifting: it defines the accepted values of `show_as` (a de-facto enum), the IANA format for `timezone` with an explicit anti-pattern (never "PDT"), the ISO 8601 format for start/end, the dual string-or-object shape of `recurrence`, and the meaning of `key`. `body`, `location`, and `is_all_day` are left undefined, which is why it falls short of a 5.

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 a specific verb+resource ("Create a calendar event") and enumerates the salient optional dimensions (attendees, recurrence, busy status, online meeting). An agent can distinguish it from outlook_update_event/outlook_delete_event by verb alone, but the description never names those siblings or states the boundary explicitly.

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?

Rich conditional guidance: use the shorthand recurrence strings for the common cases and the full Graph object "for anything else," prefer a bounded range when attendees exist, omit `calendar` for the default. What's missing is routing against siblings (e.g. use outlook_update_event to modify an existing event) — the agent must infer the create-vs-update boundary.

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

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

Annotations already declare this is a non-destructive write, and the description adds only the nesting behavior. It omits what happens when the folder already exists, whether the parent is auto-resolved or must pre-exist, and any permission requirements.

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

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

A single sentence with the action front-loaded and the parameter hint second; no filler or restatement of the name.

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?

Adequate for a two-parameter creation tool, but with no output schema the agent is left without the created folder's identifier, which is typically needed for follow-up moves or listing, and error behavior on duplicate names is 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 coverage is 0%, so the description carries the burden. It usefully discloses that parent_folder accepts a name, path, or ID, resolving real ambiguity; however the required `name` parameter gets no mention and no format/constraint detail.

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 and resource ('Create a mail folder'), which cleanly separates it from the other folder siblings (rename_folder, delete_folder, list_folders). It does not explicitly name those siblings, but the verb makes selection 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 sentence explains a parameter's effect ('pass parent_folder to nest it') rather than when to use this tool versus alternatives. There is no guidance on prerequisites, what happens on a duplicate name, or when a flat folder is preferable to a nested one.

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?

Goes well past the readOnlyHint=false / destructiveHint=false annotations by disclosing a silent-failure mode ('Graph silently drops a reminder that has no time') and a defaulting side effect (falls back to the default list). It also flags the ambiguous relative-offset parsing where a bare '7d' means seven days ago, which is exactly the kind of trap an agent would otherwise hit.

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?

Purpose is front-loaded, followed by a compact example and four short, high-value notes; each line carries distinct information. The example line is mildly redundant with the notes but earns its place by showing argument names in use.

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 7-parameter create tool with a nested object and no output schema, the description covers the risky and ambiguous parameters well. The gap is recurrence, an untyped nested object with no explanation anywhere in the definition, and no hint of what the call returns.

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?

With 0% schema description coverage the description must carry the load, and it does for due (ISO 8601 or relative offset), importance (low/normal/high), reminder (requires due), and list_id (default-list fallback). It documents neither the shape of the nested recurrence object nor anything about body beyond 'optional body', leaving two of seven parameters thin.

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 and resource ('Create a Microsoft To Do task') and enumerates the optional fields, which cleanly separates it from the sibling mutators outlook_update_task, outlook_complete_task, and outlook_delete_task. An agent can identify the right tool without opening the schema.

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

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

Provides clear operating context: list_id omission falls back to the user's default list, and reminder=True requires due. It does not explicitly state when to prefer outlook_update_task or outlook_add_checklist_item instead, so the routing guidance is implied rather than spelled out.

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 annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a destructive write. The description adds the parent context that the item belongs to a To Do task, but it does not explain irreversibility, permission needs, or side effects. With annotations carrying the safety profile, this is minimally adequate.

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 redundant or filler text. Every word contributes to identifying the action and resource.

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 destructive three-parameter tool with 0% schema description coverage and no output schema. The description identifies the operation and parent resource but omits parameter guidance, usage context, and behavioral consequences. It is not complete enough for reliable invocation without inspecting the schema manually.

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 schema provides no semantics for task_id, checklist_item_id, or list_id. The description implicitly references task and checklist item, which maps to the two required IDs, but it says nothing about list_id, ID formats, or where those IDs come from. It does not compensate for the coverage gap.

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

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

The description states a specific verb and resource: delete a checklist item from a To Do task. This distinguishes it from deleting an entire task or task attachment. It does not explicitly differentiate from sibling checklist operations, but the resource noun is clear.

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

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

The description gives no when-to-use guidance, prerequisites, or alternatives. It does not tell the agent when to delete a checklist item versus updating the task or using a related sibling. Usage is only implied by the operation itself.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether the deletion is permanent or recoverable, what happens if the contact_id does not exist, or whether permissions beyond standard auth are required.

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

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

The single sentence is front-loaded and wastes no words, but it reads as under-specification rather than disciplined brevity for a destructive mutation tool.

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 an irreversible-looking destructive operation with no output schema and an entirely undocumented parameter, the description omits the essentials: permanence, error behavior on missing IDs, and where a valid contact_id comes from. An agent could call it, but not 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%, so the description must compensate. 'By ID' is the only clue, and it only confirms that contact_id is an identifier rather than a name or email — a marginal addition over the property name itself. No format, source, or validity constraints are given.

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

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

The description names a specific verb ('Delete') and resource ('a contact'), which distinguishes it from the many other delete tools among the siblings (delete_message, delete_task, delete_event, delete_folder). It stops short of any framing beyond that, but an agent can identify the operation unambiguously.

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 versus alternatives such as outlook_update_contact, nor any precondition (e.g., confirm the contact first, verify the ID came from outlook_search_contacts). The agent is left to infer all 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?

The annotations already declare destructiveHint=true and readOnlyHint=false, so the irreversible nature is structurally conveyed. The description adds nothing on top of that: it says nothing about permanence, whether the draft can be recovered, or whether attachments are discarded with it.

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, front-loaded with the action, with no filler. It is terse to the point of under-specification, but nothing in it is wasted.

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 one-parameter destructive tool with annotations and no output schema, this is minimally viable: the agent knows what is deleted. It is missing the source of the ID and any statement of consequence, which matter more here because the operation is irreversible.

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 single draft_id parameter carries no documentation of its own; the phrase "by ID" at least confirms that draft_id is the draft's identifier and is required. It stops short of saying what form the ID takes or where to obtain it.

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

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

The description names a specific verb and resource ("Delete a draft message") and adds the identifier constraint ("by ID"), so an agent knows exactly what the call performs. It does not explicitly contrast with the neighboring outlook_delete_message, which is the closest confusable sibling for an agent holding a draft ID.

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

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

There is no guidance about when this should be used rather than outlook_delete_message, nor any prerequisite such as where a valid draft_id comes from (e.g., outlook_list_drafts). The usage is only inferable from the name.

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

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

Goes beyond the destructiveHint=true annotation by disclosing the downstream side effect: cancellation plus attendee notifications when the caller is the organizer. It does not state whether the deletion is irreversible, whether it requires organizer/owner permissions, or what happens for non-organizers, which keeps it below a 5.

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

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

A single front-loaded sentence with no waste; the parenthetical adds the non-obvious side effect rather than restating the name.

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 one-parameter destructive tool with annotations already flagging destructiveness and no output schema, the description covers the essentials plus the attendee-notification consequence. Only irreversibility and required permissions are left unstated.

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?

One parameter with 0% schema description coverage, so the description must carry the burden. 'By ID' identifies the parameter's role but adds nothing about format, origin, or whether it's the Graph event ID versus an iCalUID.

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 (Delete) plus resource (calendar event) and the keying mechanism (by ID). Easily distinguished from siblings like outlook_update_event or outlook_list_events without consulting 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?

Usage is implied by the delete verb and the ID argument, but no explicit guidance on when to use this versus outlook_update_event (to modify) or how to obtain a valid event_id (e.g., from outlook_list_events / outlook_find_event_by_key). No exclusions or alternatives are named.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write. The description adds one genuine behavioral rule beyond that (name-based rejection of well-known folders), but it is silent on the important destructive question: whether deleting a folder cascades to its messages and child folders, and what error/permission conditions look like.

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 sentence with the primary action front-loaded and the constraint trailing for emphasis. Nothing is redundant or padding.

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 destructive, single-parameter tool with no output schema, the definition covers the core action and one guardrail but leaves gaps an agent would want: how to discover a valid folder_id and whether folder contents are destroyed along with the folder.

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 has to carry the load for folder_id. 'By ID' confirms it takes an identifier, but does not say where that ID comes from (outlook_list_folders) or whether it accepts display names or well-known names — the only hint is that well-known names are rejected.

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+resource (delete a mail folder) plus the scope restriction that it must be user-created, which is what separates it from folder-creation/rename siblings and from message-level deletes like outlook_delete_message. An agent can tell exactly what class of object this operates on without opening the schema.

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

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

The 'refuses well-known folders (inbox, sentitems)' clause gives an explicit when-not condition, which is real routing guidance. It stops short of naming an alternative path (e.g. use outlook_delete_inbox_override or outlook_move_message for well-known folder contents) or saying how to obtain a valid folder_id via outlook_list_folders.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description's 'Delete' is consistent with that. However, it adds nothing beyond the annotations — no mention of irreversibility, whether the rule can be recreated, or what happens to messages previously routed by the rule.

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

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

A single front-loaded sentence with no filler; the resource and the identifying parameter are both stated immediately.

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 one-parameter delete with annotations covering the safety profile and no output schema, this is nearly sufficient. The only missing piece is how to discover a valid override_id, which would help an agent call it correctly without a failed attempt.

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% for the single override_id parameter, so the description must carry the burden. It does say the rule is deleted 'by its ID', which clarifies the identifier role, but does not indicate the ID format or where to source it.

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 (Delete) and a precisely-scoped resource (Focused Inbox per-sender override rule) plus the identifier used. It is clearly distinct from outlook_list_inbox_overrides and outlook_set_inbox_override, though it does not name them explicitly.

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 versus set_inbox_override or how to obtain a valid override_id (e.g., via outlook_list_inbox_overrides). The usage is only implied by the name and verb.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is carried structurally. The description does add real value by disclosing the recoverable-default / permanent-flag split, but says nothing about behavior on a missing message_id or whether permissions or mailbox scope affect deletion.

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

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

Two short sentences, front-loaded with the effect and its reversible default, followed by the anti-pattern warning. Nothing redundant.

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

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

For a two-parameter destructive tool with annotations covering safety, this is nearly complete: the soft/hard distinction and the sibling exclusion are the essentials. Only gaps are message_id provenance and error behavior, which are modest.

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 carry the load. It fully explains `permanent` (default soft delete, True = hard delete) but leaves `message_id` entirely undocumented — its source (list/read/search siblings) and format are 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?

States a specific verb and resource ("Delete a message") and immediately names the sibling it must not be confused with: outlook_move_message(folder="deleteditems"). An agent can pick it apart from the move tool without opening either 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?

Declares itself the canonical deletion path and gives an explicit when-not with the exact alternative call to avoid. This is direct routing guidance rather than implied 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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known. The description adds nothing beyond the annotations: it does not say whether the delete is permanent or recoverable, what happens to attached files/checklist items, or whether a nonexistent task errors out.

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 sentence with no filler, front-loading the action and target. It is efficient but arguably under-specified rather than genuinely well-structured.

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 destructive mutation with no output schema and zero parameter documentation, the description is too thin. It should at minimum clarify permanence, the role of list_id, and any auth or scope requirements.

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 carry the parameter burden, and it does not. It never explains that task_id is required and list_id is optional, nor what happens when list_id is omitted — a real ambiguity given the same task name may exist in multiple lists.

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 (delete) and resource (task in a Microsoft To Do list), distinguishing it from nearby siblings like outlook_delete_checklist_item and outlook_delete_task_attachment by scoping to the task itself. It does not explicitly name the sibling alternatives, 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?

There is no guidance on when to use this versus alternatives such as outlook_complete_task (closing out a task) or outlook_delete_checklist_item, and no stated prerequisites or exclusions. The agent must infer that deletion is for removal rather than completion.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's only real claim ('Remove') merely restates them. It adds no context on irreversibility, whether the attachment can be recovered, or any permission/ownership requirement for a destructive 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?

One short sentence with the action and target front-loaded and no filler. It is efficient, though the brevity is achieved by omission rather than by disciplined editing.

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 destructive mutation with three undocumented parameters and no output schema, the description supplies almost nothing an agent needs to call it safely or correctly. The list_id ambiguity alone makes it insufficient.

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 bears full responsibility, yet it names no parameters at all. In particular the optional 'list_id' is left completely unexplained, so an agent cannot tell when it must be supplied versus omitted.

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 ('Remove') and resource ('an attachment from a To Do task'), which clearly separates it from siblings like outlook_upload_task_attachment, outlook_download_task_attachment and outlook_remove_draft_attachment. It does not explicitly name a sibling to contrast with, so it lands just 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?

There is no when-to-use or when-not-to-use guidance and no mention of prerequisites such as needing the parent task or list context. The agent must infer entirely from the verb that this is the deletion counterpart to upload/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?

The description goes well beyond the annotations by disclosing path confinement behavior, refusal of paths outside the attachments directory, that reads and writes share the same directory, that as_content writes nothing, and the 10 MB size limit.

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, compact, and structured around the two main invocation modes. Every sentence adds useful operational detail without 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 tool with no output schema and zero schema parameter descriptions, the description covers the main file-path and content-return behavior but omits the meaning of the required message_id and attachment_id parameters and does not clarify the return shape when as_content is used.

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 meaningfully explains save_path and as_content semantics, but it does not explain the required message_id or attachment_id parameters.

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

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

The description uses a clear verb and resource: download an attachment, either to save_path or returned as content. It is easy to understand, but it does not explicitly distinguish this from the sibling outlook_download_task_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?

It explains the two operating modes (save to disk vs. return content) and when as_content avoids writing, but gives no explicit guidance on when to use this tool instead of related siblings such as outlook_list_attachments or outlook_download_task_attachment.

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?

Beyond annotations, it discloses important behavior: `save_path` is constrained to the configured attachments directory, writes are atomic via temp-file-plus-replace, failed downloads do not truncate existing files, `as_content` writes nothing, and downloads are capped at 10 MB. These details materially improve safe invocation.

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, stating the primary action first and then the important write-safety and size constraints. Every sentence adds useful information; nothing is redundant.

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 download tool with annotations and no output schema, it covers the main invocation modes, path behavior, atomicity, and size limit. The remaining gap is that it does not specify the exact form of the returned content when `as_content=True`, nor does it explain `list_id`.

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 carry parameter meaning. It adds strong semantics for `save_path` and `as_content`, but does not explain `list_id`, `task_id`, or `attachment_id`, leaving three of five parameters undocumented beyond their names.

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: download a To Do task attachment, with two retrieval modes. It distinguishes itself from generic attachment or task-listing siblings by naming the exact attachment type and the local-file versus content behavior.

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 clearly explains the two modes: default save-to-file and `as_content=True` for returning content. However, it does not explicitly say when to use this tool versus related siblings such as `outlook_list_task_attachments` or `outlook_download_attachment`, leaving selection context mostly inferable.

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

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

Annotations already declare readOnlyHint=true, so the bar is lower. The description adds valuable behavior: searches the default calendar or a specified one, covers any date, and returns events and series masters (not occurrences). This clarifies return semantics beyond annotations. Lacks details like handling multiple matches or pagination, so not a 5.

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?

Four short sentences, front-loaded with the core purpose. Every sentence adds useful information: key origin, date scope, calendar behavior, and return type. No wasted words.

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

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

Given 2 parameters, one required, no output schema, and read-only annotations, the description covers what the tool does, when to use it, what it searches, and what it returns. It omits error handling or behavior when multiple events share a key, which is a minor gap.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that `key` comes from create/update and that `calendar` defaults to the default calendar. This adds meaningful semantics beyond the bare string types, though it doesn't specify key format or calendar syntax.

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+resource ('Find events by the `key`') and adds scope details ('Any date', 'Returns events and series masters, not occurrences'). It does not explicitly differentiate from siblings like outlook_get_event, but the key-based lookup is clear enough to distinguish it from list/get tools.

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

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

Provides clear context: use when you have a key from outlook_create_event or outlook_update_event. Implies no date filtering ('Any date') and mentions calendar scope. Does not state when to prefer other tools or any exclusions, keeping it at a 4 rather than 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds the three legal flag states, which is genuinely useful, but says nothing about permissions, whether existing flags are overwritten, or what happens on an invalid message_id.

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

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

Two short, front-loaded sentences with no filler. The action comes first and the parameter vocabulary second, which is the right order for an agent.

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

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

No output schema exists, so the description could reasonably say what the call returns. For a mutation tool with only annotation-level coverage, the definition is minimally adequate but leaves message_id handling and permission requirements 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 coverage is 0% and the status parameter has no enum in the schema, so the description's enumeration of 'flagged', 'complete', 'notFlagged' is a real addition beyond the structured data. However, message_id (required) receives no explanation of format or where to obtain it.

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

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

The description names a specific verb and resource ('Set the follow-up flag on a message'), which is clearly distinct from sibling operations such as outlook_mark_read or outlook_categorize_message. It does not explicitly contrast itself with siblings, but the operation is unambiguous.

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

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

There is no guidance on when to use this tool versus adjacent tools (mark_read, categorize_message, complete_task) and no prerequisites or constraints stated. The agent must infer the use case entirely from the verb.

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

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

Annotations already supply the safety profile (readOnlyHint=false, destructiveHint=true), and the description adds nothing beyond them. It is silent on key behaviors for a forward: whether it sends immediately, whether attachments and original body are carried over, whether a copy lands in Sent Items, and what permissions/scope are required.

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

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

A single front-loaded sentence with no filler or redundancy. However, the brevity comes at the cost of substance, so it reads as under-specified rather than optimally tight.

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 4 undocumented parameters, zero schema coverage, no output schema, and a mutation annotation, the description does far too little. An agent still cannot know how to format recipients, what is_markdown controls, or what the forwarding side effects are.

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% across 4 parameters, so the description must compensate and largely does not. It only loosely maps 'new recipients' to `to` and 'optional comment' to `comment`; `message_id` and especially `is_markdown` (a format flag affecting the comment rendering) are 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?

States a specific verb ('Forward') and resource ('an existing message') plus the target ('new recipients'), so an agent can tell it apart from outlook_reply and outlook_send_message. It lacks any explicit sibling differentiation, which keeps it from 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?

There is no when-to-use guidance, no statement of prerequisites (where message_id comes from, e.g. outlook_list_inbox/outlook_read_message), and no comparison to the neighboring outlook_reply, which is the closest alternative. 'Forward an existing message' implies the tool's purpose but gives no decision criteria.

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 readOnlyHint annotation already signals a safe read, so the description's remaining job is small. "full contact" adds genuine value by indicating a complete record is returned rather than a summary projection, but nothing is said about behavior on an invalid or missing ID.

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 seven-word sentence with zero filler and the key qualifier ("full", "by ID") front-loaded. It is efficiently sized, though the terseness borders on under-specification rather than optimal concision.

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 one-parameter read with readOnlyHint set and no output schema, the essentials are present. Still missing are the ID format and error behavior on a bad ID, which an agent would need to invoke this reliably.

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 single parameter has 0% schema description coverage, so the description must carry the burden and largely does not. It indicates contact_id is an identifier but gives no format (entry ID vs. email address) or example, leaving the agent to guess what constitutes a valid value.

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

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

States a specific verb ("Get") and resource ("contact") with a scope qualifier ("one full contact by ID"), which cleanly separates it from siblings like outlook_list_contacts and outlook_search_contacts. It stops short of naming those siblings explicitly, so it's clear but not fully 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?

"by ID" implicitly tells the agent this is a direct-lookup tool requiring a known identifier, which contrasts with list/search siblings. However, there is no explicit statement of when to use this versus outlook_search_contacts or outlook_list_contacts, nor how to obtain the 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?

readOnlyHint already declares the read-only profile, but the description adds substantive context beyond annotations: the returned fields (attendees with proposed_new_time, is_organizer, allow_new_time_proposals, recurrence), the UTC convention for start/end with original_start_time_zone as anchor, and that recurrence matches the create tool's shape. It stops short of stating whether cancellation still returns the record or how attachments are represented.

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?

Front-loads the invocation rule in the first sentence, then the return contract. The field enumeration is dense but each item carries actual information; only the timezone sentence is slightly compressed in a way that reads as shorthand.

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?

There is no output schema, so the description must describe return contents — and it does, listing the meaningful fields plus timezone and recurrence semantics. Combined with readOnlyHint, an agent has everything needed to call it and interpret the result.

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% and the schema has no descriptions, so the description must carry the parameter meaning — and it does, explaining that event_id reads an event while message_id reads an invitation, with a mutual-exclusion rule ('exactly one'). It doesn't state id formats or what happens if both or neither are supplied at runtime.

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 and resource ('Read an event') and covers both retrieval modes: by event_id or by message_id for an invitation. This is clearly distinguishable from list_events, list_events_delta, and find_event_by_key, which operate on keys or collections rather than a single id.

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

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

The 'exactly one' constraint tells the agent how to invoke but not when to choose this tool over siblings such as outlook_find_event_by_key or outlook_read_message. Usage is implied by the id types rather than stated with explicit alternatives 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the bar is lower. The description adds real value by naming the categories of information returned, which compensates somewhat for the missing output schema, but it says nothing about behavior with invalid addresses, maximum recipient count, or partial/empty results.

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

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

A single front-loaded clause with zero filler; the core purpose and the returned tip categories both land immediately. It reads as a fragment rather than a sentence, but nothing is wasted.

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 one-parameter, low-complexity read tool this covers the essentials, and with no output schema the tip-category list usefully sketches what comes back. It still leaves the agent guessing about result structure and edge cases, so it is adequate rather than 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 coverage is 0% for the single required parameter, so the description must carry the load. "Recipients" loosely implies the array holds email addresses, but it never confirms the expected format (SMTP address vs. UPN vs. display name), accepted count limits, or duplicate handling.

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 operation (a pre-send check) on a specific resource (recipients) and enumerates the tip categories returned (out-of-office, delivery limits, mailbox-full). It is clearly distinct from sibling send tools such as outlook_send_message or outlook_reply, though it never names a sibling explicitly.

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?

"Pre-send check" implies the usage context — call this before sending — but the description never states that explicitly, never names outlook_send_message/outlook_reply as the tools it precedes, and gives no when-not-to-use guidance (e.g., for internal-only batches).

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?

readOnlyHint=true already declares this a safe read, so the bar is lower; the description still adds real context by naming the returned fields and explaining that `checklist_items` are ordered unchecked-first to match the To Do client. It does not cover failure behavior (e.g., missing task_id or list_id), which is the only 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?

Four short sentences, front-loaded with what is returned and immediately followed by the sibling routing rule. Every sentence carries distinct information; 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?

With no output schema, the description compensates by listing the returned fields, and the checklist ordering note prevents misinterpretation of results. Only error/not-found behavior and `task_id` format are unaddressed, which is a minor gap for a two-parameter read tool.

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

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

Schema coverage is 0%, so the description must compensate — and it does for `list_id` by stating it is only required for non-default lists, plus it maps the notes field to `body`. `task_id` is left implicit as the obvious identifier, which is acceptable but not fully documented.

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 and resource ('Get full To Do task details') and enumerates the fields returned: notes (`body`), checklist items, due, recurrence flag. It also names the sibling outlook_list_tasks, so the agent can distinguish single-task retrieval from list overviews without opening either 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?

Explicitly routes the agent: 'Use this for one task's sub-steps and notes; use outlook_list_tasks for overviews.' It also gives the condition for the optional parameter ('`list_id` is only needed when the task lives in a non-default list'), leaving nothing 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful behavioral context by stating the return fields (IDs, names, sizes, content types), but it does not mention pagination, permissions, empty-result behavior, or what happens if the message has no attachments.

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 definition is a single front-loaded sentence with no wasted words. The action and return contents are stated immediately.

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

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

For a simple one-parameter read tool with a readOnlyHint and no output schema, the description covers the purpose and return fields reasonably well. However, it leaves gaps around how to obtain message_id and edge-case behavior, so it is only minimally adequate.

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 little to compensate. It implies that message_id identifies the message, but it does not explain the expected ID format, where to obtain the ID, or any constraints on the 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 gives a clear verb and resource: 'List attachments on a message.' It also states the return fields, which helps distinguish it from download_attachment and from task-attachment siblings. It does not explicitly name an alternative, but the message-scoped listing action is clear.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as outlook_download_attachment. The agent must infer usage entirely from the tool name and the fact that it returns attachment metadata.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds one useful behavioral fact — that both primary and secondary calendars come back — but says nothing about ordering, paging, or what identifying fields (IDs, names) each entry carries, which matters since downstream tools need a calendar ID.

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 sentence with the scope qualifier front-loaded after the verb; no filler, no restatement of the tool name beyond what is needed.

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

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

For a zero-parameter, read-only enumeration tool with annotations covering safety and no output schema to worry about, the description is nearly sufficient. The one missing piece is that the returned entries carry the calendar identifiers other tools require.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description's parenthetical about primary + secondary calendars is a reasonable stand-in for parameter-level 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?

States a specific verb (list) and resource (calendars) plus the scope of what is returned (primary + secondary calendars of the authenticated user). It is clearly distinct from siblings like outlook_list_events, though it never explicitly contrasts itself with the event-listing tools an agent might reach for instead.

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 call this versus outlook_list_events, outlook_list_folders, or the calendar-ID-dependent creation tools. The agent must infer that this is a discovery/disambiguation step before listing or creating events.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the meaningful detail that the returned set is the master category list with colors, but says nothing about empty-list behavior, whether defaults are included, or ordering. With annotations covering the safety profile, that is 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?

Two short sentences: the first states what is returned, the second states what it is for. Nothing is repeated from the schema or annotations, and the payoff line 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?

Simple read-only, zero-argument tool with no output schema, so the description's summary of the return shape does real work. A note about default categories or an empty result would close the last gap, but nothing essential 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?

The tool takes zero parameters, so the schema carries no semantic load and the baseline of 4 applies. The description correctly does not waste space inventing parameter guidance.

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 and resource ('list the user's master category definitions') and even enumerates the payload ('names + colors'). It also names the sibling tool that consumes this data, so an agent can place it precisely among the many outlook_* tools.

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

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

The second line gives a concrete usage trigger: fetch these values before calling outlook_categorize_message. It stops short of explicit when-not guidance or noting that this is a discovery step only, but the relational context is unusually clear for a no-argument 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds that results are cursor-paginated, which is useful behavioral context, but says nothing about ordering, what a page contains, or how to detect the end of results.

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

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

Two short sentences, zero filler, with the core purpose and the routing rule both front-loaded. Every sentence earns its place.

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

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

For a simple read-only list tool with no output schema this is nearly enough, but the completely undocumented parameters leave the agent guessing about page sizing and cursor reuse. A single clause on 'count' and cursor round-tripping would close the gap.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only gestures at 'cursor pagination' without explaining that the cursor is the token returned by a prior call, and it says nothing at all about 'count' (default 25, any max).

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 and resource ('List contacts') plus the pagination mechanism, and explicitly contrasts itself with the sibling outlook_list_contacts_delta. An agent can distinguish it from the delta variant without opening either 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?

Gives an explicit when-to-use rule ('one-shot queries') and names the alternative with the condition that selects it ('polling/recurring agents'). Nothing is left to inference about routing.

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 only readOnlyHint=true in annotations, the description supplies substantial operational context beyond the annotation: delta-token flow, tombstone handling for is_deleted=True items, and immediate draining when has_more=True. These are concrete behavioral details an agent needs.

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 purpose, then usage/alternative, then a compact example and edge-case behavior. Every sentence earns its place and adds operational value.

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 delta-polling read tool with no output schema, the description covers the key return signals: is_deleted tombstones, has_more draining, and delta_token reuse. It is not fully complete because page_size behavior remains undocumented.

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% for the two parameters. The description fully explains delta_token, including the no-argument first call and passing the prior token back, but it never explains page_size or its pagination implications, so compensation is only partial.

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 contact changes since the last call. It explicitly distinguishes this from outlook_list_contacts, making the delta/list split clear 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?

It names the intended use case (polling/recurring agents) and the alternative (outlook_list_contacts for one-shot queries). It also gives the first-call/next-call sequence and explains how to handle has_more=True.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context; it adds that results are cursor-paginated. It does not disclose sort order, whether drafts include their attachment/recipient summaries, or how the count default of 25 behaves at the boundary.

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 twelve-word sentence with the resource stated first and the pagination trait appended. Nothing is redundant and nothing is buried.

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

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

For a two-parameter read tool with no output schema and light annotations, the missing pieces are what a returned draft record looks like and how to detect the last page. The definition is adequate to call the tool but not to use the results 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%, so the description must carry the parameter burden, and it only partially does: 'cursor pagination' hints that cursor is an opaque continuation token. The count parameter (default 25, no stated maximum or ordering semantics) is left entirely undocumented in both schema and description.

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 (List) and resource (messages in the Drafts folder), so an agent can distinguish it from outlook_list_inbox and outlook_search_mail by folder scope. It stops short of explicitly naming those siblings as 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?

Usage is only implied by the resource scope: an agent can infer this is the enumeration step before outlook_update_draft, outlook_send_draft, or outlook_delete_draft, but no sentence says so. There are no explicit when/when-not conditions or named alternatives such as search_mail.

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

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

Annotations only declare readOnlyHint=true, so the description carries real weight and delivers: recurring-instance expansion, the exact field set concise mode drops and adds, and the is_online → is_online_meeting rename. The cursor continuation rule ('continues the listing it came from') is behavior an agent cannot infer from any structured field.

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?

Front-loaded with purpose, then routing, then the parameter notes — a sensible order with no filler sentences. The concise-mode sentence is dense but every clause carries distinct field-level information. Minor cost: it is longer than it needs to be for a list operation, and the trailing `calendar`/cursor notes read as an afterthought block.

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

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

No output schema exists, yet the description never characterizes the default event shape — only the deltas in concise mode — so an agent cannot anticipate what a normal result contains. Date-range semantics (default days=7, count=50 pagination behavior, whether a next cursor is returned) are also unstated, leaving real gaps for a 7-parameter read 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 compensate for 7 parameters. It does well on three: calendar (display name or ID from outlook_list_calendars, omit for default), concise (full field-level effects), and cursor (continuation semantics). It says nothing about days, after, before, or count — notably the interplay between the relative `days` window and the absolute `after`/`before` bounds, and what happens when both are supplied, is 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?

Specific verb and resource ('List calendar events') plus a scope qualifier ('in a date range') and a behavioral note that recurring instances are expanded. It also explicitly names the sibling it is not (outlook_list_events_delta), so an agent can route between the two without opening a 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?

States both when to use this tool ('one-shot queries') and when to use the alternative ('polling/recurring agents' → outlook_list_events_delta). It also gives a second conditional routing rule: pass concise=True for day-at-a-glance scans.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and delivers: cursor encoding the window, is_deleted tombstones, and the has_more drain instruction. It omits a critical delta-API behavior — what happens when delta_token is expired or invalid (full resync vs error) — which is the main operational risk here.

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?

Front-loaded purpose sentence, then routing guidance, then a concrete two-call example that earns its place by showing the exact first/next invocation pattern. Minor redundancy between the prose statement that start/end are first-call-only and the example, and the hard-wrapped lines make it slightly longer than needed.

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-param tool with no output schema and no schema descriptions, the description covers the incremental cursor lifecycle, tombstone semantics, and pagination draining — enough to call it correctly. Missing page_size guidance and expired-token/error behavior keep it short of full completeness.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for three of four params: start/end are ISO 8601 and required on the first call only, and delta_token is the cursor that supersedes the window. page_size is never mentioned despite influencing the has_more drain loop.

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 and resource ('List only calendar event changes within a window since the last call') and immediately distinguishes itself from the sibling outlook_list_events. An agent can tell incremental-sync semantics apart from a one-shot list without opening the schema.

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

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

Explicitly names the target scenario ('polling/recurring agents') and the alternative ('Use outlook_list_events for one-shot queries'), with a cost comparison to justify the choice. The when/when-not split is fully resolved.

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 readOnlyHint=true already declaring a safe read operation, the description adds useful behavior: default top-level scope, recursive full-tree behavior, and the path output relevant to folder arguments. It omits pagination/cursor behavior and does not clarify whether counts are total or unread, but it adds meaningful context beyond annotations.

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

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

The description is two compact sentences, front-loaded with the core operation and return fields, followed by the key recursive behavior. 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 simple read-only listing tool with no output schema, it covers the main behavior, default scope, recursion, and important returned fields. It is not fully complete because cursor/pagination semantics are absent and the meaning of message counts is not 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 coverage is 0%, so the description must compensate for undocumented parameters. It explains recursive well, including the default and effect, but cursor is completely unmentioned, leaving one of two parameters without any semantic guidance.

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 mail folders', and names returned fields including message counts, parent_id, and child count. It is clearly a read/list operation, distinguishing it implicitly from folder mutation siblings, but it does not explicitly differentiate itself from tools like outlook_list_inbox or outlook_list_thread.

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 clear usage context for the recursive parameter: default is top-level only, and recursive=True walks the full tree. It does not name alternative tools or conditions for choosing this over list-inbox-style siblings, so it is clear but not fully comparative.

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