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

Goes well beyond annotations: it discloses a path-resolution rule (paths resolve inside attachments_dir, bare filenames looked up there, paths outside refused), an automatic fallback behavior (>3MB switches to upload-session), and the return value (new attachment IDs). These are exactly the behavioral traits that make or break a correct call.

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 focused sentences; the core action and the >3MB threshold are front-loaded, then the path-resolution rule, then the return value. The parenthetical default (~/.outlook-mcp/attachments) is useful, not filler. Slight density but no waste.

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 2-param mutation with no annotations beyond the safety hints, the description covers what it does, how paths resolve, the large-file fallback, and what it returns. It leaves no meaningful gap an agent would need to call this correctly.

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

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

Schema coverage is 0%, so the description must carry the full burden. It clearly explains the semantics of attachment_paths (resolution relative to attachments_dir, default location, refusal of out-of-tree paths) and implies draft_id targets an existing draft. This fully compensates for the missing schema descriptions.

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

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

Specific verb (add) + resource (attachments) + scope constraint (existing draft), and it distinguishes itself from siblings like outlook_send_with_attachments and outlook_list_attachments. The mention of 'auto-switches to upload-session for files >3MB' further pins down exactly what this tool does.

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

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

Clear implied context: it operates on an existing draft, and it points to outlook_remove_draft_attachment as the follow-up inverse action. It doesn't explicitly exclude anything (e.g. use outlook_create_draft vs this tool) but the draft-scoped framing is strong enough to route the agent correctly.

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?

The description discloses significant behavioral details: is_online is silently ignored for personal accounts (returning false), recurrence creates a series rather than a single event, and range.startDate defaults to the event start. These go beyond the annotations (readOnlyHint false, destructiveHint false) and help set expectations for the tool's side effects.

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

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

The description is detailed but well-organized: it leads with the main purpose, includes an example, then covers caveats and complex recurrence syntax with a concrete JSON example. Every sentence adds value — no fluff or repetition. The structure is logical, from basic usage to advanced edge cases.

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 create tool with optional complex recurrence, the description covers the essential edge cases: personal vs. work/school accounts for Teams, recurrence series behavior, and the importance of bounding series with attendees. It also clarifies date formats and defaults. No output schema exists, so return format isn't expected. The description is complete enough to call the tool correctly without additional context.

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

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

The schema has zero parameter descriptions (0% coverage), but the description explains the non-obvious parameters: start/end are ISO 8601, recurrence accepts a shorthand or full Graph object, and is_online is a no-op on personal accounts. It also clarifies attendees in context of recurrence. Self-explanatory parameters like subject, location, body, and is_all_day are left to inference, which is acceptable given their obviousness.

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 calendar event and lists optional features (attendees, recurrence, Teams meeting). The verb 'create' and resource 'calendar event' are specific, and the example further clarifies the action. This distinguishes it from siblings like outlook_update_event, outlook_delete_event, and outlook_list_events.

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

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

The description provides practical guidance, such as warning that is_online has no effect on personal accounts and that recurrence creates a series. It also recommends bounded ranges when attendees are present. However, it does not explicitly contrast with alternatives (e.g., 'use this for new events, not for updates'), though the tool name and purpose make that clear. Lacks an explicit when/when-not statement but gives useful caveats.

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?

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 only give the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description adds real context the annotations cannot: bytes are decoded before writing, save_path is sandboxed to attachments_dir, and out-of-directory paths are refused. It stops short of auth requirements or overwrite/error behavior, but the write-scope disclosure is substantive.

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 core action is front-loaded in the first sentence, with the save_path constraints following. All sentences carry information, though the path-sandboxing detail is slightly belabored.

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-required-param mutation with 0% schema coverage and no output schema, the save_path behavior is well covered, but the two identifier parameters and the failure/overwrite outcome are left unspecified, leaving gaps for correct invocation.

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

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

Schema coverage is 0%, so the description must carry all three parameters, but it only explains save_path (bare filename resolution, sandbox refusal). message_id and attachment_id remain entirely undocumented in both schema and prose.

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 (an attachment) plus the concrete effect (write decoded bytes to save_path on the host). This differentiates it cleanly from siblings like outlook_list_attachments (read metadata) and outlook_attach_to_draft (upload direction).

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

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

The description never says when to prefer this tool or how to obtain message_id/attachment_id (e.g. via outlook_list_attachments), nor any exclusions. Usage is only inferable from the verb, with no explicit routing guidance.

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

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

Annotations already declare 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?

The description states the core action (forwarding) which implies side effects like sending an email. It does not explicitly mention consequences such as creating a new message or whether the original is modified, but the annotation readOnlyHint=false already indicates non-read-only behavior, so the description adds limited extra 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 concise sentence that efficiently conveys the tool's purpose without any fluff or redundant details.

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

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

For a simple tool like forwarding a message, the description is largely sufficient to understand its function and inputs. It lacks broader context about when to use it, but given the simplicity, it is adequately complete.

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

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

The description references 'new recipients' and 'optional comment', which maps to the 'to' and 'comment' parameters, but it does not explicitly explain 'message_id'. Since the schema lacks per-parameter descriptions, the description provides partial coverage but not enough to fully understand all three parameters without additional 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 clearly states the action: forwarding an existing message to new recipients. The verb 'forward' and object 'existing message' are specific, and it distinguishes from sibling tools like send or reply by focusing on forwarding.

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 but provides no explicit guidance on when to use this tool over alternatives like outlook_send_message or outlook_reply. No conditions or comparisons are given, leaving the agent to infer the appropriate context.

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

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

The annotations 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?

The readOnlyHint annotation already establishes the operation is non-destructive. The description additionally explains output behavior (recurrence shape matches create_event input, type values are enumerated), which helps the agent understand what to expect. No side effects or error conditions are mentioned, but none are necessary for a simple read.

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

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

The description is concise and front-loaded: it states the core action and return fields in one sentence, then adds a brief clarifying note about recurrence and type. No redundant or extraneous information is present.

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 operation, the description is complete. It lists the key returned fields, explains the recurrence shape, and enumerates the type values. This is sufficient for an agent to call the tool and interpret the result without an output schema.

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

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

The only parameter, event_id, is self-explanatory, but the description provides no additional context such as where the ID originates (e.g., from list_events) or format expectations. While not critical for such a simple parameter, the description could have added value by clarifying the ID source.

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 ('Get one full calendar event by ID') and enumerates the specific data returned (body, attendees, organizer, recurrence, type). This unambiguously distinguishes it from sibling tools like list_events (which lists summaries) and create/update/delete operations.

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

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

The description implicitly indicates the appropriate use case: retrieving a single event when you have its ID. Though it doesn't explicitly contrast with list_events or other alternatives, the specific 'by ID' wording and the enumerated full fields make it clear when this tool is the right choice.

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?

The description adds that the tool returns authentication status, which goes beyond the readOnlyHint annotation. However, the annotation already declares the tool as read-only, and the description does not disclose additional behavioral traits like potential delays or side effects. The added value is modest.

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, front-loaded, and contains no wasted words. It 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, parameterless list tool, the description is adequate. It explains the output (accounts and auth status), which suffices for basic understanding. No output schema exists, so additional detail on return format could be beneficial but is 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?

No parameters exist, so schema coverage is 100% vacuously. Per guidelines, baseline is 4. The description adds value by specifying what the tool returns (accounts and authentication status), which is helpful for an 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 lists all configured Outlook accounts and their authentication status, using a specific verb ('List') and resource ('accounts'). It is distinct from sibling tools, which focus on other operations like sending drafts or managing 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?

No explicit guidance on when to use this tool versus alternatives. However, given the tool has no parameters and lists accounts, the intended use is straightforward. Sibling tools like outlook_switch_account imply a different purpose, but exclusion criteria are not stated.

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

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

Annotations already declare readOnlyHint=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?

Annotations declare readOnlyHint=true, which is consistent. Description adds behavioral traits: expands recurring instances and mentions the concise parameter drops large fields (body, attendees, organizer, categories) for ~10x fewer tokens. 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 concise sentences with no fluff. Front-loaded core purpose, then usage guidance, then parameter hint. 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?

Describes key behavioral trait (recurring expansion) and concise mode, but lacks explanation of return values (no output schema) and other parameters. For a list tool with 6 parameters, marginally sufficient but not exhaustive.

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 compensate. It only explains the 'concise' parameter (its effect and token savings). Other parameters (days, after, before, count, cursor) are not elaborated, leaving meaning uncovered.

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 'List calendar events in a date range (expands recurring instances).' This clearly identifies the verb (list), resource (calendar events), and scope (date range, recurring expansion). It distinguishes from sibling tools like outlook_list_events_delta and outlook_rsvp.

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 'Use for one-shot queries; use outlook_list_events_delta for polling/recurring agents.' This provides clear when-to-use and when-not-to-use guidance with a named alternative.

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?

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.

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

The description clearly states the verb 'Move' and the resource 'message', and explicitly distinguishes from copy and delete operations. It also clarifies that moving removes the message from the source folder, making the purpose unambiguous.

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

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

Provides explicit guidance on when to use sibling tools: use outlook_copy_message for duplication, outlook_delete_message for deletion, and warns against using move to 'deleteditems' as a deletion method. Also explains the folder parameter accepts display names, well-known names, or Graph IDs, with a preference for names.

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

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

Beyond the readOnlyHint annotation, the description discloses that concise=True drops large fields and returns a preview, and include_deferred_send returns scheduled-send time. 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?

The description is efficient: a two-sentence intro plus two brief bullet points. Front-loaded with core purpose, no wasted words.

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

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

Given no output schema, the description covers parameter effects and return modifications. Could mention default response structure, but the detail provided is sufficient 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?

Since schema coverage is 0%, the description compensates by explaining format values, concise behavior, and deferred send parameter. Message_id is self-explanatory. Adds necessary 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?

The description clearly states the tool retrieves one full message by ID, with specific format options. This distinguishes it from sibling tools like outlook_list_thread or outlook_download_attachment.

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

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

The description provides guidance on when to use concise mode for token-saving triage and include_deferred_send for scheduled times. However, it lacks explicit contrast with alternatives like outlook_batch_triage or when not to use this tool.

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

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

The readOnlyHint annotation covers the read-only nature, and the description adds useful behavioral details: ordering follows input message_ids, partial 404s are surfaced in failures, and the call does not fail entirely. Minor gap: no mention of auth requirements or rate-limit consequences beyond the $batch cap.

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

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

The description is tight and well-structured, with a clear purpose, return shape, example, and limit. The formatting is efficient and every sentence adds relevant 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 bulk read tool, it adequately covers return shape, partial failures, ordering, and limits. It does not provide an output schema, but the return keys are listed and the per-message shape is delegated to a sibling tool, which is reasonable given the context.

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

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

The schema has no parameter descriptions, and the description only partially compensates. It explains message_ids ordering and references outlook_read_message for format, concise, and include_deferred_send semantics, but does not define those parameter values or effects directly.

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

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

The description clearly states the tool's purpose: bulk reading up to 20 messages by ID via $batch. It explicitly distinguishes itself from the single-message counterpart by saying to use this instead of N individual outlook_read_message calls.

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 provides explicit usage guidance by naming the alternative (outlook_read_message), stating the hard cap of 20, and noting partial-failure tolerance. This makes it clear when this tool is appropriate.

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

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

The description accurately implies a mutating action (reclassify) and notes the non-destructive nature via annotations. It does not detail side effects or reversibility, but given the simple scope and the existing annotation hints (readOnly=false, destructive=false), the provided information is adequate for typical usage.

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

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

The description is concise, using two short sentences to convey the action, a key parameter value, and the alternative tool. No redundant or filler content is present.

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 only two parameters and no output schema, the description covers all necessary aspects: what it does, the classification values, and when to prefer an alternative. No additional context is needed for an agent to invoke it correctly.

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

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

The description explicitly specifies the allowed values for `classification` ('focused' or 'other'), which is critical information not present in the schema. `message_id` is self-explanatory and no further detail is necessary. This compensates for the schema's lack of descriptions.

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

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

Clearly states the action ('Reclassify'), the resource ('message'), and the specific scope ('Focused/Other placement'). The contrast with outlook_set_inbox_override also distinguishes it from a similar sibling tool, making the purpose unambiguous.

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

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

Explicitly says when to use this tool ('fix a single message') and when to use an alternative (outlook_set_inbox_override for sticky rules). This gives direct guidance on choosing between 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?

While annotations set 'destructiveHint: true', the description only says 'remove' without elaborating on side effects, irreversibility, or any other behavioral traits 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?

A single, front-loaded sentence with no extra words. Every part is essential.

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 basic purpose for a simple 2-parameter tool, but lacks usage guidelines and behavioral context. Adequate for minimal functionality.

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 only mentions 'by attachment ID' but does not clarify the role of 'draft_id' or add meaning beyond the parameter names.

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

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

The description clearly states the action (remove), target (attachment from a draft message), and key identifier (attachment ID). It is distinct from sibling tools like 'outlook_attach_to_draft' and 'outlook_download_attachment'.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., 'outlook_download_attachment'), nor any prerequisites or context for invoking it.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral constraint — that only user-created folders can be renamed, implying system folders will fail — but says nothing about error behavior, permissions, or name conflicts.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately efficient, though its brevity reflects under-specification rather than tight editing.

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

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

For a simple two-parameter idempotent mutation with no output schema, the description covers the core operation but omits parameter format details and failure conditions (e.g., duplicate names, non-user-created folders). Adequate but with clear gaps.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and largely does not. 'By ID' hints at folder_id being an identifier, but neither parameter's format, validity constraints, nor whether 'name' is the new name is clarified.

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

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

The description states a specific verb (rename) and resource (user-created mail folder), which distinguishes it from outlook_create_folder and outlook_delete_folder. It does not explicitly name sibling alternatives, but the operation 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?

There is no guidance on when to use this tool versus alternatives such as outlook_create_folder or outlook_delete_folder, and no prerequisites or conditions are stated. Usage is only implied by the verb.

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

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

Annotations already mark the tool as not read-only and not destructive, so the safety profile is established. The description adds that the operation is a reply and can target all recipients ('reply-all'), but it does not disclose side effects such as actually sending the message or requiring an existing message_id. Given the annotations, this is adequate but not enriched.

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

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

The description is two sentences with the core purpose front-loaded and the usage guidance in the second sentence. Every word earns its place; no filler or repetition.

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

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

For a tool with four parameters, no output schema, and zero parameter descriptions, the description is too sparse. It does not explain the expected format of body, the role of is_html, or what happens after the reply is sent (immediate send vs draft). The presence of sibling tools like outlook_forward and outlook_send_message adds ambiguity that the description does not resolve.

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 for parameter explanation. It only hints at 'reply-all' mapping to the reply_all boolean and gives no guidance on message_id, body, or is_html. This is insufficient to compensate for the undocumented schema.

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

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

The description states a specific verb and resource: 'Reply (or reply-all) to an email message.' It clearly identifies the tool's function and explicitly distinguishes it from the calendar-specific outlook_rsvp by naming the sibling tool, making the purpose unambiguous.

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

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

The description explicitly instructs when to use this tool vs an alternative: 'Use this for email; use outlook_rsvp for calendar meeting invites.' This provides a clear decision rule for the most relevant sibling, though it does not mention other alternatives like outlook_forward or outlook_send_message.

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

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

Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds that it sends an RSVP, which modifies invite status; no contradictions, but could mention downstream effects like email notifications.

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, zero waste, front-loaded with action and key parameter guidance.

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 3 parameters, no output schema, and no nested objects, description covers action, distinction from sibling, and key parameter; could be more complete on optional 'message' parameter.

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%; description explains the 'response' parameter with valid values, but does not elaborate on 'event_id' or optional 'message' parameter, partially compensating.

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 'RSVP to a calendar meeting invite' with specific verb and resource, and distinguishes from sibling tool 'outlook_reply' for regular emails.

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

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

Explicitly says 'Use this for meeting invites; use outlook_reply to reply to a regular email message,' providing clear context and alternative.

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