outlook-mcp

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

With no annotations the description carries the full burden, and it does disclose the meaningful behavior: this is a status query whose result is one of three enumerated states, including the non-obvious intermediate device-code state. It omits whether the call is side-effect free or whether polling is expected while waiting.

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

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

One front-loaded sentence, no filler, and the three possible states are listed in a natural reading order.

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, no-output-schema status tool this is close to sufficient: it names the possible return states, which is the main thing an agent needs. It could go further by saying what action each state implies (e.g., call login when signed out).

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

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

The tool takes zero parameters, so the baseline of 4 applies; the description correctly adds nothing to interpret.

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 ('Report') and resource (auth/signed-in state), and enumerates the three states it distinguishes. It is clearly distinct from login/logout by nature, though it never names those siblings to reinforce the contrast.

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: an agent can infer it should check state before calling authenticated tools or after initiating login. There is no explicit when-to-use, no mention of login/logout alternatives, and no guidance on what to do with the 'waiting for a device code sign-in' state.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the underlying mechanism (inbox rule to Deleted Items), scope (future mail only), and reversal path. It omits edge behavior such as what happens with zero inputs, permission/auth requirements, and whether rule creation is idempotent.

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?

Four short sentences, front-loaded with the core action and mechanism, followed by input semantics, scope limitation, and undo guidance. Every sentence adds distinct value with no 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 two-parameter mutation tool with no annotations or output schema, the description covers mechanism, input matching rules, scope boundary, sibling alternative, and undo path. It is nearly complete, though it does not address empty input or return/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 coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: addresses use exact match while domains match any sender at that domain, and either or both may be supplied. This goes beyond the minimal 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?

States a specific verb and resource: blocking senders by creating an inbox rule that moves future mail to Deleted Items. It distinguishes itself from siblings by naming delete_message for existing mail and delete_rule for undo, so an agent can select it without inspecting other 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?

Explicitly explains when to use this tool (future sender blocking) versus delete_message (already-received mail) and how to undo via delete_rule. It also clarifies accepted inputs: addresses and/or domains.

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

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

With no annotations, the description carries the full burden and does so: delete is recoverable via Deleted Items and never permanent, archive targets the Archive folder, move requires destinationFolderId, and the default and hard cap on max are stated. It also flags that the dry-run sample contains untrusted email content that must not be followed as instructions.

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

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

Front-loads the action and the mandatory dry-run safety step, then moves through selection modes, limits, action semantics, and the untrusted-content warning. It is dense but every clause conveys operational information an agent needs before calling.

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

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

For an 11-parameter mutation tool with no output schema and no annotations, the description still covers safety, scoping, limits, per-action effects, and the shape and risk of the dry-run response. Nothing an agent needs to call this 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?

Adds real meaning beyond the 73%-covered schema: the schema says query cannot combine with filters, but the description names which filters and explains the default scope difference (inbox for filters, whole mailbox for query). It restates the max default and cap already in the schema, so it falls just short of full marks.

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?

Opens with a specific verb and resource ('Apply one action ... to every message matching a search') and enumerates the seven allowed actions. This clearly separates it from single-message siblings such as delete_message, move_message, mark_read and flag_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 explicit when-and-how guidance: always run with dryRun first, confirm the matched count with the user, then re-call with dryRun: false. It also states the mutually exclusive selection modes (query vs filters cannot be combined) and points to the right parameter for move.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the message is stored rather than sent and that attachments of 3 MB or more use chunked upload up to 150 MB, but it says nothing about auth requirements, what the call returns (draft ID?), or how failures on large uploads surface.

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 with zero waste: the not-sent constraint is front-loaded and the attachment edge case follows. 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?

For a 7-parameter mutation tool with no annotations, incomplete schema descriptions and no output schema, the definition covers the core intent and the attachment size caveat but omits return value, auth prerequisites, and bodyType handling, leaving meaningful 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 43% (low), with cc, bcc, body, subject and the attachment path undocumented by the schema. The description compensates only for attachments (size thresholds); the required to/subject/body and cc/bcc semantics are left to field names and validation patterns.

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+resource ('Create a draft message') with an explicit scope clarification ('in the Drafts folder (not sent)') that implicitly separates it from send_mail and reply_message. It does not name the sibling tools directly, so it falls just short of 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?

The parenthetical '(not sent)' hints at when to use this instead of send_mail, but there is no explicit when/when-not guidance, no mention of reply_message or forward_message as alternatives, and no stated prerequisites (e.g., login).

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the future-mail-only scope ('Does not affect mail already received') and the concrete side effects for delete (Deleted Items) and junk (Junk Email). It omits permission/auth requirements, what happens on duplicate display names, and whether the created rule is returned, which keeps it short of a 5.

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 compact sentences, front-loaded with the core purpose, then conditions, then actions, then the scope caveat. No filler wording.

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 annotations and no output schema, the description covers the essentials: matching semantics, action-specific requirements, and side effects. Only the displayName/stopProcessingRules behavior and the return value are unexplained, a minor gap relative to the schema's own descriptions.

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 57%, and the description adds real meaning for destinationFolderId ('an id or a name like archive') and for the at-least-one-of constraint across the three condition arrays. However, displayName and stopProcessingRules (default true) are never mentioned in the description, leaving part of the gap unfilled.

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 ('Create an inbox rule') plus the scope of what it acts on ('future incoming mail matching the conditions'). It is clearly distinguishable from the siblings list_rules and delete_rule.

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 a concrete precondition — at least one of fromAddresses, senderContains, subjectContains — and enumerates the four actions with their individual requirements (move needs destinationFolderId). It never explicitly names an alternative tool or a when-not-to-use case, but the conditions for correct invocation are unambiguous.

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

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

With no annotations supplied, the description carries the full burden and does well on the critical trait: it discloses that default deletion is recoverable (moves to Deleted Items) and that 'permanent: true' is irreversible. It omits other behavioral facts an agent would want — return value, behavior when an id is not found, and partial-failure semantics for batches.

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

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

Three short sentences with zero filler, front-loading the action, then the default behavior, then the destructive variant, then the parameter shape. Nothing to cut and the most dangerous detail is not buried.

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

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

For a 3-parameter destructive tool with no annotations and no output schema, the description covers the essentials: what it does, the safe default, and the irreversible mode. It does not state what the call returns (e.g., count deleted) or whether auth/folder permissions are required, which leaves a modest gap.

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 67%, and the gap is the undocumented 'permanent' boolean, which the description explains in terms of consequence (recoverable vs. irreversible) — genuine value beyond the schema. The id/ids mutual-exclusivity note largely repeats the schema's own descriptions, and the 50-item cap is already encoded as maxItems.

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 ('Delete a message') with the scope ('Accepts id or ids (up to 50)'). It does not explicitly name the nearest sibling it is not (move_message, bulk_action), so an agent must infer the boundary, but the purpose itself 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?

Gives clear conditional guidance for the most consequential decision: default behavior vs. 'permanent: true'. It stops short of saying when to prefer this over siblings like move_message or bulk_action, or what to do if the id is unknown.

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?

No annotations are supplied, so the description carries the entire behavioral burden, and it says nothing about the operation being destructive and irreversible, what permissions are required, or what happens when the id does not exist. For a delete mutation with zero annotation coverage this is a substantive gap beyond what a reader can infer from the verb alone.

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 short sentence with the operation front-loaded and the pointer to list_rules appended where it is most useful. There is no waste, though the extreme brevity leaves no room for the safety context a delete tool warrants.

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?

A destructive, one-parameter tool with no annotations and no output schema leaves the description responsible for safety and error behavior, yet none is covered. An agent knows what to call but not the consequences of calling it, which is incomplete for a delete operation.

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

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

The input schema has 0% description coverage, documenting only that id is a non-empty string. The description partially compensates by clarifying that id identifies an inbox rule and can be sourced from list_rules, but it adds no format, example, or error semantics for the 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 ("Delete an inbox rule") plus the keying parameter ("by id"), which cleanly separates it from sibling mutators create_rule and list_rules. It stops short of full differentiation (e.g., no note on what happens to already-applied rules), but an agent can identify the operation 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?

The parenthetical "(see list_rules)" usefully tells the agent where to obtain a valid id, which is a real usage hint. However, there is no guidance on when deletion is appropriate versus alternatives (e.g., disabling or leaving a rule in place), and no prerequisites or preconditions are stated.

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

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

With no annotations, the description carries the full burden and discloses important behavior: overwrite refusal unless overwrite=true, rejection of paths outside the download directory, and the security-sensitive return of a sender-chosen filename under an "untrusted" key with a warning not to follow instructions found in it. It could still say more about permissions or error behavior, but the core mutation and safety traits are well covered.

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, front-loaded with the core action, and each sentence adds distinct value: destination, overwrite behavior, path validation, and an important security warning. There is no redundant wording.

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 download tool with no output schema and no annotations, the description covers the essential action, overwrite behavior, path restrictions, and the shape of the returned saved path under the "untrusted" key. It is nearly complete, though it does not explain how to obtain attachmentId or whether authentication is 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?

Schema description coverage is only 25%, so the description should compensate more for undocumented parameters. It explains the effect of overwrite and the path restriction, but messageId and attachmentId receive no semantic explanation beyond their names, leaving a meaningful gap for a low-coverage 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 uses a specific verb and resource: "Download an attachment into the configured download directory." It clearly distinguishes this action from sibling tools like list_attachments or get_message by describing a save-to-disk operation.

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 tool name and description, but there is no explicit guidance on when to choose this tool versus list_attachments or get_message, nor any note that attachment IDs likely come from list_attachments. The overwrite and path constraints are useful behavioral rules but do not constitute when-to-use 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?

With no annotations, the description carries the full burden and does so well: it declares the tool read-only, discloses the scan bound (default 500, max 2000 via the schema), and warns that sender names and subjects are untrusted email content that must never be treated as instructions. It omits cost/latency implications of scanning up to 2000 messages and any failure behavior, which keeps it short of a 5.

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 tight sentences: behavior and ordering first, the downstream action second, the security caveat last. Every sentence carries distinct information with 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?

No output schema exists, and the description compensates by describing the result shape (sender grouping, unsubscribe method, sampleMessageId) and the untrusted-content wrapping. It is nearly complete for a four-optional-parameter read tool, though it could say more about scan cost or result limits.

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 the schema already explains folderId, maxMessages, excludeDomains, and includeNoUnsubscribe. The description adds workflow meaning by referencing sampleMessageId (an output field not in the input schema) but does not otherwise enrich parameter interpretation beyond what the schema provides.

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 multi-step operation: scan recent messages in a folder, group by sender, and report which senders are mailing lists via List-Unsubscribe headers, ordered most-frequent-first. This is clearly distinguishable from siblings like list_messages and search_messages, which enumerate or filter messages rather than aggregate by sender.

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?

Implies the workflow explicitly by telling the agent to pass a result's sampleMessageId to unsubscribe, which routes it to the correct sibling tool. It also names the default folder (inbox). It does not explicitly state when to prefer list_messages or search_messages instead, so it falls 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.

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

No annotations are supplied, so the description carries the full burden, yet it says nothing about whether the operation is idempotent, what permissions are required, whether unflagging an unflagged message errors, or what the call returns. The only behavioral detail given (id or ids, max 50) merely restates the 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?

Two short sentences, front-loaded with the action and followed by the input form; nothing is padded. The second sentence is largely redundant with the schema, which keeps it from a 5.

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 mutation tool with no annotations and no output schema, the description leaves too much open: no permission/auth notes, no result behavior, and no explanation of the required status values. An agent could invoke it, but would be guessing about effects and the meaning of 'complete' versus 'notFlagged'.

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 67%, and the one undocumented element is the required 'status' enum (flagged/complete/notFlagged), whose semantics the description never explains. 'Accepts id or ids (up to 50)' duplicates what the schema already states via maxItems and the property description, adding no new meaning.

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 ('Set') and a specific resource attribute ('the follow-up flag status of a message'), which separates it from siblings like mark_read and move_message. It does not explicitly contrast itself with bulk_action, but the resource/attribute pairing is clear enough to select it.

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 statement of when to use this tool versus mark_read, bulk_action, or delete_message, and no guidance on which of the three statuses applies to which situation. Usage is only inferable from the phrase 'follow-up flag'.

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

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

With no annotations at all, the description carries the full behavioral burden, and "Sends immediately" is its only disclosure — it usefully signals that this is an outbound, non-reversible side effect rather than a draft. However, it says nothing about permissions, whether attachments and original body are carried over, whether recipients see the original sender, or what is returned, which are the material risks for an outbound mail action.

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?

Both sentences are tight and front-loaded, with the action first and the immediacy caveat second. The brevity crosses into under-specification given a mutation tool with zero annotation and zero schema coverage, so the economy costs more than it saves.

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 three-parameter outbound messaging action with no annotations and no output schema, the description should explain the identifier, the comment field, and the side-effect profile. Only the side-effect hint is present, leaving the agent without enough to call it confidently or predict the result.

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% across three parameters, so the description must compensate and largely fails to. It implies what id ("a message") and to ("recipients") mean, but never clarifies that id is a message identifier nor what form it takes, and the comment parameter is not mentioned at all, leaving a third of the inputs undefined everywhere.

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 ("Forward a message") plus the target ("the given recipients"), which is more precise than a bare name restatement. It does not distinguish the action from siblings such as send_mail or reply_message, which also emit mail, so the agent gets the operation but not its boundary.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g. whether the message must exist in a folder you can access), and no direction toward alternatives like reply_message or create_draft. The only contextual hint is "Sends immediately", which implies no draft stage but is not framed as usage 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?

With no annotations supplied, the description carries the full burden and delivers real behavioral detail: plain text is the default format, HTML bodies are sanitized and truncated, and untrusted content is demarcated in <untrusted_email_content> markers with a summary/sender/recipient fields under an "untrusted" key plus an explicit prompt-injection warning. It does not cover error cases (e.g., nonexistent id) or whether truncation is signalled in the response, which keeps it below a 5.

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 what is returned and followed by the security-relevant handling of that content. No filler, and the safety instruction is placed where an agent will read it before acting on the body.

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

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

There is no output schema, so the description must and does describe the return shape (headers, recipients, body, and the untrusted key structure) and the sanitization/truncation behavior. Gaps remain around error behavior and whether a truncation indicator is returned, but for a three-parameter read tool this is close to 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 coverage is 67% and the undocumented "id" is self-evident from the tool name and required field. The description adds genuine meaning beyond the schema for the other two: it states text is the default format and that html is sanitized and truncated, which explains the real consequences of choosing that enum value rather than just restating it.

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 uses a specific verb and resource ("Get one message") and enumerates what is returned (headers, recipients, body), which implicitly separates it from the plural siblings list_messages and search_messages. It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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: the required "id" parameter signals this is for retrieving a single known message, whereas list/search siblings would be used for discovery. There is no explicit "use this when... / use X instead when..." guidance, and no mention of prerequisites such as being logged in.

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?

No annotations are supplied, so the description carries the full burden, and it discharges the most important part by stating 'Does not change anything' — an explicit non-mutation guarantee. It also enumerates the categories of result (one-click, mailto, link), which effectively describes the return shape in the absence of an output schema. It stops short of describing edge-case behavior, such as a message with no List-Unsubscribe header or an unsupported/unverified one-click URI.

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 with no filler, and the read-only guarantee is placed last as a clean safety note after the substantive purpose. Nothing here could be cut without losing 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 one-parameter read tool with no annotations and no output schema, the description covers purpose, safety, and the kinds of results returned. The remaining gaps are the missing-header case and the semantics of the 'id' argument, both of which the agent may need in order to interpret an empty or partial result.

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 required 'id' parameter, so the schema contributes no meaning. The description only indirectly identifies it as the message whose headers are read ('a message's List-Unsubscribe headers'), which is enough to infer the parameter's role but adds no format, source, or constraint details.

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 a message's List-Unsubscribe headers and report how to leave the mailing list. It also names the three response modes (one-click, mailto, link), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the sibling 'unsubscribe' tool, which is the one it is most likely to be confused with.

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: an agent can infer this is the inspection step before acting. There is no explicit statement such as 'use this to inspect, then call unsubscribe to actually act', and no guidance on what to do when no List-Unsubscribe header is present. The read-only framing hints at when-not-to-use, but only indirectly.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: it discloses that only metadata is returned, and warns that filenames are untrusted email content surfaced under the "untrusted" key, which shapes how an agent should treat the output. It does not cover read-only status, pagination, or auth requirements.

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, zero waste, with the scope constraint and the security warning both front-loaded before any invocation detail would be needed.

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 one-parameter read tool with no output schema, the description covers what is returned (metadata, filenames under an untrusted key) and the key safety consideration. Only auth/permission expectations and result-set size behavior are absent, which is minor here.

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

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

There is a single required parameter at 0% schema description coverage, so the description would ideally explain it. It never mentions messageId, though the meaning of an identifier for "a message" is clear from the sentence's subject. Minimal compensation for 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 and resource ("List attachments of a message") and narrows scope with "metadata only, no content", which implicitly separates it from download_attachment. It stops short of naming the sibling, so the differentiation is inferable rather than explicit.

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 "metadata only, no content" signals that this is the inspection step before fetching a file, implying download_attachment is the alternative for actual content. There is no explicit when/when-not statement or precondition 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?

No annotations exist, so the description carries the full burden. 'List' implies a read-only operation, but the description says nothing about permissions/auth requirements, behavior on invalid folder ids, pagination, or whether hidden folders affect the default result beyond the parameter name. It is adequate but thin for a tool with zero 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?

Three compact sentences: purpose first, conditional behavior second, cross-tool vocabulary hint last. No filler, and the most decision-relevant information is 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?

For a two-parameter, optional-params listing tool with no output schema, the description covers purpose, conditional scope, and accepted id vocabulary. Only the lack of any behavioral notes (auth, error handling, pagination) keeps it from being fully complete given the absence of 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?

Schema coverage is 100%, so both parameters are already documented, but the description adds the enumerated set of well-known folder names (inbox, drafts, sentitems, deleteditems, junkemail, archive) that can be passed as parentFolderId, which is meaning the schema only gestures at.

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 mail folders') and immediately clarifies the scope split: no parentFolderId returns top-level folders, with it returns children. That is a concrete, distinguishing purpose no sibling tool shares.

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 makes the selection rule explicit for the one real choice (top-level vs. child listing) and notes that well-known names are usable as folder ids elsewhere. It gives no guidance on when to prefer this over other listing tools, but the alternatives (list_messages, list_attachments) target different resources, so the risk of misuse is low.

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

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

With no annotations supplied, the description carries the full burden and does well on the unique parts: it discloses sort order (newest first), the opaque cursor workflow for pagination, and a security warning that subject/sender/preview fields live under an "untrusted" key and must not be followed as instructions. It omits auth/permission requirements and any notion of result volume or rate limits.

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?

Four short sentences, front-loaded with what the tool does and how to page, then the safety caveat. No redundancy and nothing that could be cut without losing 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 an 8-parameter read tool with no annotations and no output schema, the description covers purpose, paging, and the shape/safety of returned content. A brief pointer to get_message for full message bodies would close the remaining gap.

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 75%, so most parameters are already documented. The description adds meaningful context only for folderId (default inbox), nextLink (must come from a previous response), and generic "filters"; from, since, until, top, unreadOnly and hasAttachments gain nothing 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?

States a specific verb and resource ("List messages in a folder"), plus scope details: default inbox, newest-first ordering, filter support, and paging. It does not name or differentiate itself from the sibling search_messages, so an agent must infer which listing tool to pick.

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 (browse a folder, page with nextLink) but never states when to prefer this over search_messages or when a single-message read (get_message) is more appropriate. The when-to-use context is present but only by implication.

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?

No annotations are supplied, so the description carries the full burden, and it does add one genuinely useful fact: the required MailboxSettings.ReadWrite permission. However, it omits the return shape (no output schema), whether disabled rules are included, ordering, and whether the operation is read-only — the ReadWrite scope oddly suggests broader access than a list would need.

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, front-loaded with the resource and scope, then the permission requirement. Every clause earns its place with 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?

For a zero-parameter read tool with no output schema, the definition covers what is listed and the auth requirement, which is enough to invoke it correctly. The main residual gap is return-value expectations, which the absent output schema pushes onto the description.

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. The description correctly implies a no-argument full listing and adds nothing misleading about inputs.

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?

Names a specific verb and resource ("List the inbox message rules") and disambiguates what "rules" means with a parenthetical definition ("server-side rules that run on incoming mail"). It is clearly distinct from create_rule and delete_rule by its read framing, though it never explicitly contrasts itself with 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?

Usage is only implied: an agent infers this is the tool to inspect existing rules, presumably before create_rule or delete_rule. There is no explicit when-to-use statement, no exclusions, and no mention of prerequisites beyond the permission note.

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?

No annotations, so the description carries the full behavioral burden, and it does most of it: it discloses the return payload (URL plus one-time code), the required human step, and that completion happens asynchronously in the background. The only gap is it doesn't say what happens if the user is already signed in without force, so an agent can't predict whether a fresh code is always issued.

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 action, then the user-facing steps in sequence, then the async completion and confirmation, then the force case. Every sentence maps to a distinct decision the calling agent has to make; 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?

For a one-parameter tool with no annotations and no output schema, the description covers the return shape, the human interaction, asynchronous completion, the confirmation path, and the force semantics. It falls just short of complete because it doesn't cover the already-authenticated state or the failure case.

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% — the schema only says 'force: boolean' — so the description must supply meaning, and it does: 'Use force: true to sign in again (e.g. after adding a permission in Azure).' It implies the default is to skip re-sign-in when already authenticated, but doesn't state that default or the false case explicitly.

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?

Opens with a specific verb and resource ('Sign in to the Microsoft account') and immediately separates itself from the sibling auth_status by casting that tool as the confirmation step. An agent can pick it out from the mail and auth siblings 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?

Gives explicit when-to-use (initial sign-in), when to re-run ('force: true ... e.g. after adding a permission in Azure'), and names the follow-up tool (auth_status to confirm). Both the primary path and the re-authentication path are routed, leaving nothing to infer.

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?

No annotations are provided, so the description carries the full burden; it does disclose the key side effects (cached account removal and deletion of the local token cache file). It omits whether the token is revoked server-side, whether the operation is reversible (i.e., requires a fresh login), and what happens if invoked while not authenticated.

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 names the action first and then the consequences, with no redundant or filler wording.

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 zero-parameter session tool with no output schema, the description covers the essentials: what it does and what local state it destroys. Only server-side session/token revocation and any failure mode remain unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is fully consistent with the described behavior. Baseline of 4 applies for a parameterless tool.

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 ("Sign out") plus its concrete effects (removes cached account, deletes local token cache file), which makes it clearly distinct from the sibling `login` tool. It stops short of explicitly naming `login`/`auth_status` as counterparts, but the operation 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 by the verb rather than stated: an agent can infer this is called when ending a session. There is no explicit guidance on when-not to call it, whether a session must exist first, or how it relates to `auth_status` and `login`.

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

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

With no annotations supplied, the description carries the full behavioral burden and does much of it: it declares 'Read-only' explicitly, discloses the response shape in detail, and warns that subjects and sender names are untrusted email content that must never be followed as instructions — a meaningful safety disclosure no annotation would provide. It stops short of describing scan cost, truncation behavior when maxMessages is hit, or what happens for an empty/unknown folder.

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 a colon-delimited enumeration of outputs, followed by the security caveat and the read-only marker. Every clause adds information — output inventory, trust boundary, safety profile — with 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?

There is no output schema and no annotations, so the description must supply both return-value semantics and the safety profile; it does both (output inventory plus read-only and untrusted-content warnings). For a read-only, zero-required-parameter digest tool, an agent has enough to decide to call it and to interpret what comes back.

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 every parameter including the groupBy enum, unreadOnly, and maxMessages bounds is already documented in structured form. The description restates the folder and time-window defaults but adds no new meaning for groupBy, unreadOnly, or maxMessages, so 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?

The description states a specific verb ('Summarize') and resource ('what is waiting in a folder') and then enumerates the exact outputs: counts (total, unread, flagged, high importance, with attachments), high-importance/flagged messages, and sender-grouped messages with a newsletter hint. That aggregate framing clearly separates it from siblings like list_messages and search_messages, which return raw message lists rather than a digest.

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 rather than stated: the defaults (inbox, last 24 hours, unreadOnly true) suggest a 'what's new' triage use case, which is helpful context. However, the description never says when to prefer this over list_messages or search_messages, nor does it state when a digest is a poor choice (e.g., when specific messages are needed).

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?

No annotations are supplied, so the description carries the full burden, yet it discloses nothing about whether the call requires authentication, whether it is idempotent, what happens when an id is already in the requested state, or what the response contains. For a mutation tool with zero annotation coverage, this leaves the behavior opaque.

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 with the action front-loaded and the batch limit second; nothing is wasted, though the second sentence largely duplicates structured schema constraints.

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 core action is covered, but a mutation tool with no annotations, no output schema, and only 67% parameter coverage should say more about permissions, on-success behavior, and the read/unread semantics of isRead. It is minimally adequate rather than 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 coverage is 67% and the description merely restates the id/ids alternative and the 50-item cap already encoded in maxItems. It adds no meaning for isRead, such as whether true marks as read and false reverts to unread, which is the key field the agent must set correctly.

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 and resource ("Mark a message") plus the two target states (read/unread), so an agent knows exactly what it does. It does not distinguish it from the nearby sibling flag_message, which is the one remaining ambiguity.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as flag_message. The only usage-adjacent content is the batch cap, which the caller must infer is for bulk cleanup rather than search-driven flows.

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

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

With no annotations, the description carries the full burden, and it delivers the single most important behavioral fact: the call returns the NEW message id because ids change after a move. That is exactly the kind of context annotations cannot express. It still omits permission requirements and the failure/partial-success semantics for batched moves, so it is not a 5.

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

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

Three short sentences, front-loaded with the action, then the return-value gotcha, then the parameter nuance. Every sentence carries information an agent needs and nothing is repeated.

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 three-parameter mutation with no output schema, the description covers the action, the returned value, batch limits, and folder addressing. The remaining gap is error behavior when one of up to 50 ids fails, which matters for a batch mutation but is a secondary concern.

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 67% and the undocumented parameter is destinationFolderId, which the description rescues by explaining it accepts either an id or a well-known name such as archive, deleteditems, or junkemail. The id/ids exclusivity and the 50-item cap merely restate the schema, but the folder-name semantics are genuine added meaning.

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?

"Move a message to another folder" states a specific verb and resource, which cleanly separates it from read-side siblings like get_message or search_messages. It does not explicitly distinguish itself from delete_message or bulk_action, which are the closest neighbors in the sibling list, so it stops 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?

Usage is implied by the verb – an agent wanting to relocate a message will land here – but there is no explicit when-to-use or when-not-to-use guidance. Nothing tells the caller whether to prefer this over bulk_action for multi-message moves, nor what happens on partial failure when several ids are supplied.

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

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

With no annotations supplied, the description carries the full behavioral burden. "Sends immediately" is a genuinely useful disclosure that this is an unguarded write rather than a draft, but nothing states whether the send is irreversible, who receives a reply-all, whether it threads onto the original, or what is returned; for a mutation tool with zero annotation coverage that is a substantial 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 short sentences with no filler, and the immediate-send warning is front-loaded. The efficiency is real, though it shades into under-specification rather than true crispness.

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?

A three-parameter mutation tool with no annotations, no output schema, and no parameter documentation needs far more than two sentences. An agent cannot determine recipient scope, body semantics, or the result of the call from this definition.

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% across three parameters, so the description must compensate and does not. It hints at replyAll only obliquely ("or reply-all") and never explains that id is the target message identifier or that comment is the reply body — a non-obvious name that an agent could easily misread.

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 and resource ("Reply ... to a message") and immediately disambiguates the inline variant ("or reply-all"). It does not differentiate from neighboring tools such as forward_message or send_mail, which is the only thing keeping it from 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?

There is no guidance on when to reply versus forward_message, send_mail, or create_draft, and no instruction on when replyAll should be true versus a direct reply. The parenthetical implies replyAll is an option but leaves the selection criterion entirely to inference.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses that results are not sorted, that Graph caps results at about 250, that nextLink is needed for further results, and that subjects, senders, and previews are untrusted content that must not be followed as instructions. This is rich, operationally important context beyond the 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?

The description is three tightly written sentences. It front-loads the core purpose and example, then adds operational constraints and a security warning, with no wasted wording.

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 search tool with no annotations and no output schema, the description covers the most important behavioral traits: unsorted results, result cap, pagination, and untrusted email content. It still leaves top unexplained and does not describe the overall return shape beyond the untrusted key, so it is strong but not fully 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 coverage is only 50%, and the description adds useful meaning for query (KQL syntax with examples) and nextLink (pagination continuation). It does not explain the top parameter at all, and folderId meaning is left to the schema description, so it only partially compensates for 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?

The description states a specific verb and resource: full-text search of messages using KQL, with an example query. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling list_messages tool.

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 'Full-text search using KQL', and pagination guidance is given via nextLink. However, the description does not say when to use this tool instead of list_messages or other message-retrieval siblings, nor does it state any 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?

No annotations are supplied, so the description carries the full behavioral burden, and it does meaningful work: it discloses that the action is irreversible and that large attachments are uploaded in chunks with a failure-abort semantic ('if an upload fails nothing is sent'). It omits permission requirements, the effect of saveToSentItems, and anything about what is returned (e.g., a message id), which are relevant for an 8-parameter mutation.

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

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

Three short sentences, no filler. The primary action and its irreversibility are front-loaded, and the attachment edge case follows as secondary detail, which is the right ordering for an agent scanning the definition.

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

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

For a destructive, 8-parameter tool with no annotations and no output schema, the description covers the two things an agent most needs: that the send is irreversible and how attachment uploads behave on failure. The remaining gap is return-value expectations and the semantics of saveToSentItems, which are not covered here or anywhere in structured 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 50%, and the description adds meaning mainly for attachments by restating the 3 MB threshold and the 150 MB ceiling also present in the schema property description. The remaining parameters (cc, bcc, subject, body, bodyType, saveToSentItems) receive no added explanation, such as whether bodyType defaults to text or what happens when saveToSentItems is omitted.

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 ('Send an email immediately'), which clearly distinguishes it from prepare-only siblings like create_draft. It does not explicitly name sibling alternatives such as reply_message or forward_message, so an agent must infer that this tool is for new mail composition rather than replies or drafts.

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?

Use is strongly implied by 'immediately' and by the irreversibility warning, which tells the agent this is the terminal send step rather than a draft step. However, there is no explicit guidance such as 'use create_draft to compose first' or 'use reply_message to respond to an existing thread', leaving the routing decision to inference.

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

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

With no annotations, the description carries the full burden and does so: it discloses the escalation path (RFC 8058 HTTPS POST first, then mailto from the user's account), the terminal fallback (return the web link for the user to open), and the real-world side effect of confirming the address is live. Minor unstated items like error behavior are not enough to lower 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?

Four sentences, front-loaded with purpose, then mechanism, then fallback, then the safety exclusion. No filler and every clause carries operational 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 two-parameter, no-output-schema tool that triggers external network actions, this covers purpose, mechanism order, fallback, input shape, and a safety precondition. The only gap is that it does not say what is returned on the POST/mailto success paths, though it does describe the web-link return case.

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 the baseline is 3, but the description adds that the ids are message ids tied to a message's List-Unsubscribe header and restates the 50-item cap and either/or rule, which reinforces the mutual exclusivity the schema already encodes. Small but genuine added meaning.

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 ('Unsubscribe from the mailing list a message came from') plus the exact mechanism (List-Unsubscribe header). It is clearly distinguishable from siblings like get_unsubscribe_info (inspection) or find_newsletters (discovery), which an agent could otherwise confuse with it.

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 an explicit negative rule ('Never use this on spam or phishing') with the reason (unsubscribing confirms the address is active), plus the preference order for mechanisms and the fallback when only a web link exists. That is when-to-use, when-not-to-use, and fallback behavior in one paragraph.

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