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

Goes well beyond the readOnly/non-idempotent annotations by disclosing pagination mechanics, cursor single-use, and a 10-minute cursor expiry. These are non-obvious operational traits an agent must know to avoid replaying a stale cursor, and they cannot be inferred from the schema or 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?

Five short sentences, front-loaded with the core operation then scoping, defaults, and pagination in descending order of importance. No filler and nothing redundant with the schema.

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

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

Output schema exists so return shape need not be described; the description instead covers the reusable concerns an agent needs—traversal depth, starting point, paging protocol, and cursor lifetime. Complete for a list tool of this complexity.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely does: limit default 20 / max 100, parent_folder_id's effect on traversal start, and cursor reuse semantics. store_id's role is left implicit, which keeps it from a 5, but the compensation for the coverage gap is substantial.

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 immediate child folders') and constrains scope explicitly ('Does not recurse'), so the agent knows exactly what set is returned. The sibling tools are email-related, and this description leaves no ambiguity about which tool this is.

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?

Explains the default starting point ('store root unless parent_folder_id is given') and gives concrete pagination procedure ('Follow next_cursor with the same arguments; limit may change'). It does not name an alternative tool or a when-not-to-use condition, but no sibling competes for this task, so the guidance is sufficient in context.

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

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

The annotations already declare readOnly, openWorld, idempotent=false, and destructive=false. The description adds meaningful context by specifying that it includes mounted archives and shared stores and does not modify accounts or request access, which goes 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?

Two tightly written sentences: the first states what is listed and what is included; the second clarifies what is not done, which prevents misuse. No redundancy or filler.

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

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

The description is complete for a no-parameter read-only tool with an output schema. It covers scope, inclusions, and exclusions, and the annotations plus output schema handle the rest.

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 zero parameters, the baseline is 4. The description adds no parameter details, but there are none to describe, so this 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?

States a specific verb (List) and resource (mailboxes/stores) with explicit scope: only those accessible via the running Outlook profile. It distinguishes itself from siblings like list_folders and search_emails by naming the exact collection returned.

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

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

The description clarifies the implicit boundary by stating it does not add accounts or request access, which helps the agent know this is observation-only. However, it doesn't explicitly tell the agent when to use this versus outlook_status or list_folders.

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

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

Annotations already disclose the read-only, non-destructive, open-world safety profile, yet the description adds meaningful context beyond them: the return payload is limited to 'safe diagnostics and counts' with no mailbox names or message contents, and the tool functions even with Outlook closed. These privacy and availability traits are genuine disclosures, though response format specifics are left to the output schema.

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

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

Three front-loaded sentences: capability first, output/privacy second, availability precondition third. No filler, no repetition of the schema or annotations.

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

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

For a zero-parameter diagnostic with an output schema, the description supplies everything else an agent needs: what is inspected, that the output is sanitized, and the prerequisite state of Outlook. Return-value detail is correctly delegated to the 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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. It correctly adds no parameter narrative, which is appropriate here.

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

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

The description names a specific verb ('Check') and enumerates the exact resources inspected: Windows, classic Outlook, the running profile, and the connection. This clearly separates it from the mailbox/email-reading siblings, though it does not name them explicitly, so it falls short of a 5.

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

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

It gives concrete conditions: the tool works even when Outlook is closed, and the agent should open Outlook and resolve pending dialogs first. That is real operational guidance, but it never states when to prefer this over a sibling or what to do after a failed check, so no explicit alternative routing exists.

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

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

Goes well beyond the annotations: it discloses that the read does not mark the message read, that only plain text plus attachment names/sizes are returned (no HTML, images, links, or downloads), the character semantics of body_offset, the limit defaults/caps, and a prompt-injection warning about untrusted email content. This is exactly the behavioral context annotations cannot convey.

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

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

Front-loaded with purpose and the non-mutating guarantee, then pagination mechanics, then the security caveat. Every clause carries distinct information; nothing is restated from the schema or annotations.

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 paginated single-message reader with an output schema, the description supplies everything an agent needs: limits, offset semantics, how to continue pagination, what the body excludes, and a safety note about untrusted content. No material gap remains.

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

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

With 0% schema description coverage the description must carry the load, and it largely does: body_offset is defined as counting Unicode characters, body_limit gets its 12000 default and 30000 max, and the two IDs are characterized as opaque. It stops short of explaining server-side error behavior for invalid IDs, but the semantic gaps are covered.

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 ('Read an email by opaque entry_id and store_id') and immediately carves out scope that distinguishes it from siblings like search_emails and recent_emails: single-message read with no read-state mutation. An agent can route to it without inspecting the schema.

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

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

Usage context is implied by the requirement of an opaque entry_id/store_id and by the non-mutating read behavior, plus explicit pagination guidance (follow next_body_offset while body_truncated). However, it never names alternatives such as search_emails or recent_emails, so there is no explicit when-to-use-this-vs-that routing.

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

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

Annotations cover safety (read-only, non-destructive, open-world), while the description adds essential behavioral context: newest-first ordering, omission of bodies, default Inbox, folder/store relationship, best-effort pagination, non-snapshot behavior, and single-use cursors expiring after 10 minutes. No annotation 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?

Very dense and front-loaded: purpose, scope, filter rules, and pagination caveats appear in a few sentences with no wasted words. Every sentence adds operational meaning.

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

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

Output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers the tricky pagination and filtering behavior well, but omits guidance on when to prefer this over sibling tools and gives only minimal treatment of limit.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clearly documents cursor semantics and the store_id/folder_id relationship, but does not explain limit beyond noting it may change when following a cursor. Limit defaults and bounds remain in schema only.

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

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

States a specific verb and resource ('List recent emails') plus ordering and a key exclusion ('without bodies'). It also clarifies default scope and folder selection. It does not explicitly name sibling alternatives like search_emails or read_email, so it stops 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?

Gives clear filter rules for store_id and folder_id and explains cursor continuation, but does not say when to choose this tool over search_emails or read_email. Usage is implied rather than explicitly contrasted with alternatives.

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

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

Beyond the annotations (which only establish read-only, non-destructive, non-idempotent, open-world), the description discloses runtime traits the agent could not otherwise know: 1000 candidates / ~10s per call, an external 30s deadline against blocked Outlook, single-use cursors expiring in 10 minutes and lost on worker restart, and best-effort results accounting for inaccessible candidates. This is exactly the behavioral context annotations cannot carry.

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?

It is dense but front-loaded, leading with scope and ordering before filter semantics and the crucial incomplete-search warning. Nearly every sentence earns its place; the only mild cost is that several behaviors are packed into a single block, making it slightly heavy to scan.

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

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

An output schema exists, so return values need not be explained, and the description covers the parts that schema cannot: pagination mechanics, cursor lifetime, coverage.exhausted semantics, and evaluation_complete accounting for inaccessible items. For a complex 11-parameter search tool, nothing an agent needs to call or interpret it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it does for the key filters: query is a literal case-insensitive substring in subject/body/subject_body, query_in selects the field, sender matches name or SMTP address, after is inclusive and before exclusive, and both date formats are spelled out. It leaves store_id, folder_id, unread and has_attachments unspecified, with folder scope only implied by 'one folder'.

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, resource and scope: 'Search one folder without recursion, newest received first,' which tells an agent exactly what operation this performs and the ordering/scope constraint. It doesn't explicitly differentiate itself from the sibling recent_emails or read_email, so the agent must infer the routing, but the core purpose is unmistakable.

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

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

It gives strong operational context: filters combine with AND, how to follow next_cursor with identical filters, and the critical pitfall that zero results with coverage.exhausted=false is an unfinished search rather than a definitive negative. It doesn't name a sibling alternative or state when-not to use this tool, so it stops short of full when/when-not guidance.

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