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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'Deletion is a mailbox mutation' mostly restates the structured data. It does add the useful safety context that explicit user request and ID confirmation are required, but it does not describe effects like permanence or recovery beyond what the parameter schema already offers.

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

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

Two sentences, no filler, with the most important usage constraint front-loaded. Every sentence earns its place.

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

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

For a destructive batch operation, the description plus annotations and fully documented parameters give an agent enough to select and invoke the tool correctly. The output schema exists, so return-value details are covered elsewhere. A small extra note about default trash vs permanent behavior would be nice, but the schema already specifies it.

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%, and the description adds no parameter-level detail. Per the rubric baseline, the schema carries the semantic weight, so a 3 is appropriate.

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

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

The description clearly conveys that the tool deletes messages, and ties it to user-supplied or confirmed message IDs. It does not explicitly contrast with sibling batch tools, but 'deletion' is specific enough to distinguish it from batch_get or batch_update.

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 opening 'Use this only when the user explicitly asks to delete messages and supplies or confirms the message IDs' provides an explicit precondition and a clear exclusion signal. It does not name alternatives, but the 'only when' phrasing effectively constrains when the tool should be selected.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld behavior, so the safety profile needs no restating. The description adds only the efficiency rationale and says nothing about per-message failure handling, truncation defaults, or partial results across a batch, which is where the real behavioral risk lies for a 100-item batch.

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

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

Two sentences, no filler, with the usage trigger front-loaded ahead of the rationale. It is arguably over-lean for an 11-parameter tool, but nothing in the text is redundant.

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 output schema and full parameter descriptions carry most of the weight, and annotations cover safety. What is missing is batch-specific context an agent would want: the 100-ID cap, behavior when some IDs are invalid, and whether results are ordered or partial — none of which appear in 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?

Schema description coverage is 100%, so every one of the 11 parameters including enums like body_mode, part, and include_attachments is already documented in the schema. The description adds no interpretation of how ids, mailbox_id, or body_mode interact, so 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 implies a batch retrieval of messages keyed by IDs ('several message IDs', 'multiple candidates') and distinguishes itself from single-message fetching via 'avoids repeated single-message calls'. It never states the verb+resource outright ('fetch messages by ID'), relying on the tool name to close that gap, so it is clear but not fully self-contained.

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

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

It gives concrete triggering conditions: the user supplies several IDs, or a prior search yields multiple candidates, and implicitly the single-message call is the alternative for one message. It does not state an exclusion case or the batch-size limit context, so guidance is strong but not complete.

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

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

Annotations already cover readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description's job is to add context beyond those. It adds a meaningful workflow constraint (invoke only post user-confirmation) and reinforces the mutating nature of the call, consistent with the annotations. No contradiction exists, and the added context is genuinely useful for an agent deciding whether to act autonomously.

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 with zero filler: the operations list is front-loaded, the user-confirmation gate follows immediately, and the read-only exclusion closes it out. Every sentence carries load-bearing guidance for invocation.

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 and annotations covering idempotency and destructiveness, the description need not explain return values or safety profiles. It covers purpose, when-to-use, and exclusions adequately. The residual gap is the unsupported 'move to a folder' claim and no guidance that ids is semantically required despite the empty required array, leaving minor ambiguity for the agent.

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 documents all six parameters, including rich detail on keywords (normalization to lowercase, read-only lifecycle keywords) and if_in_state (stale-write protection). The description adds only loose alignment ('set keywords/labels' maps to the keywords param) and no syntax or format details beyond the schema. 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 names a specific resource (multiple messages) and concrete operations (mark, flag, set keywords/labels), which distinguishes it from sibling update-adjacent tools like mailbox_batch_delete_messages and mailbox_batch_get_messages. However, the claimed 'move to a folder' capability has no corresponding parameter in the input schema, which slightly muddies the purpose for an agent planning its call.

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

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

The description gives an explicit when-to-use condition ('after the user has confirmed the desired change') and a clear when-not-to-use exclusion ('Do not use it for read-only tasks'). It stops short of naming the specific read-only siblings (e.g., mailbox_batch_get_messages, mailbox_get_message) as alternatives, which would earn 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 cover safety and idempotency, and the description adds value beyond them: required scopes (mailbox.read, email.send), mandatory optimistic concurrency via expected_revision and expected_schedule_version, and the state-dependent failure 'Cancellation fails once sending has begun'. Those are precisely the operational facts an agent cannot infer from readOnlyHint=false / idempotentHint=true.

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, zero filler, with the core action and the 'only when the user asks' constraint front-loaded before auth and concurrency details. Every clause carries information an agent needs.

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 state-mutating scheduling tool with an output schema, the definition covers auth, concurrency, cancel semantics, and the failure boundary. Minor gaps remain: behavior on revision/version conflict is left entirely to the schema, and mailbox_id targeting is not mentioned in 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?

Schema coverage is 100%, so the baseline is 3, but the description adds the reason the two expected_* fields must be passed (they are concurrency guards the caller must supply) and the meaning of scheduled_for=null as cancellation. That is genuine semantic value beyond the field-level 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?

The description names a specific verb pair and resource: 'Reschedule or cancel a saved draft send'. That is unambiguous and clearly a distinct operation from update_draft or send_draft. It stops short of naming a sibling tool for contrast, so it isn't quite 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 a real gating condition ('only when the user asks') plus an in-tool disambiguation (scheduled_for=null cancels, otherwise reschedules). However there is no guidance on when to use this versus update_draft or delete_draft, nor any statement of exclusions beyond the sending-started case.

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, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds the behavioral trait that it does not list results (only counts), which is useful beyond the annotations. It also hints at a workflow sequence. No contradiction with annotations.

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

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

The description is two sentences with zero redundancy. The primary purpose is front-loaded, and the usage alternative is stated succinctly. Every word earns its place.

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

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

Given the tool has 20 optional parameters and an output schema exists (though not shown), the description sufficiently explains when to use it and what it accomplishes. It does not explain the return format, but the output schema likely covers that. The description is adequate for an agent to decide when to invoke this tool.

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

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

The schema description coverage is 100%, so the baseline is 3. The description does not elaborate on any parameters; it only refers to 'mailbox filters' generically. Since the schema already documents all 20 parameters, the description adds no additional semantic value here.

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

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

The description clearly states the tool's function: 'count messages matching mailbox filters without listing every result.' It specifies the verb (count) and resource (messages), and explicitly differentiates itself from mailbox_list_messages, which is a sibling. This makes the purpose unambiguous.

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

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

The description provides explicit usage guidance: use this tool to count messages, and follow with mailbox_list_messages only when examples are needed. This directly addresses when to use this tool versus an alternative, leaving no ambiguity for the agent.

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 this is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds two pieces of context the annotations cannot convey: the required scope "calendar.write" and the side-effect boundary that no invitations or email reminders are sent. The idempotency behavior is covered by the annotation and the Idempotency-Key schema field, so the remaining gap is minor.

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 and the usage gate before the auth and side-effect notes. No redundant wording, though the separate "does not send invitations or email reminders" sentence is slightly tangential for a calendar-creation tool.

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

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

With annotations covering safety and idempotency, a 100%-covered input schema, and an output schema that removes the need to describe return values, the description supplies exactly the missing pieces: the required permission and the absence of notification side effects. Nothing an agent needs to call this correctly is absent.

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

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

Schema description coverage is 100%, with name, time_zone, mailbox_id, and Idempotency-Key all documented in the schema itself. The description adds only the adjective "private" for the name parameter and nothing about time_zone format or mailbox_id targeting, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ("Create a private calendar") and scopes it as private, which is meaningful against calendar listing/getting siblings. It does not explicitly differentiate itself from mailbox_create_calendar_event, which is the closest sibling, so an agent must infer the calendar-vs-event distinction from names alone.

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 phrase "only when the user asks" gives a clear gating condition for invoking the tool, but there is no mention of alternatives (e.g., use create_calendar_event to add events, list_calendars to check existing ones) and no explicit when-not guidance beyond the user-request constraint.

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

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

Beyond the annotations (which only say readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds genuinely useful behavior: no invitations or email reminders are sent, the credential needs calendar.write, and the UID must be retained for reconciliation after an uncertain result. It does not explain how a duplicate UID is treated (conflict vs. overwrite), which is the remaining gap for a non-idempotent write.

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 the capability, permission requirement, and retry rule front-loaded; nothing is filler. The second clause is telegraphic ("Retain the required UID before dispatch") but still parseable.

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?

Nine parameters with full schema coverage and an output schema means return values need no explanation; the description covers the two things structure cannot: notification side effects and safe retry after an ambiguous failure. Only the duplicate-UID/conflict outcome is left unstated for a 6-required-param write tool.

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

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

Schema description coverage is 100% and the UID reconciliation/never-repeat guidance is already written verbatim into the uid and Idempotency-Key parameter descriptions. The description therefore restates rather than adds meaning; baseline 3 is appropriate.

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

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

"Save an event without invitations or email reminders" states a specific verb (save/create) and resource (calendar event) plus an important scope qualifier: no attendee invitations or mail notifications. It does not explicitly name the sibling create/update calendar-event tools or say how it differs from them, 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 qualifier (use this when you want an event with no invitations/reminders) and a prerequisite is disclosed ("Requires calendar.write"). There is no explicit when-not guidance or named alternative such as mailbox_update_calendar_event or the qubrics_ variant, which matters given several near-identical calendar siblings.

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

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

The description adds real context beyond the annotations: the required mailbox.read and mailbox.drafts.write scopes, the fact that adoption needs an Idempotency-Key, and that the key should be reused on retries. That is meaningful operational disclosure for a write tool whose annotations only say readOnly=false, destructive=false and idempotent=false. It does not explain blast radius beyond 'saved, not sent', but the annotations plus scope disclosure cover most of the 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?

Four tight sentences, front-loaded with the outcome ('save without sending') before the prerequisites and the source.action mechanics. No filler, though the scope and idempotency clauses are somewhat compressed into the middle and could read more cleanly as separate statements.

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 14 parameters, nested recipient/attachment objects and an output schema, this tool is complex, and the description covers the pieces an agent cannot get from structured fields: auth scopes, the adoption idempotency contract, and content-override precedence. Limits, formats and return shape are handled by the schema and output schema, so nothing critical is missing.

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

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds genuine semantics: explicit content fields override the defaults prepared from source.action, and the Idempotency-Key must be reused when retrying the same create. That precedence rule is not derivable from the schema alone, so it earns an increment.

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 opens with a specific verb+resource pair ('Save a message') and immediately scopes it ('for review without sending it'), which cleanly separates this tool from mailbox_send_draft, mailbox_send_message and mailbox_update_draft. An agent can pick this tool over the send path without opening any 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?

It gives conditional guidance for the source.action values (reply/reply_all/forward/adopt) and the idempotency-retry case, which implies when the tool is appropriate. However, it never states when to use this tool versus mailbox_update_draft or mailbox_send_draft, nor any when-not conditions, so the routing guidance is inferred rather than explicit.

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

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

Beyond the destructive/idempotent annotations, it discloses the required calendar.write scope and the explicit 409 outcome when the calendar is non-empty, which is genuine behavioral context an agent needs before calling. It still doesn't say whether the deletion is permanent or recoverable, keeping it from 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 terse sentences with the permission requirement front-loaded, then the precondition, then the failure mode. No filler, and each sentence carries actionable 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?

The output schema covers return values and annotations cover destructiveness, so the essentials are present. However, for a destructive mutation the description omits reversibility and any recovery guidance, and gives no routing for non-empty calendars.

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 schema already documents calendar_id, mailbox_id, and If-Match. The description only reiterates the ETag workflow, adding no format, sourcing, or scoping detail beyond what the field descriptions provide. 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 name and title establish 'delete a calendar', and the description narrows the scope to an empty calendar with a concrete constraint (409 if events exist). It does not explicitly say 'deletes the calendar' in the description body or distinguish itself from mailbox_delete_calendar_event, so it falls short of a 5.

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

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

It gives a required workflow (GET the calendar first, pass its ETag) and a failure condition, which implies when the call is valid. It never states the alternative path for a calendar that contains events (e.g., delete its events first via mailbox_delete_calendar_event), leaving that inference to the agent.

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

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

Beyond the destructiveHint and idempotentHint annotations, the description discloses the required calendar.write scope, the required reviewed If-Match precondition, that there are no cancellation emails, and that the caller should reload after a conflict. This is meaningful operational context. It stops short of describing the response body or what happens on a 412 beyond 'reload'.

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 confirmation requirement, then the prerequisites, then the side effects and error recovery. Every sentence carries a distinct constraint, with no repetition of the schema or annotations.

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

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

An output schema exists and annotations cover destructiveness and idempotency, so the description only needs the operational prerequisites, operational caveats, and recovery path, which it supplies. It omits what happens to recurring-event instances and to attendee state, which would be relevant for a delete on an open-world calendar.

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. The description earns an extra point by calling the If-Match value 'reviewed', which signals that the ETag must come from a fresh read; it also ties conflicts to a reload, adding semantics to the precondition 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: 'Delete an event'. The scope is limited to calendar events, distinguishing it implicitly from mailbox_delete_calendar and the update/create event siblings. It does not explicitly differentiate itself from the near-duplicate qubrics_mailbox_delete_calendar_event, so it falls short of a 5.

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

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

'Delete an event only when the user asks' gives an explicit usage condition and implies a when-not: never delete proactively. It does not name alternatives such as updating the event or using a batch tool, so the guidance is clear but not complete.

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

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

The annotations already declare destructive=true and idempotentHint=false, so the description is not carrying the safety burden. It adds real value beyond them: required scopes (mailbox.read, mailbox.drafts.write), asynchronous background completion, and the edge case that an in-flight send blocks deletion.

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; the action, precondition, permission requirement, and behavioral caveat are front-loaded in that 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?

With an output schema present, return values need no explanation, and the description covers permissions, async completion, and the send-in-progress constraint. It omits whether deletion is reversible or what error surfaces on a precondition failure, but nothing critical for correct invocation 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 100%, so draftId, If-Match, and mailbox_id are already documented in the schema. The description's note about in-progress sends is loosely related to the conditional-delete parameter but doesn't clarify its semantics or when to supply 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 gives a specific verb and resource ('Delete a saved draft'), which is unambiguous. It does not distinguish this from siblings like mailbox_send_draft or mailbox_update_draft, so an agent must infer the boundary from the name alone.

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 phrase 'only when the user asks' establishes an explicit precondition and implicitly cautions against proactive deletion. It doesn't name alternative actions (send, update, discard schedule), but the usage context is clear.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description clears the lower bar and still adds real context: the returned download_url is short-lived and must be fetched promptly, and expiration is handled by re-calling rather than by retrying the URL. That is exactly the operational detail an agent cannot get from the hint flags.

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 prerequisite stated first and the expiration caveat second. Every clause carries actionable 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 three-parameter read tool with an output schema and full annotation coverage, this tells an agent what it gets back and how to handle URL expiry, which is the main failure mode. Only the choice between this tool and the read/text siblings is left unaddressed.

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 schema already documents all three parameters, and the description adds only the idea that message_id plus attachment_id pin down 'that exact attachment'. It says nothing about when mailbox_id is required, but with full schema documentation a baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('returns metadata plus a fresh short-lived download_url for that exact attachment'), which implicitly separates it from content-fetching siblings like mailbox_read_attachment or mailbox_get_attachment_text. It never names those siblings, 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?

It gives a sequencing prerequisite ('use this after finding a message attachment') and a re-invocation rule ('call this tool again if it expires'), which is useful. However, it never states when to prefer this over mailbox_read_attachment or mailbox_get_attachment_text, leaving that 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?

Annotations already establish readOnly, idempotent, non-destructive and openWorld, so the bar is lower, yet the description still adds real value: the mailbox.read privilege requirement, the not_found outcome from cache expiry or source deletion, and the instruction to inspect status/outcome before consuming text. It stops short of describing polling cadence or what a partially-converted state looks like.

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 tightly packed sentences with the workflow constraint front-loaded and zero filler. 'Check status and outcome before using text' is slightly compressed and could be clearer about which outcome values matter, 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?

An output schema exists, so return values need not be explained, and the description covers the prerequisite, the auth requirement, and the main failure mode. Given a five-parameter cached-read tool, that is nearly complete, with only the polling/retry expectation left implicit.

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%: mailbox_id, message_id, attachment_id, max_bytes and If-None-Match are all documented in the schema, including the default and cap on max_bytes. The description adds no parameter-level meaning beyond that, so the baseline of 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 ('Read or poll a previously requested attachment extraction') and explicitly rules out the conversion-starting behaviour, which separates it from request_attachment_text. It does not disambiguate against the near-identically named siblings mailbox_get_attachment and mailbox_read_attachment, which remain ambiguous from the description alone.

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 phrase 'previously requested' plus 'Check status and outcome before using text' tells the agent this is a follow-up step in a two-call workflow, not a first call. However, it never names mailbox_request_attachment_text as the prerequisite tool, so the agent must infer the alternative rather than being routed to it explicitly.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered and the description only needs to add beyond it. It contributes the OAuth scope requirement ("calendar.read"), which is genuine context not present in annotations. It does not cover behavior such as error handling on an unknown calendar_id or cross-mailbox access 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?

Two short sentences with the operation stated first and the permission requirement second; no filler and nothing 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 single-resource GET with an output schema and full annotation coverage, the description plus schema give an agent enough to call it correctly, including the required scope. The remaining gap is minor: no note on failure behavior for a wrong or inaccessible calendar_id.

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%, including mailbox_id's scoping rule and If-None-Match's 304 semantics, so the baseline is 3. The description's phrase "in the selected mailbox" loosely reinforces the mailbox_id/calendar_id relationship but adds no syntax or format detail 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?

"Read one calendar in the selected mailbox" gives a specific verb (read) and resource (one calendar), and the singular "one" implicitly separates it from the list_calendars sibling. It stops short of naming a sibling or stating a distinguishing condition explicitly, so it is clear but not fully differentiated.

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?

"Requires calendar.read" is the only guidance, which is an authorization prerequisite rather than a when-to-use rule. Nothing says whether the caller must first call mailbox_list_calendars to obtain a valid calendar_id, and no alternative (e.g. list_calendars) is named for the bulk case.

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

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

Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds real value beyond them by naming the required scope (calendar.read) and by warning that the returned concurrency token must be retained for a subsequent conditional change, which is non-obvious operational context.

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

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

Three short sentences, front-loaded with the action and its precondition, then the auth requirement, then the follow-up advice. 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?

Returns are covered by the output schema and all three parameters are documented in the schema, so the description only needs to supply usage, auth, and concurrency context, which it does. A note on what happens when the credential spans multiple mailboxes (selecting via mailbox_id) would round it out, but the schema already covers that.

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 goes further by framing the returned ETag as a 'concurrency token' tied to conditional changes, giving the If-None-Match parameter practical meaning beyond its schema text. It does not explain mailbox_id resolution, but the schema handles that.

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 one event'), which clearly separates it from the list siblings such as mailbox_list_calendar_events and the sibling get_calendar_event variants by scoping to a single event. It stops short of naming an alternative tool outright, so it is clear but not fully differentiated in-text.

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

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

It states a concrete when-to-use condition: read before editing or deleting. That implicitly routes the agent to mailbox_update_calendar_event and mailbox_delete_calendar_event without naming them, and there is no explicit 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety bar is lower; the description still adds substantive context: the calendar.read permission requirement, the meaning of sync_required, and the caveat that coalesced changes are not a complete activity history. That last point is a real behavioral caveat an agent could otherwise misuse.

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 core action and followed by the permission requirement and the sync caveat. Every sentence contributes, though the first sentence is compressed to the point of mild ambiguity about what a 'retained state' is.

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 values need not be explained, and the description still covers the key output flag (sync_required) and the credential scope implication. It is close to complete for a three-optional-parameter read tool, missing only explicit sibling routing.

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 are documented with formats and constraints; the description adds no syntax or defaulting detail beyond that. Baseline 3 applies since the schema carries the parameter burden.

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 ('Read bounded event changes') plus the source of truth ('from a retained state'), which is precise and tells an agent this is an incremental sync operation. It does not differentiate itself from siblings like mailbox_list_calendar_events or mailbox_get_calendar_event, so an agent must infer the distinction.

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 actionable guidance for the sync_required=true case (perform a full resync) and implicitly defines the incremental flow via since_state. However, it never states when to choose this tool over mailbox_list_calendar_events or mailbox_get_calendar_event, and no explicit prerequisites or exclusions beyond the read scope are given.

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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needs to add context beyond that. It adds the cursor-based sync mechanism but does not describe return behavior or cursor-format expectations; output schema covers the return shape, so 3 is appropriate.

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 with zero waste. The primary use case is front-loaded, and the exclusion follows immediately. Every word earns its place.

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

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

For a tool with 10 optional parameters including 7 distinct cursor types (since_state vs. type-specific *_since_state), the description is thin. It does not explain how the legacy since_state relates to messages_since_state, folders_since_state, etc. — a genuine gap an agent could trip on. Output schema and 100% schema coverage offset this somewhat, but the multi-cursor complexity warrants more guidance.

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% — all 10 parameters have individual descriptions in the input schema, so the baseline of 3 applies. The description adds no parameter-level detail beyond the schema, though its cursor-resume framing helps contextualize the various *_since_state parameters.

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 purpose: resume mailbox sync from a prior state cursor. The verb 'resume' plus 'prior state cursor' makes the operation precise, and the explicit exclusion of ad hoc message search differentiates it from siblings like mailbox_list_messages and mailbox_search_message_snippets.

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 when-to-use (resuming sync from a cursor) and an explicit when-not-to-use (ad hoc search). However, it does not name the alternative tools to use for ad hoc search, so the agent must infer which sibling handles that case.

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, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context: it validates the current credential, reads specific connection-level data, and explicitly states that no mailbox selection or storage access is required. This is consistent with the annotations and goes beyond what they state.

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

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

The description is two sentences with no wasted words. It front-loads the core purpose, lists the specific data returned, and adds a relevant scope constraint about mailbox selection and storage access. Every sentence earns its place.

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

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

For a simple read-only tool with one optional parameter, an output schema, and strong annotations, the description is largely sufficient. It explains the purpose, scope, and key behavioral constraint. It does not explicitly route agents to sibling tools, but that gap is minor given the tool's simplicity and rich structured metadata.

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

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

The schema has one optional parameter, If-None-Match, with a description covering its ETag behavior, so schema description coverage is 100%. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific action: validate the current Mailbox credential and read team, connection label, permissions, and authorised mailboxes. It clearly distinguishes itself from mailbox-content tools by noting that no mailbox selection or mailbox storage access is required, though it does not explicitly name or contrast sibling tools like mailbox_get_session.

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 its use for credential validation and connection metadata retrieval, and the 'no mailbox selection or mailbox storage access is required' line hints at when it is not appropriate. However, it provides no explicit guidance about when to prefer this tool over alternatives such as mailbox_get_session or sending_get_connection.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower, yet the description still adds real behavioral content: the required mailbox.read scope and the instruction to retain the revision and schedule version for subsequent mutations, which is optimistic-concurrency guidance not visible in the annotations. It does not explain what happens on a stale revision or how the 304 path behaves, so it is not exhaustive.

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 with no filler; the action and its scope come first, followed by the precondition and the follow-up obligation. Every clause contributes distinct 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?

With an output schema present, return values need not be described, and the annotations cover the safety profile; the description fills the remaining gaps of auth scope and version retention. The phrase "schedule version" is left unexplained, a minor gap for a tool whose whole point is version bookkeeping.

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 draftId, mailbox_id and If-None-Match are already documented with their targeting and conditional-request semantics. The description mentions revisions but does not add input-level detail (such as how the revision relates to If-None-Match), so the schema carries the load and 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?

"Read a saved draft and its current revision" states a specific verb and resource, and adds scope (current revision) that separates it from a plain listing call. It does not explicitly name sibling tools like mailbox_list_drafts or mailbox_update_draft, so differentiation is implied through the workflow 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?

"before editing or sending" gives clear context for when this read is the right call, positioning it upstream of update/send operations. It stops short of naming the alternative tools or stating when-not to use it (e.g., bulk inventory of drafts), which keeps it below 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 cover read-only, idempotent, non-destructive behavior. The description adds context about reading sender identity and display name before composing replies, but does not disclose additional behavioral details such as error conditions or auth requirements. No contradiction with annotations.

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

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

Two short sentences carry the purpose and the key usage context without any filler. The information is front-loaded and every word contributes to the agent's understanding.

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 read-only tool with one optional parameter, an output schema, and strong annotations, the description is nearly complete. It could slightly improve by mentioning when to prefer mailbox_list_identities, but this is not a major gap given the clear composing-replies scenario.

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 parameter schema has 100% coverage and already explains mailbox_id clearly, including when to omit it. The description does not add parameter-specific guidance, but with such strong schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool reads the mailbox sender identity and display name, using a specific verb and resource. It does not explicitly differentiate itself from sibling tools like mailbox_list_identities, but the singular 'mailbox identity' and the composing-replies context imply the intended use.

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

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

The description gives an explicit use case: use this before composing replies when the sender should match the mailbox identity. It lacks explicit exclusions or alternatives, but the context is clear enough for an agent to select this tool for the stated scenario.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the 'currently in use' mailbox targeting nuance, but it does not describe caching/304 behavior or edge cases; the schema's If-None-Match parameter description covers the 304 behavior instead.

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; the main use-case is front-loaded in the first sentence and the return value in the second. Every sentence earns its place.

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

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

For a simple read-only profile tool with no required parameters, rich annotations, 100% schema parameter coverage, and an output schema, the description is sufficient. An agent has everything needed to invoke it and interpret the basic 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 100%, so both params (mailbox_id and If-None-Match) are already documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, which yields the baseline score of 3.

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 clear verb ('identify', 'returns') and a specific resource ('authenticated mailbox' / 'mailbox key currently in use'), making the tool's function obvious. It does not explicitly distinguish itself from sibling tools like mailbox_get_identity or mailbox_get_session, so it stops short of full differentiation.

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

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

It gives a concrete usage context: 'before acting on mail', which tells an agent when this lightweight profile lookup is appropriate. It does not state when not to use it or name alternatives, so it lacks explicit exclusion/alternative guidance.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds only the implication that it returns a summary rather than a body and that a detail mode exists, without saying how to trigger it. It does not mention that If-None-Match can return 304, although the schema documents that.

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 primary action first and the alternative routing second. Every sentence carries information, and there is no redundant restatement of the title.

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

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

An output schema exists, so return values need not be explained, and the parameters and annotations are rich. The only real gap is the unexplained distinction between 'summary' and 'detail' modes, which leaves ambiguity about what this call actually returns.

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 three parameters are already documented, including mailbox_id scoping and the weak ETag for conditional requests. The description mentions message_id but adds no meaning beyond the schema, such as ID format or what happens when mailbox_id is wrong. Baseline 3 is appropriate because the schema does the heavy lifting.

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: fetch one message by message_id, scoped to a single message rather than a list. It also names the siblings that should be used instead when body content is needed, which helps distinguish it. However, the phrase 'summary or detail' is never explained: no parameter controls that choice, so an agent cannot tell which response it will get.

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

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

The description gives an explicit routing rule: use mailbox_list_body or mailbox_list_content when body content is required, implying that this tool returns metadata or summaries. It does not address other close alternatives, such as mailbox_batch_get_messages for multiple IDs or mailbox_get_thread for conversation context, so the guidance is good but incomplete.

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 read-only, idempotent, non-destructive and open-world behavior, so the description is not carrying the safety burden. It still adds genuine context beyond the annotations: the result is a policy intersection, subdomains need separate authorisation, and the permissions are re-validated at send time, which tells the agent the result is advisory rather than a guarantee.

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

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

Three sentences, none obviously wasteful, but the opening sentence is a dense chain of policy jargon that front-loads mechanics instead of the tool's outcome. Leading with what the tool returns would make the text far easier to act on.

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 spelled out, and the description covers the policy-intersection logic, the subdomain caveat and the re-check at send time. What is missing is a plain statement of what a 'choice' actually is (address? identity? provider account?) and whether results are filtered by the delivery group or merely annotated by it.

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 (mailbox_id, If-None-Match, delivery_group_id) are already documented in the schema. The description adds only a light gloss by referring to 'selected delivery groups', which corresponds to delivery_group_id, but says nothing about mailbox scoping or the ETag caching parameter. 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 explains how the result is computed (an intersection of team, inbox and credential policies with provider restrictions and delivery groups) but never states plainly that the tool returns the set of sender addresses/identities that may be used. The verb is implicit and buried in 'Intersects', so an agent must infer the output type from the title rather than the body text.

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 explicit when-to-use instruction and no reference to an alternative. The clause 'Sending checks these permissions again before submission' hints that this is a pre-send check, but the agent must derive that call ordering itself, and nothing says when this tool should be skipped (e.g., if the caller already knows the allowed sender).

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, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds only that the payload contains capabilities, limits, and endpoint metadata, without describing caching semantics, variability of the response, or what 'limits' concretely means. Useful but thin beyond the structured fields.

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

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

Two short sentences with zero filler; the intended use is front-loaded and the exclusion follows immediately. Nothing is redundant with the title or restated needlessly.

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

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

An output schema exists, so return values need not be explained, and the description covers the essential purpose and one key exclusion for a low-complexity, zero-required-parameter tool. It stops short of clarifying how it relates to the many overlapping sibling discovery/connection tools, which would have made it 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 description coverage is 100%, so both parameters (mailbox_id and If-None-Match) are already fully documented in the schema, establishing the baseline of 3. The description contributes no additional meaning about when to supply mailbox_id or how conditional requests interact with this 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 names a specific function — discovering supported mailbox capabilities, limits, and endpoint metadata — which is a distinct outcome rather than a restatement of the name. It also explicitly separates itself from message search, so an agent can tell it is a discovery/metadata call rather than a data read.

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

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

It gives a clear positive trigger ('before complex mailbox work') and a clear negative exclusion ('do not use it for message search'). It does not name the alternative tool to use for search, nor does it distinguish itself from near-duplicate discovery siblings such as mailbox_get_connection or qubrics_mailbox_get_session.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile needs no restating. The description adds the useful fact that the payload is a thread 'summary' rather than full messages, but says nothing about what the summary contains, pagination, or how the If-None-Match/304 path behaves in practice (that is only implied by the schema field).

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 tight sentences, purpose first then the alternative, with no filler. Slightly clipped — it reads more like a routing note than a full definition, but nothing 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?

With an output schema, full parameter documentation and complete annotations, the description only needs to establish scope and routing, which it does. The remaining hole is the prerequisite relationship to mailbox_list_threads for sourcing a thread_id and the distinction from the duplicated qubrics_mailbox_get_thread.

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%, including the mailbox_id targeting rule and the weak-ETag caching semantic, so the schema carries the parameter burden. The description only echoes thread_id, adding no meaning beyond the schema; 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 names a specific verb and resource ('read one thread summary') and keys it to thread_id, which is enough to separate it from the message-list siblings. It does not differentiate itself from mailbox_list_threads or the duplicate qubrics_mailbox_get_thread, so the agent must still infer ordering within the thread family.

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

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

It explicitly routes the agent: use this for the thread summary, use mailbox_list_thread_messages when the messages themselves are needed. That is a concrete when-to-use with a named alternative. The gap is how a thread_id is obtained in the first place (mailbox_list_threads) and whether this must be called before the message list.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context about response granularity (raw/simplified body, not full MIME details), which goes beyond what annotations express.

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 with no filler. The verb, resource, precondition, and selection guidance are front-loaded and every sentence earns its place.

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

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

The schema covers all parameters, an output schema exists, and annotations cover safety guarantees. The description provides enough decision context for an agent to invoke the tool correctly, though explicit sibling routing for full-MIME or attachment needs would make it 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 100%, so the baseline is 3. The description adds general context about body versus MIME details but does not explain parameter-specific behavior beyond what the schema already 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?

The description states a specific verb ('read'), a specific resource ('body'), and a precise scope ('for a known message_id'). It also distinguishes the tool from generic message retrieval by clarifying that it returns raw or simplified body content and omits full MIME detail.

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

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

The description gives an explicit preference condition: use it when the task needs message text but not every MIME detail. This gives an agent useful selection context, though it does not name specific alternative tools or explicitly say when not to use it.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower; the description still adds real value by disclosing the required calendar.read scope and the eventual-consistency trait of UID search. The warning that an empty lookup leaves an uncertain create unresolved and must not be retried is exactly the kind of behavioral context annotations cannot convey.

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

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

Three short sentences, front-loaded with purpose, followed by the auth requirement and the consistency caveat in priority order. Slightly hurt by the awkward phrasing 'never authorises repeating it', which a reader has to parse before understanding the retry prohibition.

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 annotations declaring the safety profile, an output schema covering return values, and full schema parameter descriptions, the remaining burden is auth and consistency semantics — both are stated. An agent can select and invoke this tool correctly without further inference.

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

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

Schema description coverage is 100%, so every parameter (uid, limit, cursor, mailbox_id, calendar_id) is already documented in the schema, including the mailbox_id omit-when-single-mailbox rule. The description only restates the UID lookup mode and adds no syntax, range, or interaction detail beyond the schema, 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?

States a specific verb and resource ('List events in the selected mailbox') and adds a second mode ('look up a caller-held UID'), so the agent knows this tool both enumerates and fetches by UID. It stops short of naming the closest sibling (mailbox_get_calendar_event) which appears to be the dedicated single-event fetch, leaving the mode overlap unresolved.

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?

'Requires calendar.read' gives a clear prerequisite, and the two operating modes imply when the uid parameter path applies. However, there is no explicit when-to-use versus mailbox_get_calendar_event or mailbox_get_calendar_event_changes, and no guidance on when to paginate through the full mailbox listing versus targeting a UID.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description usefully adds the required permission and the cursor-based pagination contract, but leaves openWorldHint and the actual return shape unexplained despite a list of calendars potentially spanning accounts.

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, each earning its place: what it does, what auth it needs, how to page. It is front-loaded and free of filler, though it is terse enough that it borders on under-specified.

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 values need no explanation, and all three parameters are documented in the schema. The description covers permissions and paging, which is nearly everything an agent needs for a simple read-only list operation; only the relationship to sibling calendar tools 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 100%, so limit, cursor, and mailbox_id are already fully documented, including the omit-when-single-mailbox rule. The description reinforces the paging semantics of limit and cursor but adds no new parameter detail beyond that.

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 opens with a specific verb and resource ('List calendars in the selected mailbox'), which distinguishes it from mailbox_list_calendar_events and mailbox_get_calendar. It stops short of naming the closest sibling, so the agent must infer that this enumerates calendar containers rather than calendar events.

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

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

It gives two concrete operating instructions: the required scope (calendar.read) and the paging pattern (small limit, continue with returned cursor). It does not say when to prefer mailbox_get_calendar or when listing is unnecessary, so usage is implied rather than contrasted.

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

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

The annotations already declare this as read-only, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds little behavioral detail beyond the general content scope: it does not mention truncation behavior, ETag/304 semantics, mailbox scoping, or that attachment contents are excluded.

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

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

The description is two sentences, front-loaded with the main action, and contains no redundant restatement of the title or schema. Every sentence contributes to identifying the tool's intended use.

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 tool has 11 parameters, rich annotations, full schema coverage, and an output schema, which reduces what the description must cover. Still, with many similar mailbox-reading siblings, the description is thin on routing guidance and behavioral expectations, leaving an agent to infer when this tool is better than mailbox_get_message or mailbox_list_body.

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 input schema fully documents parameters such as part, include_headers, strip_quotes, and If-None-Match. The description mentions message_id and general content categories, but adds no meaning beyond what the schema already 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?

The description states a specific action and target: read structured content for a known message_id, with headers, participants, and body parts as relevant details. It is clear enough on its own, but it does not differentiate this tool from close siblings such as mailbox_get_message or mailbox_list_body.

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

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

It gives a usable condition: use it for a known message_id and prefer it when headers, participants, or body parts affect the answer. However, it provides no when-not guidance and does not name alternatives among the many overlapping mailbox read tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds value beyond that by disclosing the required scope (mailbox.read), the sort order (newest first), and the cursor-based pagination contract.

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, zero filler, with the purpose and ordering front-loaded before the permission and pagination notes. Every sentence carries information an agent would otherwise have to infer.

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

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

For a read-only paginated list tool with full schema coverage, an output schema, and rich annotations, this covers scope, auth, ordering and pagination. Only the routing to sibling tools for draft detail or message listing is left implicit.

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 limit, cursor and mailbox_id are already fully documented, and the baseline of 3 applies. The description only adds the soft heuristic "use a small limit," without clarifying cursor lifetime, stability across pages, or mailbox_id omission behavior beyond what the schema states.

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 saved drafts") plus scope ("in the selected inbox") and ordering ("newest first"). It does not name a sibling such as mailbox_get_draft or mailbox_list_messages to disambiguate draft-listing from message-listing, 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?

Provides real usage context: the required scope mailbox.read and explicit pagination advice ("Use a small limit and continue with the returned cursor"). It gives no when-not guidance or named alternative for cases where the caller wants full message listings instead.

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 carry readOnlyHint, idempotentHint, and destructiveHint=false; the description merely restates 'read-only' and adds no new behavioral traits like pagination or auth. No contradiction.

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

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

Two short sentences, front-loaded with purpose and no filler. Every word earns its place.

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

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

With full schema coverage, an output schema present, and annotations covering read-only and idempotent behavior, the description's purpose and use-case complete the picture.

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%, and the description relies on the schema for parameter details. It adds no extra semantics, which meets the baseline.

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

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

Description identifies a specific verb ('inspect') and resource ('mailbox folders'), plus a clear use case. It doesn't explicitly differentiate from sibling tools, but 'folders' is distinct among the sibling list.

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

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

States a concrete trigger: before filing or moving messages. It doesn't mention alternatives or when not to use, so it doesn't reach 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: it searches only the granted mailbox set and returns IDs intended for mailbox_id, which goes beyond the annotations without contradicting them.

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-load the usage condition ('Use this first') before stating scope and output. Every sentence earns its place 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?

For a simple read-only list/search tool with fully documented optional parameters and an output schema, the description covers why to use it, when to use it, its scope, and how its result is consumed downstream. Nothing essential is missing for correct invocation.

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

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

The input schema provides full descriptions for q, limit, and cursor, with 100% coverage. The description adds no parameter-level semantics beyond that, so the schema carries the load and the baseline of 3 is appropriate.

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

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

The description states a specific verb ('searches') and resource ('mailboxes granted to this connection'), and clarifies the output: IDs to pass as mailbox_id. 'Use this first' positions it as the discovery tool among sibling mailbox operations, making its purpose distinct.

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

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

The description explicitly says to use this tool first when the token can access more than one mailbox, giving a clear trigger condition. It does not name alternatives or state when not to use it, so it stops short of full exclusion guidance.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description does not add additional behavioral context (e.g., pagination details or rate limits), but with the output schema present and the annotations strong, a baseline 3 is appropriate.

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 with no fluff. The primary purpose is in the first sentence, and the sibling distinction is delivered concisely in the second. Every word earns its place.

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

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

Given that the output schema is present (so return format is documented), the annotations cover safety, and the parameters are fully explained in the schema, the description covers all essential decision points. It could add a note on pagination behavior, but the cursor parameter implies it, making this a minor gap. Overall, it's complete for an agent to call 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 description coverage is 100%, meaning all three parameters (limit, cursor, mailbox_id) already have clear documentation in the schema. The tool description does not add any extra nuance beyond what the schema provides, so it meets the baseline of 3 without adding value.

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

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

The description states a clear verb ('list') and specific resource ('sender identities available to the mailbox'), and it explicitly differentiates from the sibling mailbox_get_identity by naming the condition under which that alternative is preferred. This leaves no ambiguity about what the tool does.

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

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

The description explicitly tells when to use this tool (to list all identities) and when to prefer the alternative 'mailbox_get_identity' when only the default identity is needed. This provides direct routing guidance without requiring 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for what it adds: cursor-based pagination and, notably, that attachment metadata carries a short-lived download_url — an operational constraint an agent could not learn from the schema. It stops short of describing result shape or default ordering, but the output schema covers returns.

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

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

Two sentences, front-loaded with the core behavior and followed by a compact filter inventory. The filter enumeration partly restates what 24 well-described parameters already say, but it is short enough to earn its place as a quick orientation.

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 24-parameter, all-optional filtered-list tool with an output schema, the description covers the essential model: metadata-only scanning, cursor pagination, filterable dimensions, and the short-lived attachment URL caveat. Missing only marginal items such as default ordering or the interaction between cursor and changing filters.

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% across all 24 parameters, so each filter is already fully documented. The description groups the filters into categories (dates, sender/recipient, keyword, unread, attachment) but introduces no syntax, precedence, or combination rules beyond the schema, 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?

"Scan mailbox messages by cursor without fetching full bodies" states a specific verb, resource, and a distinguishing scope (metadata-only, not full bodies). That implicitly separates it from mailbox_get_message / mailbox_list_body. It does not name any of its many close siblings (list_thread_messages, search_message_snippets, count_messages), so differentiation is inferred 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?

"Use this to scan..." gives an implied context and the no-full-bodies framing hints that a body-fetching tool is the follow-up. But there is no explicit when-to-use vs. when-not, and with 8+ overlapping list/search siblings an agent still has to guess whether this or list_thread_messages, list_content, or search_message_snippets is correct.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description's one added behavioral fact is that results are not full message bodies, which is genuinely useful; it says nothing about result ordering, pagination behavior, or what happens on an unknown thread_id.

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, the primary purpose front-loaded and the fallback guidance second. Nothing is repeated from the schema and no sentence is filler.

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

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

With an output schema present and full parameter coverage, return-value and pagination details need not be restated. The only meaningful gap is the relationship to sibling tools like mailbox_get_thread and mailbox_list_messages, which an agent must infer from names alone.

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% and all five parameters, including sort direction, limit bounds, cursor semantics and the multi-mailbox targeting rule, are documented in the schema. The description adds no parameter-level meaning beyond that, 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?

States a specific verb and resource: list messages inside a known thread. That distinguishes it from mailbox_list_messages (all messages) and mailbox_get_thread (thread metadata), though it never explicitly names those siblings.

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 prerequisite (a known thread) is stated, and the second sentence routes the agent away from this tool toward 'message body tools' when full content is needed. It stops short of naming the concrete alternative (e.g. mailbox_list_body or mailbox_get_message), leaving the mapping 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?

Annotations already declare read-only, idempotent, non-destructive and open-world. The description adds one real piece of behavior beyond that: results are thread-level scans that do not load full messages, plus lazy pagination advice. It says nothing about default ordering, result caps, or the mailbox_id scoping/auth behavior that matters for an 11-param listing tool.

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

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

Two short sentences, front-loaded with the purpose and followed by the pagination constraint. There is a little filler ("Use this to") and the second sentence largely echoes the cursor schema description, but nothing extraneous.

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 and rich annotations, the description does not need to explain return values, and the schema covers all 11 parameters. However, for a tool whose name invites confusion with the many sibling list/get tools, it lacks the disambiguation an agent needs to make a correct first choice.

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 every parameter is already documented. The description only restates cursor pagination ("continue with next_cursor"), adding essentially no meaning beyond the schema. 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?

"Scan conversation threads without loading every message" gives a clear verb and resource and hints at why this differs from a full thread/message fetch. It stops short of naming the sibling alternatives (mailbox_get_thread, mailbox_list_thread_messages), so an agent must infer the distinction.

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

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

It gives one concrete usage rule — request the next page only when more threads are actually needed — which is useful operational guidance. It never states when to prefer this over mailbox_get_thread or mailbox_list_thread_messages, so selection guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description does add useful behavior beyond them: server-side download of text attachments and metadata-plus-fresh-link fallback for binary or oversized files. It says nothing about permissions, mailbox scoping, or failure modes.

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 usage trigger and followed by the two behavioral cases. The web_fetch remark earns its place by preventing a detour, and there is 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?

An output schema exists, so return-value detail is not required, and the description covers the main branching outcomes (inline text vs. metadata plus link). The remaining gap is sibling disambiguation within a very crowded attachment-tool family.

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, and the description goes slightly beyond by explaining that oversized attachments degrade to a link, which is the semantics behind max_text_bytes. It does not mention the mode parameter or mailbox_id scoping, leaving those entirely to 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 clear verb and resource (read an attachment's contents) and ties it to a trigger (after finding a message attachment). It does not distinguish itself from close siblings like mailbox_get_attachment, mailbox_get_attachment_text, or mailbox_request_attachment_text, so an agent must infer which of the look-alikes 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?

Gives a clear entry condition (after locating an attachment when you need its contents) and explicitly closes off one alternative (generic web_fetch). It is silent on the real ambiguity, though: nothing says when to prefer this over get_attachment, get_attachment_text, or request_attachment_text.

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

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

The annotations already state idempotent=true, destructive=false, and readOnly=false; the description adds value by explaining the 24-hour cached-reuse behavior and the mailbox.read authorization requirement. It also discloses the OCR limitation and the failed-extraction path, which annotations cannot convey. The instruction to 'check status and outcome' stays vague about where or how, but the presence of an output schema offsets that.

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, with the core action and the size and cost constraint front-loaded, followed by the authorization, caching, and fallback notes. Every sentence carries operational information, though 'at no extra charge' reads as promotional filler and the size figure adds ambiguity rather than clarity.

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 four-parameter tool with a full output schema, the description covers authorization, cost, caching, limits, and failure handling, so the agent can call it correctly. The remaining gaps are sibling disambiguation and the ambiguous byte limit, which are notable but not blocking.

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, and the description does not clarify any parameter beyond the schema. The phrase 'up to 7500000 bytes' is potentially misleading next to a max_bytes parameter whose maximum is 1048576, and the description never explains that the 7.5 MB figure is presumably the attachment-size limit; an agent could conflate the two.

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 ('Extract readable text from an attachment'), so the agent knows exactly what the tool does, and it adds a scope limit and cost note. It does not, however, distinguish this tool from close siblings such as mailbox_get_attachment_text and qubrics_mailbox_request_attachment_text, so an agent cannot tell the request and immediate-get variants apart from the description alone.

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

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

It gives useful operating guidance: the required mailbox.read scope, the fact that OCR is unavailable, and the fallback to the original download when extraction cannot complete. It never states when to choose this over the existing get_attachment_text sibling or what error conditions should trigger a retry rather than a fallback, so the when-to-use decision is only implied.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds a distinct behavioral disclosure beyond those annotations: snippets may not be sufficient for content-specific claims, so agents must read the underlying messages first. This is valuable context that the schema and annotations do not provide.

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 with no wasted words. The main purpose is front-loaded, filters are compactly grouped, and the critical read-before-claim caveat is placed at the end. It avoids repeating schema details and is easy for an agent to parse.

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

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

For a 21-parameter tool, the description is sufficient because the schema documents every parameter and the output schema covers the return shape. The annotations fully cover the safety profile, and the description adds the one operational caveat an agent needs: read full messages before making content-specific claims. Nothing critical 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?

All 21 parameters already have description coverage in the input schema, so the description does not need to explain individual fields. It adds a useful thematic grouping of filters, but no additional syntax or semantic meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a specific action and resource: 'search message snippets by query text.' This clearly identifies the tool as a snippet search rather than a full-message retrieval or listing tool, and the closing instruction to read full messages reinforces that it returns snippets/IDs. It is unambiguous and differentiates from siblings like mailbox_get_message and mailbox_list_messages.

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

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

The description states the primary use case and enumerates the main narrowing dimensions: folder, keyword, dates, sender/recipient, unread state, and attachments. It also gives a clear operational caution: use returned message IDs with a read tool before making content-specific claims. However, it does not explicitly name the read tool or state when not to use this tool versus a sibling, so the guidance is strong but not fully explicit.

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 this as a non-read-only, non-idempotent, non-destructive, open-world operation. The description adds genuinely new behavioral context beyond them: required scopes (mailbox.read and email.send), the optimistic-concurrency contract that a stale expected_revision returns a conflict, and the 30-day scheduling horizon. It stops short of saying what happens to the draft after a successful send.

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 the approval constraint, then escalating to the optional scheduling path. Every sentence carries requirement or precondition information, though the telegraphic phrasing ('Requires mailbox.read and email.send') is terse enough to read as a checklist.

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 annotations covering the safety profile, a full output schema, and 100% schema description coverage, the description only needs to supply auth requirements, precedence, and conditional-parameter logic — all of which it does. The one residual gap, post-send draft state, is plausibly covered by the output schema.

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

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

Schema coverage is 100%, so the schema already documents every parameter individually and the baseline is 3. The description adds conditional interaction logic the schema does not express — expected_revision as mandatory, and expected_schedule_version being required both for scheduling and after a schedule cancellation — but offers no detail on If-Match or mailbox_id handling.

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 ('Send... the saved revision') and adds a distinguishing scope: only the revision the user approved, implying a guarded send rather than a generic send. It never names the closest siblings (mailbox_send_message, mailbox_update_draft), so the separation is implied by scope 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?

Usage conditions are conveyed through parameter preconditions ('to schedule within 30 days also pass scheduled_for', 'after cancelling a schedule, include the current schedule version'), which tells the agent when each mode applies. There is no explicit statement of when to choose this over mailbox_send_message or mailbox_control_draft_schedule, and no exclusion of unsaved/composed content.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real operational context beyond them: the two-step attachment flow with an alternative for small inline payloads, and the 24h retry-safety contract implied by the Idempotency-Key. The instruction to supply an Idempotency-Key is consistent with idempotentHint=false, since it tells the agent how to achieve safe retries on a non-idempotent endpoint rather than contradicting the annotation.

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

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

Three short sentences, action first, with the prerequisite workflow and retry advice front-loaded and no filler. Every sentence maps to something the agent must do differently at call time.

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?

Rich structured data (full schema coverage, annotations, output schema) carries most of the burden, and the description covers the two non-obvious mechanics. However, for a 12-parameter, nested-object, open-world send tool with dozens of overlapping siblings, the absence of any sibling disambiguation or delivery-side-effect note (recipient limits, sender defaults are only in schema) leaves a meaningful 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 description coverage is 100%, so the schema already documents every parameter including blob_id provenance, the mailbox_id targeting rule, and the Idempotency-Key conflict behavior. The description's attachment guidance largely restates schema content, adding only the ordering ('call ... first ... then pass'), so 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 ('send a message from the authenticated mailbox'), so the core action is unambiguous. It even names the prerequisite sibling mailbox_upload_attachment, but it never distinguishes itself from other send paths in the sibling list (mailbox_send_draft, qubrics_mailbox_send_message, sending_send_email), leaving an agent to infer which send 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?

Gives explicit conditional guidance for two cases: attachments (upload first, then pass blob_id) and retries (include an Idempotency-Key). What is missing is the primary routing decision — when to compose-and-send here versus creating a draft or using the sending_* family — which is the most consequential choice an agent faces with this sibling set.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, open-world. The description adds genuine value on top: no invitations or reminders are dispatched, a write scope is required, and the If-Match concurrency contract with reload-on-conflict behavior is stated. It stops short of saying whether omitted fields are preserved or cleared.

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, each carrying distinct information: the action, the required permission and concurrency token, and the conflict recovery step. Nothing is wasted and the key constraint 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?

With an output schema present, return values need no explanation, and the description covers permissions and concurrency well. The remaining gap is update semantics: whether this is a full replace or a partial patch, and whether an omitted field such as duration is preserved or cleared.

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 eight parameters are already documented in the schema, and the description correctly adds no redundant re-listing. The only parameter-level context it contributes is that If-Match must be the 'reviewed' value, a modest addition over the schema's own wording. Baseline 3 is appropriate here.

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

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

The description states a specific verb and resource ('Edit an event') and adds a distinguishing behavioral detail: no invitations or email reminders are sent. It does not explicitly name the sibling it contrasts with (mailbox_create_calendar_event), so differentiation is implied rather than spelled out.

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

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

It gives real preconditions ('Requires calendar.write and the reviewed If-Match value') and a procedural rule for the conflict case ('Reload after a conflict before making another change'). What's missing is explicit routing: when to use this versus create_calendar_event or the qubrics_ prefixed variant is left to inference.

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