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?

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuine context beyond that: it enumerates what is returned (mounted archives, shared stores) and explicitly disclaims account creation or access requests, which an agent needs in order to set expectations.

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 compact sentences with the primary action front-loaded and the inclusion/exclusion caveat immediately after. No filler.

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

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

With no parameters, an output schema present, and annotations covering the safety profile, the description supplies everything else an agent needs: what is enumerated and what the call will not do.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; per the baseline for parameterless tools this is a 4. The description correctly implies the call is unconditional.

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 (mailbox stores) and scopes it to 'already accessible through the running Outlook profile', which separates it from sibling tools like list_folders. It does not name a sibling explicitly, but the resource is distinct enough for disambiguation.

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 clause 'does not add accounts or request access' sets a useful negative boundary, steering the agent away from expecting provisioning behavior. However, there is no explicit statement of when to call this versus list_folders or outlook_status, so 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?

Annotations already declare readOnlyHint/destructiveHint, but the description adds genuinely new behavioral facts: it returns only 'safe diagnostics and counts' with no mailbox names or message contents (a privacy guarantee), and it functions while Outlook is closed. That is useful context beyond the annotation block, though it says nothing about latency or repeated-call 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?

Two sentences, no padding, and the core purpose leads. The privacy constraint and the availability caveat each carry distinct information, so every clause earns its place.

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

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

With zero parameters and an output schema present, the description need not explain return values, and it doesn't. It covers the remaining unknowns — scope of the check, privacy of output, and behavior when Outlook is not running — so nothing an agent needs before calling is missing.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It correctly avoids inventing parameter talk that would be noise 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 gives a specific verb (Check) and a precise scope (Windows, classic Outlook, running profile, connection) that no sibling tool covers — the siblings are all mailbox/content readers. It further disambiguates by stating what it does NOT return (no mailbox names or message contents), so an agent can tell it apart from list_mailboxes or read_email immediately.

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 supplies a real usage precondition: 'Available even when Outlook is closed; open Outlook and resolve pending dialogs first.' That tells the agent the tool is safe to call in a down state and what to do to get better results. It stops short of explicitly naming alternatives, but no sibling tool serves the same diagnostic purpose, so the gap is minor.

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

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

Annotations already declare readOnly/openWorld/destructive=false, but the description adds real behavioral context: Deleted Items exclusion, cursor stability rules, per-body paging, best-effort coverage with shared scan budgets, and the untrusted-data warning. The only unaddressed point is why idempotentHint is false, which the cursor semantics imply but never state.

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

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

Purpose is front-loaded in the first sentence and the remaining sentences are terse and information-dense, each covering a distinct behavior. It is jargon-heavy but almost no sentence is wasted.

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

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

An output schema exists, so return-value explanation is not required, and pagination/coverage caveats are well covered. The gap is the two required identifiers, whose meaning and provenance an agent must know to call this correctly at 0% schema coverage.

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 there are 5 parameters, so the description carries the full burden. It only gestures at 'cursor'/'next_cursor' and 'limit' and vaguely at body paging; the two required parameters entry_id and store_id are never explained, and body_limit is not defined. The compensating detail is partial at best.

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

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

The description gives a specific verb and resource ('Read the native conversation across accessible stores/folders') and adds scoping detail (ConversationIndex order, Deleted Items excluded). It does not explicitly name why an agent would pick this over search_emails or read_email, though it notes read_email continues body paging.

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 operational guidance for continuing a page ('Follow next_cursor with unchanged arguments except limit') and a pointer that 'read_email continues' body paging, which implies usage. However, it never states when to use this tool versus the sibling search_emails or read_email, so the routing decision 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?

The description adds substantial behavior beyond annotations: it does not mark the email read, returns plain text plus attachment names/sizes only, performs no HTML rendering or attachment downloads, explains body pagination via next_body_offset/body_truncated, and warns that email content is untrusted external data.

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

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

The description is front-loaded with purpose, then usage, return behavior, pagination rules, limitations, and security guidance. Each sentence carries operational value, and no sentence is wasted.

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

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

For a read-only email body tool with an output schema, the description covers when to call it, what it returns, pagination behavior, limitations, and prompt-injection risk. The remaining structural details are already handled by the schema and annotations.

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 compensates by explaining that entry_id/store_id are returned short references, that body_offset counts Unicode characters, that body_limit defaults to 2000 with a 30000 maximum, and how to follow next_body_offset while truncated. It still does not individually elaborate on entry_id/store_id beyond their source role.

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: read an email using entry_id/store_id references, without marking it read. It distinguishes this from metadata-only operations and from listing/body-fetching behavior, so an agent can tell when this tool is appropriate.

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

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

It gives explicit usage conditions: use only when metadata cannot answer the question, and do not fetch every body for a listing. It does not name specific sibling alternatives such as search_emails or recent_emails, so it falls just short of the highest usage-guidance score.

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 cover the read-only safety profile, but the description adds substantial operational context a caller cannot infer: cursors are single-use and expire after 10 minutes, pagination is best-effort rather than a snapshot, and next_cursor must be followed with unchanged filters. These are meaningful traits beyond the structured fields.

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?

Well front-loaded: purpose first, then usage guidance, then parameter and pagination rules. Seven sentences is dense but each one carries distinct information; no filler 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?

With an output schema already present, return values need no explanation, and the description covers defaults, filter dependencies, and pagination lifecycle sufficiently for correct invocation. Nothing an agent needs to call the tool 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 semantics, and it does: store_id alone selects a store's Inbox, folder_id requires store_id, cursor drives pagination, and limit's default of 20 is flagged. Cursor format and exact id semantics remain unstated, keeping it below a 5.

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

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

States a specific verb and resource ("List recent emails") with scope and ordering detail ("newest received first, without bodies") and a default target ("Defaults to the default Inbox"). This implicitly separates it from read_email (no bodies) and search_emails (recent, not search), but it never names a sibling, so it falls short of full 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?

"Call directly; no discovery is needed" and "Prefer the default 20-item page for overviews" give clear when-to-use context for the default and paged cases. It does not explicitly compare against search_emails or read_email as alternatives, so there are no stated 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?

Goes far beyond the readOnly/openWorld annotations: discloses the 1000-candidate / ~10s per-call cap, the external 30s deadline, the critical distinction that zero results with coverage.exhausted=false is not proof of absence, cursor single-use/10-min expiry/restart loss, and that evaluation_complete accounts for inaccessible candidates. This is exactly the operational context an agent needs and cannot derive from 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?

Front-loaded well with scope, query semantics, and the no-discovery note, plus the IMPORTANT callout is appropriately prominent. However it runs long and dense (repeated 'text matching is case-insensitive', layered filter and date explanations), and several clauses could be consolidated. Functional but not tight.

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

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

For a 15-param, zero-required-param, open-world, non-idempotent search with an output schema, this covers intent, all filter semantics, pagination/cursor lifecycle, and the crucial exhausted/coverage reliability caveat. Return values are handled by the output schema, so the description is complete.

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

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

Schema description coverage is 0%, so the description must carry full parameter meaning and does: it defines query as literal substring (not AQS), subject/body/subject_body matching scope, sender/recipient name-or-SMTP matching, attachment_name on filenames, category as complete name, importance values, inclusive 'after'/exclusive 'before', and accepted date formats. It even explains cursor semantics for next_cursor. Comprehensive compensation for the schema 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+resource (search emails) and a scope constraint ('one folder without recursion, newest received first'). Doesn't explicitly name siblings like recent_emails or list_folders, but the folder/recursion constraint and the 'no mailbox/folder discovery prerequisite' line distinguish it functionally. Clear enough to select without opening the schema.

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

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

Tells the agent to call directly for the default Inbox with no discovery prerequisite, and to return metadata first and read bodies only when needed (pointing toward read_email as the alternative). Doesn't explicitly enumerate when NOT to use it vs. recent_emails or read_conversation, but the usage context is concrete and actionable.

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