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 nothing beyond them: it does not say whether the item is appended or prepended, whether calls are idempotent, or what the result contains.

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 waste. It is efficient, though its brevity is partly under-specification rather than disciplined conciseness.

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

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

For a 3-parameter mutation tool with no output schema and 0% schema coverage, the description is too thin: list_id is undocumented anywhere, and there is no behavioral context beyond what annotations supply.

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 full burden, yet it only loosely implies what display_name and task_id are and says nothing about the optional list_id. No format, ordering, or scoping detail is provided.

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

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

States a specific verb (Add) and resource (checklist item / sub-step on a To Do task). The 'add' verb implicitly distinguishes it from the sibling update_checklist_item and delete_checklist_item, though it never names them.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives such as update_checklist_item. The agent must infer usage from the verb alone.

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

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

Annotations only declare readOnly=false and destructive=false, and the description goes well beyond that: it discloses the >3MB upload-session auto-switch, the path-resolution/security rule (bare filename looked up in attachments_dir, outside paths refused), and the return of new attachment IDs. That is substantive operational context.

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

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

Front-loads the core action and size-threshold behavior before the pathing detail; every sentence carries information. The parenthetical about the default directory is dense but earns its place.

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

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

With no output schema, the description usefully states what is returned (new attachment IDs) and how they feed into removal. Combined with the path and size behavior, an agent has enough to invoke it correctly, though draft_id semantics are not 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?

With 0% schema coverage, the description compensates strongly for attachment_paths by explaining resolution rules, the bare-filename case, and the outside-path rejection. draft_id is only implied by 'existing draft', but it is a self-evident identifier, leaving only a minor 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?

States a specific verb and resource — 'Add attachments to an existing draft' — which clearly separates it from siblings like outlook_send_with_attachments and outlook_create_draft. An agent can identify its scope 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?

Usage is implied by 'existing draft' and it cross-references outlook_remove_draft_attachment for cleanup, but it never explicitly states when to prefer this over alternatives such as attaching at send time. Guidance is present but inferential.

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 tool is non-destructive, and the description aligns with that by saying 'Check.' The added remediation tip ('Run `outlook-mcp auth` on the host if needed') provides mild extra context about behavior when auth is missing, but no deep detail.

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

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

The description is one short sentence plus a concise remediation command. Every word contributes meaning, with no fluff or redundancy.

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

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

For a simple no-parameter status check, the description is mostly complete: it states what the tool does and what to do if auth is needed. It does not specify the exact output shape, but with no output schema and a simple status check, that is not a critical omission.

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

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

There are no parameters, and the schema coverage is complete by default. The description adds nothing about parameters, but with zero parameters the baseline score of 4 is appropriate.

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

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

The verb 'Check' clearly identifies a read-only status operation, and 'authentication status' is a specific resource. No sibling tool appears to overlap with this purpose.

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

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

The description explicitly notes that if auth is needed, the agent should run `outlook-mcp auth` on the host, which provides actionable remediation guidance. It does not explicitly state when to prefer this tool over siblings, but the purpose is distinct enough that this is not a major gap.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation but no destruction. Description adds batch behavior, hard cap, and example, confirming it modifies messages without being destructive.

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 concise sentences with an example, no fluff. Purpose and parameters are 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?

Covers key aspects—batch size, actions, parameters—for a mutating batch tool. No output schema, but return likely success/failure; description could mention result, but not critical.

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

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

Schema coverage is 0%, but description fully explains action values (move, flag, categorize, mark_read) and value meaning (folder name, status, category name). Example illustrates usage. Message_ids implied as list of IDs.

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

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

Clearly states it triages up to 20 messages in a batch call, with specific actions (move, flag, categorize, mark_read). Distinguishes from sibling tools that operate on single messages or other operations.

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

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

Explicitly defines batch scope and hard cap of 20, indicating bulk usage. Does not explicitly state when not to use or provide alternatives, but context implies it for batch operations instead of individual tools.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description adds the crucial detail that categories are fully replaced rather than appended — behavior not captured by the annotations. It does not, however, spell out the consequence of omitting previously set categories or any auth/rate-limit context.

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

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

Two short lines with the core semantic constraint front-loaded and a concrete example that shows valid argument shapes. No filler sentences.

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 and full annotation coverage, the description supplies the one non-obvious behavior (replacement) plus a usage example. Minor gaps remain around message_id format and error behavior.

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

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

Schema description coverage is 0%, so the description must compensate; it names both parameters in the example and explains that 'categories' is a full replacement list, which is meaningful. message_id is left entirely to inference, so it does not fully close 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?

States a specific verb (Set) and resource (categories on a message) and clarifies the replace-list semantics, which an agent could not infer from the name alone. It stops short of naming the sibling tools it complements or contrasts with (e.g. outlook_list_categories), so it is clear but not sibling-differentiating.

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

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

The parenthetical '(replaces the full list)' implies when this tool is appropriate versus an additive categorization call, but there is no explicit when-to-use/when-not guidance or reference to alternatives. Usage is only implied.

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?

Discloses key behaviors: fallback window to avoid historical items, independent tokens for each resource, auto-resync on 410 errors, and specifics about return fields (urgent_flagged, by_sender, calendar quirks). Adds value beyond readOnlyHint annotation.

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?

Description is detailed but well-organized with paragraphs and examples. Every sentence adds value, though slightly longer than minimal.

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

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

Despite no output schema, the description thoroughly explains return fields and edge cases (410 errors, resync, calendar quirks). Covers all necessary context for effective use.

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

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

With 0% schema coverage, the description fully explains both parameters: delta_tokens (object from prior response, independent per resource) and fallback_window_hours (default 24, purpose of filtering historical items).

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

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

The description clearly states it provides a 'structured digest across mail, events, and contacts' and distinguishes from sibling delta tools which return 'raw item lists or per-resource control'.

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 recommends use for 'recurring agent loops' and gives concrete usage scenarios: 'morning brief, hourly inbox sweep'. It explains when to use alternatives and provides a clear example of first call vs subsequent calls with delta_tokens.

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 indicate non-read-only and non-destructive, but the description adds no detail about side effects (e.g., whether completion is reversible, affects recurrence, or requires specific permissions). It does not contradict annotations, but transparency is minimal.

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

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

The description is a single concise sentence without redundancy, but it is too brief to cover essential information, making it feel under-specified rather than efficiently complete.

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

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

Given the lack of output schema, the description need not detail return values, but it still omits practical context such as parameter meanings, expected prerequisites (e.g., task must exist), or any side effects. Overall, it is insufficient for an agent to invoke 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?

The schema has two parameters (list_id and task_id) with no descriptions, and the tool description provides no explanation. The agent receives no semantic information about what these parameters represent or how they relate to the operation.

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

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

The description clearly states the verb 'Mark' and the object 'a To Do task as completed', which uniquely identifies the action. It is distinct from siblings like delete, update, or create tasks, though it does not explicitly contrast them.

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

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

No guidance is provided on when to use this tool versus alternatives. The description simply states the action without contextual cues such as 'when a task is finished' or 'to update task status'.

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

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

The description discloses the key behavioral trait that copying duplicates the message and leaves the source unchanged, which aligns with the annotations (destructiveHint: false). No additional context like auth or rate limits is provided, but the description adds value beyond the 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 exceptionally concise: two sentences with no redundancy. Every word serves a purpose, making it efficient for an AI agent to parse.

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

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

For a simple copy operation with no output schema, the description covers the core purpose, usage guidelines, and folder input format. It omits potential details like return values or error handling, but these are not critical given the tool's straightforward nature.

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 compensate. It does so partially by explaining that the folder parameter accepts display names, well-known names, or Graph IDs (preferring names). However, the message_id parameter is not described, leaving a 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 clearly states the action ('Copy a message to another folder') and specifies the behavior ('duplicates; source is unchanged'). It effectively distinguishes the tool from the sibling outlook_move_message by noting it does not remove the source.

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

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

The description explicitly guides the agent on when to use this tool vs. the alternative: 'Use outlook_move_message to remove from source.' It also provides practical instructions for the folder parameter, mentioning acceptable input formats.

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

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

Annotations already indicate non-destructive write. The description adds minimal behavioral context, such as any duplicate handling, permission requirements, or default folder behavior.

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

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

A single, front-loaded sentence efficiently conveys the tool's purpose with no redundant 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 6 parameters, no output schema, and no schema descriptions, the description is too minimal. It lacks information on return values, typical usage patterns, and important constraints.

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 lists key fields (email, phone, company, title) but does not explain their semantics or clarify that last_name is optional while first_name is required.

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

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

The description clearly states it creates a contact with name and optional fields, distinguishing it from sibling tools like outlook_update_contact or outlook_delete_contact. However, it does not explicitly differentiate from similar creation 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?

No guidance on when to use this tool versus alternatives like outlook_update_contact or outlook_search_contacts. The description does not specify prerequisites or 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 indicate non-read-only and non-destructive. The description adds context about the draft creation behavior, and clarifies that deferred_send_datetime holds the message server-side after sending. Does not contradict 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 four sentences, front-loaded with the core purpose. It is efficient but could be slightly more concise by removing redundant phrasing.

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

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

Given 9 parameters (3 required) and no output schema, the description provides adequate high-level context but lacks detail on optional parameters and return value expectations. It is minimally complete for a standard email draft 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. It explains only deferred_send_datetime and reply_to, but fails to describe 7 other parameters (to, subject, body, cc, bcc, is_html, importance), which are somewhat standard but still need explicit documentation for an AI agent.

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

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

The description clearly states the tool creates a draft email for later review/send and explicitly pairs it with outlook_send_draft. It distinguishes from siblings by mentioning outlook_send_message for immediate sending.

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

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

The description explicitly states when to use this tool (when human review is needed) versus alternatives (use outlook_send_message for immediate send). It also explains the deferred_send_datetime parameter for scheduling.

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 cover the safety profile (readOnlyHint=false, destructiveHint=true); the description goes well beyond them by disclosing silent-failure behavior (`is_online` is ignored on consumer accounts and returns isOnlineMeeting: False), the series-vs-single-event consequence of passing recurrence, the default busy status when show_as is omitted, and the noEnd series pitfall that invites attendees to every future occurrence. These are exactly the behavioral traits an agent must know before calling.

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

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

The purpose is front-loaded in the first sentence, followed by a concrete call example, then model-specific caveats. It is fairly long but nearly every sentence carries operational value; only minor tightening (e.g. the parenthetical REST response detail) could be trimmed.

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 11-parameter mutation tool with no output schema and thin annotations, the description supplies the semantics most likely to cause a bad call (recurrence, timezone, show_as, is_online). It does not state what is returned (e.g. the created event id) or any auth/permission prerequisites, which are minor gaps given no output schema exists.

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 full burden, and it compensates well for the non-obvious parameters: ISO 8601 for start/end, shorthand vs full Graph recurrence object with a worked example, IANA zone names ('never an abbreviation like PDT'), the show_as enum values, and the is_online caveat. It leaves body, location, and is_all_day undocumented, but those are largely self-evident from 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 opening sentence gives a precise verb+resource ('Create a calendar event') plus the optional dimensions (attendees, recurrence, busy status, online meeting), which cleanly separates it from the sibling mutators such as outlook_update_event, outlook_rsvp, and outlook_create_task. An agent can identify this 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?

The description gives conditional guidance on parameters (use a bounded recurrence range when there are attendees, prefer full Graph objects for complex patterns, is_online only works on work/school accounts), but it never states when to choose this tool over outlook_update_event or when to RSVP instead of creating. Usage context is implied rather than explicit.

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

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

Consistent with annotations (readOnlyHint=false, destructiveHint=false). Adds behavioral detail about nesting via parent_folder, which is not covered by 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?

Single sentence, front-loaded with action. Every word is necessary; no fluff.

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

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

Sufficient for a simple creation tool. No output schema needed. Implicitly uses current account context. Could mention mailbox context, but not required.

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?

Description explains the parent_folder parameter's purpose (nesting by name or ID). The name parameter is self-explanatory. Adds meaning beyond the schema, which has 0% coverage.

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

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

Clearly states 'Create a mail folder' with specific verb and resource. Distinguishes from sibling tools like outlook_delete_folder and outlook_rename_folder by focusing on creation and nesting.

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 when to use (to create a folder) and how to nest using parent_folder. No explicit when-not-to-use, but the context is clear given the sibling set.

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=false, so the description adds real value: it discloses the reminder/due dependency and the non-obvious fact that Graph silently drops a reminder with no time. It also explains relative-offset semantics and default-list fallback, though it omits auth/rate-limit context.

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

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

Front-loaded with verb, then a concrete example, then the gotchas. Dense but every sentence adds a distinct constraint; the backtick-heavy formatting is slightly cluttered but not wasteful.

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 mutation tool with no output schema and only safety annotations, the description supplies the key behavioral gotchas and most parameter semantics. It falls short on the recurrence object format and body, which an agent would need for those fields.

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 full burden and does so for due, importance (enum values), reminder, list_id, and title. It leaves body and especially recurrence (a nested object) unexplained, which is a meaningful gap given the low coverage.

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

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

States a specific verb+resource ('Create a Microsoft To Do task') and enumerates the optional attributes. The 'Microsoft To Do task' domain cleanly separates it from calendar/contact/draft creation siblings, so an agent can route without inspecting 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 self-evident create action, and the reminder/due coupling acts as a precondition. However, there is no explicit when-to-use routing against siblings like outlook_update_task or outlook_create_event, and no exclusions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write. The description restates the deletion but adds no extra behavioral context, such as whether the operation is reversible, what permissions are required, or what happens to the parent task.

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 wasted words. It is appropriately sized for a simple deletion 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 a destructive mutation with three parameters, no output schema, and 0% schema description coverage, the description is too thin. It should at least clarify the required identifiers or the effect of the deletion, even if annotations cover the safety profile.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It implies that a 'To Do task' and 'checklist item' are involved, but it does not explain the required task_id/checklist_item_id or the optional list_id, nor does it clarify identifier formats.

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

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

The description states a specific action ('Delete') on a specific resource ('checklist item') within a specific context ('a To Do task'). It also implicitly distinguishes itself from sibling tools such as outlook_add_checklist_item and outlook_update_checklist_item, which operate on the same resource.

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

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

The description gives no guidance on when to use this tool versus alternatives like outlook_update_checklist_item, outlook_delete_task, or outlook_complete_task. It also omits prerequisites or conditions, such as whether the task must be open or whether ownership is required.

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 aligns with annotations (destructiveHint=true) but does not add behavioral context beyond what annotations already provide. For instance, it does not disclose whether deletion is permanent, requires confirmation, or impacts related data. With annotations present, the description should add context but fails to do so.

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, clear sentence with no wasted words. It could potentially benefit from a bit more detail, but it remains appropriately sized for a simple 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 a tool with one parameter and no output schema, the description is minimally adequate: it states the core action. However, it lacks detail on error handling, expected response, or ID format, which limits completeness for an agent that must produce correct arguments.

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

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

Schema description coverage is 0% and the description does not explain the 'contact_id' parameter's format, source, or constraints. The agent must infer that it is an identifier without any additional 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 'Delete a contact by ID' clearly states the action (delete), the resource (contact), and the identifier mechanism (by ID), which distinguishes it from sibling tools like update, get, or create contact.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., outlook_update_contact) or any prerequisites such as the existence of the contact. The agent receives no 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 description says 'delete', which matches the destructiveHint: true annotation, but adds no further behavioral detail (e.g., irreversibility, cascading effects, or permissions). With annotations already indicating destructiveness, the description contributes no new transparency.

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

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

The description is a single, front-loaded sentence that conveys the core action efficiently. However, it is so brief that it sacrifices useful detail, making it borderline for conciseness rather than under-specification.

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 delete-by-ID operation with annotations covering destructiveness, the description is minimally adequate. It lacks prerequisites, error conditions, or return value expectations, but no output schema exists. The tool's simplicity justifies a moderate score.

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 single parameter (draft_id). The description mentions deletion 'by ID' but does not clarify the ID format, source, or validation constraints. This does not compensate for the missing parameter documentation.

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 'Delete a draft message by ID' uses a specific verb (delete) and resource (draft), clearly differentiating it from sibling tools like outlook_delete_contact or outlook_delete_event. The action and target are unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. For instance, there is no mention of conditions for deletion or distinction from outlook_update_draft or outlook_send_draft. The description lacks context for appropriate usage.

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 mark destructiveHint: true and readOnlyHint: false. The description adds valuable behavioral context: it cancels and notifies attendees if the user is the organizer. No contradiction with 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?

A single, well-structured sentence that immediately conveys the essential action and a key behavioral detail. No extraneous information, every word earns its place.

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

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

For a simple delete operation with one parameter and no output schema, the description is fairly complete. It covers the core action, the notification behavior, and the context of being the organizer. It could mention error conditions like non-existing events, but for this level of complexity, it suffices.

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 sole parameter 'event_id' lacks any description in the input schema (0% coverage). The tool description does not provide additional meaning about the parameter, such as format or source, which is expected given the low coverage.

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

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

The description clearly states the action 'Delete' and the resource 'calendar event by ID', distinguishing it from sibling tools like update_event or create_event. The additional context about attendee notification further clarifies the specific 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?

The description specifies the action and its effect but does not explicitly guide the agent on when to use it versus alternatives (e.g., canceling without notification). The context about organizer status is helpful, but explicit usage context is missing.

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. The description adds that it refuses certain folders, providing safety context beyond the annotation.

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?

Single sentence, front-loaded with action and constraint. No wasted words.

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

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

For a simple delete tool with one param and annotations covering destructiveness, the description is complete, addressing the key behavioral constraint (refusing system folders).

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 single parameter. The description says 'by ID' but doesn't specify format or how to obtain it. Minimal added meaning beyond the schema.

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

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

Description clearly states it deletes a user-created mail folder by ID and explicitly refuses well-known folders (inbox, sentitems). This distinguishes it from sibling tools like rename or create.

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

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

The description implies usage for user-created folders only, and by ID. It doesn't explicitly state when not to use, but the refusal of well-known folders provides clear guidance.

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

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

Annotations already indicate destructiveHint=true, so mutation is expected. The description does not add further behavioral details such as permanence or permission requirements, but is consistent with the 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 a single sentence that efficiently conveys the core function. It is front-loaded and has no filler, though it could be enriched with a bit more context without harming conciseness.

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

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

For a simple destructive tool with one parameter and no output schema, the description provides the minimum viable information. However, it omits how to obtain the override_id and any post-deletion effects, leaving some gaps for a complete understanding.

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% with no parameter descriptions. The description only implies the parameter is an ID by using 'by its ID', but does not explain format, source, or constraints. Minimal added value 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?

The description clearly states the action ('Delete') and the specific resource ('Focused Inbox per-sender override rule by its ID'). It is distinct from sibling tools like outlook_delete_contact which delete different resources.

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

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

No guidance is provided on when to use this tool, prerequisites (e.g., obtaining the override ID), or alternatives. The description lacks context for appropriate usage.

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 destructiveHint annotation already signals destructive behavior, and the description adds useful nuance about soft versus hard deletion. It does not detail return values or irreversibility consequences, but the essential behavioral traits are disclosed.

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

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

The description is two concise sentences with no redundant information. The key guidance is front-loaded and easy to parse.

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

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

For a simple delete operation with two parameters, the description provides enough context to use the tool correctly, including the distinction from a sibling tool. It omits output details, but that is not critical for correct invocation.

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

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

The description directly explains the permanent parameter's effect, and message_id is self-explanatory given the tool purpose. Schema coverage is limited to types and titles, but the description fills the most important semantic 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 clearly states the tool deletes a message, with a specific verb and resource. It also distinguishes this operation from the related outlook_move_message tool by explicitly warning against using move for deletion.

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

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

It explicitly says this is the canonical way to delete a message and instructs not to use outlook_move_message for deletion. It also clarifies the default soft-delete behavior and how to request a hard delete.

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 description does not need to repeat this. The description adds no extra behavioral context such as permanence or cascading effects, but it is consistent with the destructive annotation.

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

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

The description is a single, concise sentence with no superfluous words. It is well-structured and immediately conveys the tool's purpose.

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 delete operation, the description is mostly adequate, but it omits any mention of side effects (e.g., whether the deletion is permanent, whether it affects reminders or subtasks). The optional list_id parameter also raises questions about required context, which are left unanswered.

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

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

The schema provides no descriptions for task_id or list_id, and the description does not explain them. While task_id is presumably the identifier of the task to delete, list_id is optional and its purpose is unclear—whether it scopes to a specific task list or is irrelevant is not explained.

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

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

The description clearly states the action (delete) and the resource (a task from a Microsoft To Do list). It distinguishes this tool from sibling delete tools by specifying 'task', which is unambiguous.

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

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

The description does not explicitly mention when to use this tool over alternatives like outlook_complete_task or outlook_update_task. However, the operation is straightforward and self-explanatory, so some guidance is implicit in the tool name and description.

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 known. The description adds nothing beyond that restatement – it does not say whether the deletion is permanent, whether the task/list_id must exist, or whether any confirmation is required.

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

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

A single front-loaded sentence with zero filler, which is efficient for a simple operation. Its brevity is arguably under-specification rather than true conciseness, but the structure itself is clean.

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 0% schema coverage, an undocumented optional list_id parameter, and no output schema, the description is too thin. An agent cannot tell what happens on success, whether the removal is reversible, or how list_id affects the operation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It implies task_id and attachment_id, but says nothing about the optional list_id or its role, leaving a third of the inputs unexplained 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+resource ('Remove an attachment from a To Do task'), which is clear and distinct from the closest sibling outlook_remove_draft_attachment (drafts, not tasks). It does not explicitly name that sibling or any alternative, but the resource boundary 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 when-to-use guidance, no preconditions (e.g. attachment must already exist on the task), and no mention of the alternative tool for removing a draft attachment. The agent must infer usage entirely 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?

Annotations declare a non-read-only, idempotent, non-destructive write, but the description adds genuinely new behavior: bytes are decoded, the path is confined to attachments_dir, a bare filename resolves inside it, and out-of-directory paths are refused. That path-confinement/refusal rule is not derivable from the annotations or schema.

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

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

Purpose and destination are front-loaded in the first sentence, and the second paragraph is short and focused on path rules. Slightly more verbosity than needed for the 'same directory for reads and writes' note, but nothing 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?

There is no output schema, and while the write target and path constraints are covered, the description omits what the tool returns (e.g., the resolved path) and how to obtain the two IDs. Adequate but with clear gaps for a three-required-parameter 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 carries the full burden. It explains save_path thoroughly (resolution rules, bare filename, refusal), but message_id and attachment_id get no explanation of format or where they come from, leaving two of three parameters 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?

States a specific verb+resource ('Download an attachment and write the decoded bytes') and names the destination parameter, so the action and effect are unambiguous. It does not, however, distinguish itself from the similarly-named sibling outlook_download_task_attachment, which an agent could easily confuse.

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 never says when to use this tool or that message_id/attachment_id must first be obtained from outlook_list_attachments or outlook_read_message. There is no exclusion or alternative routing, only the mechanics of where files land.

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 declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description goes beyond them usefully by disclosing that save_path is sandboxed to the configured attachments directory, that the write is atomic (temp file + replace), and that a failed download never truncates an already-staged file. Auth requirements and error/return behavior are not covered, but for a download tool this is unusually informative.

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

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

Two sentences, front-loaded with the core action, and the follow-up sentence is dense with non-redundant operational detail rather than filler. Nothing reads as 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?

No output schema exists, so the description needn't explain returns, and the safety profile is annotation-covered. It communicates the destination semantics and failure behavior well; only permissions/error semantics are unaddressed, which is minor here.

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, yet it only adds meaning for save_path (resolves inside the configured attachments directory). The roles of task_id, attachment_id, and list_id are left entirely to the schema 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?

States a specific verb (Download) and resource (a To Do task attachment's content) with a clear destination (a local file). The qualifier 'To Do task' distinguishes it from the sibling outlook_download_attachment, which handles message attachments.

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 purpose implies the usage context, but there is no explicit when-to-use guidance or routing advice against the very similar sibling outlook_download_attachment. No prerequisites or preconditions (e.g., listing attachments first) 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 idempotentHint=true, so the agent knows re-flagging is safe and non-destructive; the description adds the status semantics on top. It does not mention permission requirements or what state an unflagged message returns to, but with annotations carrying the safety profile this is 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?

Two short sentences, purpose first, parameter values second. No filler whatsoever.

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 trivial two-parameter mutation with no output schema and annotations covering the safety profile, the description gives everything needed to invoke it correctly. Only usage routing and permission context are absent.

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 status has no enum constraint in the schema, so the description's enumeration of the three valid values ('flagged', 'complete', 'notFlagged') is the only place that meaning exists — this genuinely compensates. message_id is left implicit but is self-explanatory.

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

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

States a specific verb and resource: 'Set the follow-up flag on a message.' That is clearly distinguishable from siblings like outlook_mark_read, outlook_categorize_message, or outlook_move_message. It just doesn't explicitly name or contrast with an alternative.

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

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

No when-to-use guidance, no mention of prerequisites or alternatives (e.g. when to flag vs. categorize vs. mark read). The agent must infer usage from the verb alone.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates state. The description adds that the comment is optional and gets attached, but it does not clarify the critical behavior of whether forwarding sends immediately or only creates a draft, nor how attachments are handled. With annotations covering the safety profile, this is a moderate but real 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?

One front-loaded sentence with the operation and the optional parameter, no filler or redundancy. Appropriately sized for a three-parameter 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?

There is no output schema and no annotation detail beyond the safety flags, so the description should say more about the outcome of the call (e.g. does it return the new message id, does it send instantly). As written it is adequate to call the tool but incomplete about consequences, which matters for a send-type mutation.

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

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

Schema description coverage is 0%, so the description must carry the param burden. It explains 'to' (new recipients) and 'comment' (optional), but leaves message_id completely undescribed beyond the weak implication of 'an existing message'. Two of three parameters are covered, but no format or type guidance is added.

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') and names the target ('new recipients'), which an agent can readily separate from outlook_reply and outlook_send_message. The only gap is that it never names those siblings explicitly, relying on the reader to infer the distinction.

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

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

The phrase 'to new recipients' implicitly signals the forwarding use case versus replying to the original sender, which is useful context. However, there is no explicit when-to-use guidance, no prerequisites (e.g. requires an existing message_id), and no named alternatives despite 60+ sibling tools.

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

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

The annotations include readOnlyHint=true, indicating a read operation. The description's 'Get' aligns with this. It adds the detail 'full contact', implying the returned data is comprehensive, which is useful beyond the annotation.

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

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

The description is a single sentence with five words, extremely concise and front-loaded. Every word adds value with no redundancy.

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

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

For a simple get-by-ID tool with one parameter and annotations present, the description is nearly complete. It lacks details on the return structure, but given no output schema, it is adequate for an agent to understand the tool's purpose.

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%. The description mentions 'by ID' but does not explain the format or source of contact_id. For a single required parameter with no schema description, more context would be beneficial.

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

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

The description clearly states the verb 'Get', the resource 'contact', and the scope 'one full contact by ID'. It distinguishes from sibling tools like outlook_list_contacts (list) and outlook_search_contacts (search).

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

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

The description does not explicitly provide when to use or when not to use this tool versus alternatives. The context is implied from the purpose, but there is no explicit guidance or mention of related tools.

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

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

With readOnlyHint=true already covering the safety profile, the description adds genuinely useful behavioral detail about the return shape: recurrence mirrors what outlook_create_event accepts, the type discriminator values are enumerated, and the timezone semantics of start/end versus original_start_time_zone are explained. It stops short of covering failure modes (missing ID, permissions), but the added value beyond annotations is substantial.

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

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

Front-loads purpose plus returned fields in one line, then a short second block for return-value semantics. Dense but every sentence earns its place; no padding or restatement of the tool 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?

With no output schema, the description usefully explains the return payload's timezone and recurrence semantics, which an agent needs to interpret results. It is nearly complete for a simple read, though error and permission behavior for an unknown or inaccessible ID is 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?

Schema description coverage is 0% for the single event_id parameter, so the description must carry the load and only says retrieval is 'by ID' without format or source guidance. It adds no syntax beyond the schema's string type, though the one-parameter simplicity keeps this from being a serious 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?

States a specific verb and resource ('Get one event by ID') and immediately enumerates the payload an agent can expect: body, attendees, organizer, recurrence, type, show_as, anchor zone. This cleanly distinguishes it from sibling list tools like outlook_list_events and outlook_list_events_delta.

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 never says when to reach for this tool versus outlook_list_events, outlook_list_events_delta, or outlook_get_task. Retrieval-by-ID is implied by the name and schema, but no explicit context, prerequisites, or alternatives are offered.

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

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

The description discloses that the tool performs a read-only check (consistent with readOnlyHint annotation) and specifies the type of information returned. No contradictions with annotations. It adds context beyond the annotation by detailing the check 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?

The description is a single sentence that concisely conveys the tool's purpose and behavior. Every word adds value, with no filler or redundancy.

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

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

Given the simple input (one array parameter) and readOnlyHint annotation, the description adequately explains the tool's function. It could optionally mention that tips are returned per email, but the current description is sufficient for an agent to invoke the tool correctly.

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

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

The input schema has one required parameter, 'emails', with 0% description coverage. The description mentions 'recipients' but does not explicitly name the parameter or add meaning about its format (e.g., array of email addresses). The single parameter is somewhat obvious, but the description fails to clarify the expected input structure.

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

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

The description clearly states the tool is for a 'pre-send check' for recipients, listing specific types of mail tips (out-of-office, delivery limits, mailbox-full warnings). This is a distinct purpose that separates it from sibling tools, which involve reading, drafting, or sending messages.

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

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

The description implies usage before sending emails to check recipient status. It indicates context ('pre-send') but does not explicitly state when not to use it or suggest alternatives. However, among sibling tools, sending tools are present, providing indirect guidance.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds real behavioral context beyond that: checklist_items are returned ordered unchecked-first 'matching the To Do client', and list_id is only needed for non-default lists. It stops short of covering failure modes (e.g., behavior when task_id is not found).

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, zero filler, with the returned-field list front-loaded before the usage routing and the list_id caveat. Every sentence carries distinct information.

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

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

With no output schema, the description correctly enumerates the returned fields (body/notes, checklist items, due, recurrence flag), which is what an agent needs to interpret results. It covers the required task_id implicitly and the optional list_id explicitly; only a note on error behavior or task_id format is missing.

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

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

Schema description coverage is 0%, so the description carries the burden. It successfully explains list_id's conditional nature ('only needed when the task lives in a non-default list'), which is genuine added meaning, but task_id is left entirely unexplained. One of two parameters is covered, so it is only partial compensation.

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 (To Do task details) and enumerates the returned fields: notes/body, checklist items, due, recurrence flag. It explicitly names outlook_list_tasks as the overview alternative, so an agent can distinguish it from the sibling 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?

Gives clear routing: use this for one task's sub-steps and notes, use outlook_list_tasks for overviews. It covers when-to-use and one named alternative, but does not address other task siblings such as outlook_update_task or outlook_complete_task, so there is no explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds return field details but omits potential errors, pagination, or size limits. With annotations covering the core safety, this 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?

Single sentence with no wasted words. Front-loaded with verb and resource, then return details. Perfectly concise.

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

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

For a simple list tool with one parameter, the description is fairly complete: it states the action and return fields. No output schema exists, but the description compensates partially. Missing details like authentication or response format, but the system context likely covers those.

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 description must explain parameters. The description does not mention message_id at all; it only says 'on a message'. The parameter name is self-descriptive, but description fails to add explicit meaning. This is a 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?

Description clearly states verb 'list', resource 'attachments on a message', and enumerates returned fields (IDs, names, sizes, content types). This distinguishes it from siblings like outlook_download_attachment (downloads) and outlook_attach_to_draft (adds).

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?

Context is clear: use to list attachments given a message_id. However, no explicit guidance on when not to use or alternatives beyond the name itself. The description provides sufficient context for a simple 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?

The description adds behavioral details beyond the readOnlyHint annotation by specifying that it returns primary and secondary calendars. Annotations already indicate read-only, so the description supplements without contradiction.

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

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

The description is a single, concise sentence that immediately conveys the tool's purpose. No extraneous words or information, perfectly front-loaded.

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

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

Given the tool has no parameters, no output schema, and annotations provide safety context, the description is complete. It fully informs the agent of what the tool does and its scope.

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

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

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter information. According to guidelines, baseline is 4 for 0 parameters, and no additional param info is needed.

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

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

The description clearly states 'List all calendars available to the authenticated user (primary + secondary).' It uses a specific verb 'List' and resource 'calendars', and distinguishes itself from sibling tools by specifying the scope and inclusion of primary and secondary calendars.

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

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

The description implies that this tool is used when you need a list of all calendars, which is a simple and clear use case. However, it does not explicitly mention alternatives or when not to use it, but given there are no parameters and the purpose is straightforward, it's sufficiently clear.

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

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

The readOnlyHint annotation is present, and the description confirms a read-only operation ('List'). No contradictions, and the description adds context about return values (names+colors).

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

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

Two sentences, front-loaded with the core action. No wasted words, and the second sentence adds valuable context about its relationship to another 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?

Given no parameters, no output schema, and a readOnlyHint annotation, the description is complete: it states what is returned and why it is useful.

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

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

The input schema has zero parameters with 100% coverage (by default). The description does not need to add parameter info, and the baseline for 0 parameters is 4.

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

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

The description clearly states the action ('List the user's master category definitions') and the output (names + colors). It also distinguishes its purpose by noting it provides valid values for another tool (outlook_categorize_message).

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

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

The description implies when to use the tool (before categorizing a message to get allowed categories) and references a sibling tool (outlook_categorize_message). It does not explicitly state when not to use it, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, describing a safe read operation. The description adds the cursor pagination detail. Otherwise no extra info on rate limits, permissions, or other behavioral traits. Adequate but minimal 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?

Two clean sentences with no wasted words. Front-loaded with core functionality, then usage distinction. Ideal conciseness.

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

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

The description is adequate for a simple list tool with pagination, but lacks details about what the tool returns (e.g., list of contacts). Given no output schema, some mention of the response would improve completeness.

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

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

Schema coverage is 0%, so description must add meaning. It mentions 'cursor pagination' which loosely relates to the cursor parameter, but provides no explanation of count, cursor format, or how they work. Very limited added value.

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

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

The description clearly states the tool lists contacts with cursor pagination (verb+resource+pagination). It hints at a different use vs. the delta variant, but doesn't explicitly distinguish from other contact listing tools like outlook_search_contacts.

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 says when to use this tool (one-shot queries) and when to use an alternative (outlook_list_contacts_delta for polling/recurring). This is clear and differentiation guide.

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 mark readOnlyHint=true, and description adds important behavioral details: tombstones (is_deleted=True items should be dropped), pagination (has_more means drain immediately), and cost implications. No contradictions.

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?

Extremely concise yet comprehensive. First sentence clearly states purpose, followed by usage guidance, example, and edge cases. Every sentence adds value with no redundancy.

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

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

For a delta/polling tool with no output schema, the description sufficiently covers return behavior (tombstones, has_more), pagination strategy, and cost benefits. Complete enough for effective use.

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

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

Schema coverage is 0%, so description must compensate. It explains delta_token as a token from prior response and the has_more pattern, but does not detail page_size defaults or ranges. Adequate for context.

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

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

Description clearly states 'List only contact changes since the last call' with a specific verb and resource. It distinguishes itself from sibling tools like outlook_list_contacts (full list) and outlook_list_events_delta (different resource).

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 recommends use for polling/recurring agents, notes cost advantage over outlook_list_contacts, and advises using outlook_list_contacts for one-shot queries. Provides example usage and explains pagination with has_more and delta_token.

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 indicates a read-only operation. The description adds the behavior of cursor pagination, which is useful implementation detail beyond the annotation.

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

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

The description is a single, concise sentence with no unnecessary words. It is well-structured and to the point.

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

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

While the basic purpose is clear, the description does not mention ordering, default count, how to obtain the next page, or any additional behavior. Combined with the lack of parameter details, the context is somewhat incomplete for an agent to use it effectively without additional inference.

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

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

The schema lacks descriptions for count and cursor, and the description only mentions 'cursor pagination' without explaining how the parameters work. This leaves the agent guessing about parameter semantics, especially since schema coverage is 0%.

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

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

The description clearly states the tool lists messages in the Drafts folder, which is a specific verb and resource. It differentiates from sibling tools like outlook_list_inbox and outlook_list_folders by specifying the Drafts folder.

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

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

The description indicates the purpose but does not explicitly state when to use this tool versus alternatives. No when-not guidance is provided, though the tool name and context give some implicit clues.

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 readOnlyHint=true by disclosing that recurring instances are expanded, the exact field-level effects of concise=True (drops organizer/response_status/type/show_as, adds is_organizer/attendees_count, renames is_online), and that a cursor only continues the listing it came from.

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 the sibling rule, then tight, information-dense clauses. No filler sentences; every line adds an actionable fact.

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 concise-mode field mapping usefully substitutes for describing the return shape, and recurring expansion plus cursor semantics are covered. However, pagination/count limits and the date-parameter formats are unaddressed, leaving how the range is actually computed ambiguous.

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 carries the burden and does well for the non-obvious params: calendar (display name or ID from outlook_list_calendars, omit for default), concise (full field mapping), and cursor (continuation semantics). It leaves days/after/before/count unexplained, including their formats and how they interact, which is the tool's central range-selection logic.

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+scope: 'List calendar events in a date range (expands recurring instances).' It also explicitly names the sibling it is not (outlook_list_events_delta), so an agent can distinguish it 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?

Explicit routing rule: 'Use for one-shot queries; use outlook_list_events_delta for polling/recurring agents.' It adds a second conditional for concise mode ('day-at-a-glance scans') and clarifies cursor reuse, covering when-to-use and which alternative to pick.

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 annotation already indicates readOnlyHint=true. The description adds useful behavioral context: explains the delta token mechanism, first-call requirements, and the meaning of is_deleted and has_more fields. No contradictions.

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 (4 sentences plus example) and front-loaded: purpose first, then usage guidance, then example, then additional notes. Every sentence adds unique value with no redundancy.

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

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

Given the complexity of a delta endpoint and the absence of an output schema, the description covers the key behaviors (paginated result, is_deleted tombstones, has_more flag). It could be slightly more explicit about the response structure (e.g., that it returns event objects), but is largely sufficient.

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 full burden. It explains start/end (required on first call, ISO 8601), delta_token (used subsequently), but does not describe page_size. This covers 3 of 4 parameters with meaningful context.

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 explicitly states it lists 'calendar event changes within a window since the last call,' which is specific and actionable. It clearly distinguishes from the sibling tool outlook_list_events by positioning this as the delta/change-tracking variant.

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

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

Provides explicit guidance: 'Use this for polling/recurring agents — typically 10x cheaper than outlook_list_events after the first call. Use outlook_list_events for one-shot queries.' This directly tells the agent when and when not to use the 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. The description adds behavioral context about recursion resolving subfolder names. No mention of pagination or performance, but adequate for a read-only list tool.

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

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

Two sentences, no redundant words. Front-loaded with purpose and key details. Efficient and clear.

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; the description lists returned fields (message counts, parent_id, child count) adequately. However, the cursor parameter is not addressed, and some potential behavior like pagination is omitted.

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%. The description explains the recursive parameter but does not mention the cursor parameter, leaving its purpose unclear. Only one of two parameters is 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?

The description clearly states the tool lists mail folders and specifies the returned data (message counts, parent_id, child count). It distinguishes from siblings like outlook_create_folder or outlook_delete_folder by focusing on read-only listing.

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

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

The description explains default behavior (top-level only) and when to use recursive=True. It doesn't explicitly state when not to use the tool, but the context of siblings makes usage clear.

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

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

Annotations supply readOnlyHint=true, so the safety profile is covered, but the description adds genuinely non-obvious behavioral context: concise=True drops large fields for ~10x token savings, uncategorized_only filtering, and the accepted forms for `folder`. It stops short of describing pagination/cursor behavior or default page size, which is the remaining 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?

Front-loaded with the core purpose before routing guidance, examples, and parameter notes; each sentence carries distinct information. It is somewhat long, but no line is padding given the 0% schema coverage it must compensate for.

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 11-parameter list tool with no output schema, the description covers routing, token-cost tradeoffs, filter semantics, and date formats well. The notable omission is pagination behavior (cursor/skip) and any statement about result ordering or limits, which an agent browsing large folders would need.

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 largely meets it: it clarifies `folder` accepted formats, the effect of concise and uncategorized_only, and the ISO 8601/relative-offset semantics of after/before. However cursor, skip, from_address, and classification receive no explanation, leaving several of the 11 params undocumented anywhere.

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 messages) plus its scope constraint (one folder) and the filter dimensions it supports (read, sender, date, category, Focused). It explicitly names sibling tools it is not (outlook_search_mail for cross-folder full-text, outlook_list_inbox_delta for polling), so an agent can distinguish it without reading 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?

Provides explicit when-to-use routing: folder-scoped browsing vs outlook_search_mail for KQL search across all folders, and a concrete condition for choosing outlook_list_inbox_delta (polling/recurring agents, ~10x cheaper after first call). Includes a worked example invocation.

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 is consistent with the description. The description further explains behavior around tombstones (is_deleted) and pagination (has_more), giving the agent a clear mental model of the response semantics.

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

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

The description is compact and well-structured, with every sentence serving a purpose: usage guidance, example, and pagination semantics. No fluff or repetition.

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

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

The description covers the essential delta and pagination behavior despite the lack of an output schema. It could be slightly more complete by describing the return items more explicitly, but the core usage is fully understandable.

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

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

The description explains delta_token's role through the example, but folder and page_size are not described beyond their schema titles/defaults. Since schema description coverage is 0%, more parameter-level detail would be beneficial.

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

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

Clearly states the tool lists inbox changes since the last call, with a specific verb and resource. It also distinguishes itself from outlook_list_inbox by noting cost and appropriate use cases.

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 says when to use this tool (polling/recurring) versus outlook_list_inbox (one-shot snapshots). Provides a concrete usage example for the first and subsequent calls, plus pagination instructions via has_more and delta_token.

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 explains the meaning of the override rules themselves, but it does not disclose the tool's own behavior beyond listing. It lacks details about the return format, pagination, or explicit confirmation that no modifications occur, though the readOnlyHint annotation partially covers this.

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

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

The description is concise, consisting of two short sentences that directly state the purpose and clarify the domain concept. There is no unnecessary information.

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

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

For a simple list operation with no parameters, the description sufficiently explains what the tool does and what the data represents. It provides enough context for an agent to understand when to call it, and the readOnlyHint annotation covers safety expectations.

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

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

The tool has no parameters, so there is nothing to explain. The description does not need to add any parameter-related semantics.

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

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

The description clearly states the verb 'List' and the specific resource 'the user's Focused Inbox per-sender override rules'. It further explains what an override does, making the tool's purpose unambiguous.

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

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

The description does not explicitly mention when to use this tool versus alternatives like set_inbox_override or delete_inbox_override. While the list operation is self-explanatory, no direct guidance is provided about using this for viewing overrides or modifying them with sibling tools.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the pagination contract ('has_more=True means pass next_cursor back for the next page') and the shape of returned items. It omits details like default page size or cursor lifetime.

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 in the first clause, and the two following sentences each deliver a distinct actionable fact (download routing, pagination). 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?

With no output schema, the description correctly enumerates the returned fields and the pagination flag, so an agent knows what it gets back. It is nearly complete, missing only coverage of the optional 'list_id' parameter and the 'count' control.

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 full burden. It explains the pagination cursor ('next_cursor' back-and-forth) and implies 'task_id' via 'on a To Do task', but 'list_id' and 'count' are never mentioned, leaving two of four parameters undocumented anywhere.

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 attachments on a To Do task') and enumerates the returned fields (id, name, size, content_type). It is clearly distinguishable from the sibling 'outlook_download_task_attachment', which it explicitly names as the follow-up.

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_download_task_attachment' with an id from this result to save content, which is a concrete when-to-use-next instruction. It does not state any when-not conditions or prerequisites (e.g., task must exist), so it stops short of a 5.

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

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

The description adds context beyond the readOnlyHint annotation by specifying the scope ('for the current user'). It confirms no destructive effects and aligns with 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?

A single sentence that is concise and front-loaded with the action and resource. Every word is necessary and informative.

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 no-parameter read-only listing tool, the description is complete. It tells what the tool does, its scope, and its safety. No output schema is needed as return format is standard.

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?

No parameters exist, so the schema coverage is 100%. The description does not need to add parameter details, and the baseline score of 4 is appropriate.

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

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

The description clearly states the verb 'List' and resource 'task lists', and the name 'outlook_list_task_lists' is specific. It distinguishes from sibling tools like 'outlook_list_tasks' which lists tasks within a list.

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

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

The description implies use when you need all task lists for the current user. It does not explicitly state when not to use it or mention alternatives, but for a simple list operation this is sufficient.

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, consistent with 'list'. Description adds no further behavioral details (e.g., pagination behavior via cursor, count defaults). It does not contradict annotations.

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

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

Two sentences, no extraneous information. Essential facts front-loaded. Every sentence adds 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?

Lacks details on pagination (cursor, count defaults), return format, and the role of list_id. For a list tool with no output schema, this is insufficient for full understanding.

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 description must explain parameters. It only documents the 'status' parameter with allowed values. 'count', 'cursor', and 'list_id' are not explained, leaving 3 of 4 parameters underspecified.

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

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

Description clearly states the action 'list tasks', the resource 'in a To Do list', and the optional 'status' filter. It distinguishes from sibling tools like outlook_list_task_lists by specifying tasks within a list.

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

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

No guidance on when to use this tool versus alternatives (e.g., outlook_list_task_lists, outlook_create_task). The description only mentions an optional filter but does not explain prerequisites or exclusive 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?

Description explains ordering (chronological) and the effect of the concise parameter, adding behavioral context beyond the readOnlyHint annotation. No contradictions.

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 sentences, front-loaded with purpose, followed by prerequisite and a performance tip. No unnecessary 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?

Covers ordering, prerequisite, and concise hint. Does not mention pagination or maximum results, but for a straightforward list tool with annotations, it is nearly 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?

Explains conversation_id (prerequisite) and concise (effect), but does not explain the count parameter (default 50). With 0% schema description coverage, the description partially compensates but leaves a 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?

Description clearly states 'List all messages in a conversation thread, chronological order.' It uses a specific verb and resource, distinguishing it from siblings like outlook_read_message (single message) or outlook_list_folders.

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 mentions prerequisite 'Needs conversation_id from a message's metadata' and provides a tip for using concise=True on long threads. Does not compare to siblings or state when not to use, but context is clear.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety/mutation profile is covered. The description adds only the "single message" scope and restates the boolean semantics, leaving permissions, side effects, and response behavior undisclosed.

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 tight sentence with the action front-loaded and no wasted words. It is efficiently sized for a simple two-parameter 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 a simple toggle tool with no output schema and annotations covering safety, the description is minimally adequate but omits any guidance on message_id validity, error behavior, or relationship to sibling read tools.

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

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

Schema description coverage is 0%, so the description carries the burden. It clarifies that is_read toggles read vs unread, but message_id is never explained and no format/constraint details are added for either 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?

States a specific verb and resource ("Mark a single message as read or unread") and scopes it to a single message, which implicitly separates it from batch or content-reading siblings. It does not explicitly name the alternative such as outlook_read_message, so it falls short of full sibling differentiation.

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 and no exclusions, so an agent gets no help distinguishing it from siblings like outlook_read_message or outlook_flag_message. Usage is only inferable from the verb 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?

The description explicitly states 'removes from source', making the destructive nature of the operation clear, which is not fully captured by the annotations (destructiveHint: false). This transparency helps the agent understand the side effect of moving.

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

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

The description is concise, with two sentences: the first states the purpose and effect, the second provides usage alternatives and parameter details. No redundant information, 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?

The description covers the core purpose, effect, alternatives, and parameter behavior. No output schema is provided, but the tool's return is not complex. The description is sufficient for an agent to decide when and how to use this tool correctly.

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

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

The folder parameter is well explained (display names, well-known names, Graph IDs, prefer names), adding value beyond the schema. The message_id parameter is not described but is self-explanatory as a message identifier. Since schema coverage is 0%, the description compensates for one of two parameters adequately.

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