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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: default unread filtering, inbox default, newest-first ordering, and the fields shown (sender, subject, time, short preview). It does not disclose pagination behavior or rate limits, but that is a minor gap given the annotation coverage.

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 with no waste. The core behavior and output shape are front-loaded, followed immediately by routing to the correct sibling tools.

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 that the schema fully describes parameters and an output schema exists, the description provides enough context to invoke the tool correctly. It covers the default behavior, result ordering, returned fields, and when to use deeper-view alternatives.

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 100%, so all four parameters are fully documented in the schema. The description reinforces the default unread-only and inbox scope, but adds little beyond what the schema already states. Baseline 3 is appropriate when the schema carries the parameter 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?

States a specific verb and resource ('New mail: messages in the Inbox') plus scope details (default unread, newest first, returned fields). It explicitly names the sibling tools for deeper views (get_message for full text, get_thread for conversations), so an agent can distinguish it from those alternatives 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?

Provides clear context for when to use this list view versus drilling into a single message or a whole conversation, naming both alternatives. It does not explicitly address when to use search_messages or list_senders instead, but the implied 'new mail' scope is strong.

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 and openWorldHint=false, so safety is covered. The description adds genuine behavioral context by disclosing the two underlying data sources (Exchange GAL plus personal contacts), a directory-specific trait not in the annotations. It does not describe matching behavior (exact vs fuzzy), pagination, or empty-result handling, so it stays mid-range.

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 filler, with the scope statement front-loaded and the usage/alternative cue immediately after. Every clause carries 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?

An output schema exists, so return-value explanation is unnecessary, and the description covers purpose, sources, and usage well enough to call the tool correctly with no required parameters. Only minor gaps remain (matching semantics, how query and queries interact).

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 100% (limit, query, queries all documented with formats and bounds), so the baseline is 3. The only parameter-adjacent value the description adds is the `is_me` marker, which is a result field rather than an input parameter, and it doesn't clarify query vs. queries interplay.

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 (Searches) plus the two concrete resources it covers (organization address book / Exchange GAL and the user's contacts) and lists the fields it resolves (name, email, job title, department). No sibling tool does people lookup, and this is instantly distinguishable from search_messages, list_senders, or get_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?

Gives clear triggering contexts: 'get an exact address before send_email' and 'find out who someone is', naming the downstream sibling tool send_email. It lacks explicit when-not guidance (e.g. when to prefer list_senders or search_messages), which keeps it just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety basics are covered. The description adds genuinely new context beyond the annotations: body format normalization (HTML to plain text) and an explicit prompt-injection warning that the text is data, not instructions. It does not mention truncation behavior, which is the one notable gap.

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

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

Two dense sentences with zero filler, front-loaded with the retrieval scope and ending on the highest-risk detail (untrusted content). Every clause carries 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?

An output schema exists, so return values need not be re-explained, and the annotations cover the safety profile. The description adequately covers content and format plus injection risk; the only shortfall is that truncation via max_chars is not surfaced for a tool that returns potentially large bodies.

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 only 67% and the description says nothing about any parameter. max_chars (truncation of the body) and include_quoted (quoted-reply handling) are explained only in the schema, and message_id has no description anywhere, so the agent gets no guidance on its expected format or the effect of truncation on the returned content.

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 ('One message in full') and enumerates exactly what is returned: sender, recipients, time, attachment names, and body text. This clearly separates it from search_messages or list_senders, though it never explicitly names the closest sibling get_thread.

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

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

Usage is only implied by the phrase 'One message in full', which suggests single-message retrieval rather than thread or search retrieval. There is no explicit when-to-use statement, no mention of when to prefer get_thread, and no prerequisites called out.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description still adds real behavioral value by disclosing that it exposes the user's own identity (with a warning against self-sending) and whether sending is enabled, which are traits the annotations do not 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?

It is a single dense sentence plus a short usage clause; the parenthetical earns its place by explaining why self-address matters. It is front-loaded with the returned data, though the opening parenthetical is slightly heavy 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?

An output schema exists, so the description need not re-document return formats, and it correctly focuses on what the tool is for and when to call it. For a zero-param status tool this is essentially complete, with only minor room to note alternatives.

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. No parameter guidance is needed and none is missing.

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 enumerates the specific data returned (user's own address/name, local time, unread count, sending-enabled flag), which is far more than a tautology and lets an agent distinguish it from siblings like get_message or check_mail. It lacks an explicit verb phrasing and never names the tools it is not, but the content is concrete and 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?

"Call first when you need today's date or want to check the mailbox is reachable" gives clear triggering conditions and even an ordering directive. It stops short of naming alternatives or exclusion cases (e.g., when to prefer check_mail), so it does not reach the explicit when/when-not bar of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, and the description adds genuinely new behavioral detail: cross-folder aggregation, oldest-first ordering, quoted history being cut off, and participant counts with message counts. It doesn't discuss truncation limits or rate/permission behavior, but the added output-shaping context is substantial.

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

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

A single front-loaded sentence that leads with what is returned, then layers scope, ordering, and trimming. Every clause carries information; nothing is redundant or padded.

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 present, return-value explanation isn't required, and the annotations cover the safety profile. The description supplies scope, ordering, and trimming behavior; the only minor gap is what happens when a thread exceeds max_messages, which the schema parameter partially addresses.

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 100%, so all three parameters (message_id, max_messages, max_chars_per_message) are already documented in the schema. The description's mention of 'quoted history cut off' and 'oldest first' loosely relates to the char/message limits and ordering, but adds no syntax or default detail beyond the schema — the baseline 3 applies.

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

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

States a specific verb and resource — retrieving the 'whole email conversation the message belongs to' — with scope details (across Inbox, Sent and other folders, oldest first, quoted history trimmed). This clearly separates it from get_message (one message) and search_messages (matching messages) without needing to name 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?

Gives clear use-case context: 'everything needed to summarize a thread, see who said what, and find open questions.' It doesn't name an alternative tool or state when not to use it, so it stops short of full 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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-structured behavior: result ordering (most messages first), the specific aggregate fields produced, and the reverse semantics when folder=`sent` (counts recipients instead of senders).

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, both load-bearing: the first front-loads the output contract and ordering, the second covers the folder inversion. No filler, no restating of the title or name.

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

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

An output schema exists so return values need no further explanation, annotations cover the safety profile, and 86% of parameters are schema-documented. The description supplies the remaining semantic gaps (ordering, sent-folder inversion, period scoping), so an agent has everything needed to call 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?

Schema coverage is 86%, so the schema carries most parameters. The description still adds meaning the schema lacks, notably that folder=`sent` inverts the tool to count people the user wrote to, and it frames the since/until pair as the 'period' the tool scopes to.

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 resource (senders) and enumerates exactly what the aggregation returns: message counts, unread counts, latest subject/time, latest message id, sorted most-messages-first. That precision implicitly separates it from search_messages and find_people, but no sibling is named outright, so it stops short of the top mark.

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?

Three concrete question phrasings ('who wrote to me this week', 'who is waiting for an answer', 'find the person from accounting who sent the invoice') tell the agent when this tool fits, and the folder=`sent` sentence flags a non-obvious alternate mode. No when-not guidance or explicit alternative is given, though.

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 readOnly/openWorld annotations by disclosing the Exchange full-text index path, the 500-newest-match cap, and the interaction between the index and date/flag filters. The reference to `complete` is opaque (it is not an input parameter), which slightly weakens an otherwise strong behavioural disclosure.

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 compact, front-loads the verb/resource and ordering, then adds the index mechanics. The final clause is dense and slightly run-on, but 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 10-parameter tool with an output schema, the description covers the query-execution model, result ordering and the truncation limit. The only real gap is that `complete` is referenced without explanation, though it is plausibly an output-schema field the agent can inspect.

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 90%, so the baseline is 3, but the description adds genuine meaning: it clarifies which fields (text, sender, recipient, subject) route through the full-text index and how those results are then narrowed by dates and flags. That is semantic behaviour the schema does not express.

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 ('Finds messages') plus ordering ('newest first') and the filter-combination capability. It does not explicitly distinguish itself from siblings like get_message, check_mail or list_senders, so an agent must infer that this is the general purpose searcher, but the core purpose 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?

Usage is implied ('Combine any filters') and there is a useful caveat about narrowing words when `complete` is false, but no explicit when-to-use-this vs get_message/check_mail routing or preconditions. The agent is told how the search behaves, not when to prefer it over a sibling.

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 state non-read-only/non-idempotent/openWorld; the description adds far more: a human approval window with a ~50 second timeout, external-recipient flagging, decline/edit outcomes, the edited_by_user flag, the duplicate:true dedup behavior within 10 minutes, and the fact that a decline/timeout is surfaced as an error with nothing sent. 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?

Front-loaded with the core action and every sentence carries distinct operational information (approval, timeout, outcomes, dedup), so nothing is wasted. It is a dense single paragraph with no visual structure, which slightly hurts scannability for a definition this information-rich.

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 high-stakes outbound tool with an output schema already present, the description still covers the auth prerequisite (OWA Mail MCP setup allowance), the human-approval gate, timeout behavior, error semantics, and dedup. Nothing an agent needs to invoke it safely 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 coverage is 71% and the description only loosely adds meaning by noting what the confirmation window displays (recipients, subject, text). It does not clarify cc/bcc or the reply_to_message_id/reply_all interaction beyond what the schema already documents, so it is a baseline 3 with the schema doing most of the work.

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 (sends an email from the user's mailbox) and immediately establishes the scope that distinguishes it from every sibling, all of which are read-only lookup tools (get_message, search_messages, check_mail, etc.). An agent can tell this is the only mutating/outbound tool in the set without opening a schema.

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

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

Gives explicit when-to-use ("Call only when the user asked to send this message") and explicit when-not-to-retry behavior for decline or timeout, plus the duplicate-call window. These are the exact conditions an agent needs to avoid unsolicited sends or retry loops.

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