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

Annotations already declare this as a safe read-only operation, so the bar for additional disclosure is lower. The description adds valuable behavioral context beyond annotations: it exposes the `online` field and explains the consequence of `online: false` for send_imessage, namely queuing without dispatch until the Mac is back online.

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 tool's purpose and followed by the operational caveat that affects send_imessage. Every sentence adds clear value with no repetition 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 no-parameter status check with annotations covering safety, the description is complete enough to call correctly. It explains the key result field (`online`) and the important downstream behavior when the agent is offline.

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?

This tool takes no parameters, so there are no parameter semantics to document. Per the evaluation baseline, a zero-parameter tool receives 4 when the description does not create confusion about inputs.

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

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

The description states a specific verb and resource: checking whether the user's Mac agent is running and able to dispatch iMessages. It also explicitly connects the result to send_imessage, which distinguishes it from sibling tools like get_draft_status or list_drafts.

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

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

The description clearly implies when this check matters by explaining that if `online: false`, send_imessage will queue a draft without dispatching it. It does not explicitly say to call this before send_imessage or compare it directly with get_draft_status, but the context is strong and unambiguous.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds genuinely useful behavior beyond them: the operation is soft (not a hard delete), it is gated on `sent: false`, and an out-of-window call yields 409 Conflict. It does not say whether the cancellation is reversible or what the success payload contains.

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 with the mutation semantics front-loaded and the precondition and error behavior following. No filler and nothing repeated from the schema.

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

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

For a one-parameter state-changing tool with no output schema, the description covers what it does to state, the eligibility window, and the error outcome. Minor gaps remain around reversibility and return value on success.

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

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

With a single fully documented parameter (schema coverage 100%), the schema already carries all semantics for draft_id. The description adds situational context about which draft is eligible but no format, sourcing, or lookup guidance. Baseline 3 is appropriate when the schema does this much work.

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

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

States a specific verb ('Soft-cancel') and resource ('pending draft') plus the scoping condition 'before the Mac agent dispatches it', which separates it from siblings like get_draft_status and list_drafts. It never names an alternative tool explicitly, so the differentiation is implicit 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?

Gives a clear operating condition ('Only works while the draft is still `sent: false`') and the failure case ('Once sent, this returns 409 Conflict'), which tells the agent when the call will succeed. It does not say whether the agent should first verify state with get_draft_status, so the pre-call workflow 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.

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

Annotations already flag readOnlyHint=false, destructiveHint=true, openWorldHint=true, and the description adds real context the annotations don't: the operation is an upsert (so it can modify existing data, not just insert), it is one-way, and changes do not propagate to native macOS/iOS Contacts. That non-obvious side effect is exactly the kind of disclosure the agent needs; what's missing is what an upsert collision overwrites and whether any auth/confirmation is required.

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 verb and action, then the trigger, then the constraint, then the caveat. Nothing is redundant; every sentence carries information the agent would otherwise lack.

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 4-parameter mutation with no output schema and annotations covering the safety profile, the description supplies the trigger, the minimum-data rule, and the sync caveat. The remaining gap is what the call returns and how upsert matching/overwrite behaves, which an agent would need to proceed confidently on an existing contact.

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 per-field meanings are already handled, and the description still contributes a cross-field constraint ('at least one of phone_number or email') that the schema does not express — required is empty and there is no anyOf. It does not explain how the upsert matches an existing contact (by phone, email, or name), which leaves the most important parameter interaction unstated.

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 or upsert a contact') and immediately clarifies the colloquial trigger ('save' a new person). It is distinguishable from list_contacts and find_contact by implication (writing vs reading), but never names or contrasts those siblings explicitly.

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 when the user asks to "save" a new person to their address book' gives a concrete usage trigger, and 'Requires at least one of phone_number or email' states a precondition. It stops short of saying when NOT to use it or how it relates to find_contact/list_contacts, so no exclusion or alternative is offered.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds genuinely useful matching semantics beyond the annotations: results are the 'closest matches' by 'case-insensitive substring', telling the agent to expect fuzzy, ranked, possibly multiple results rather than an exact lookup.

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: what it does, how matching works, when to use it. Each sentence earns its place and the core purpose is front-loaded.

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

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

For a simple 2-parameter read tool with a fully documented schema and safety annotations, the description covers purpose, matching behavior, and the calling context. It stops short of saying whether returned handles are directly usable for send_imessage or what happens when no match is found, but no output schema exists to fill that gap.

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

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

Schema coverage is 100% and both parameters are already documented there, so the baseline is 3. The description restates that the query spans name/phone/email as a substring, roughly duplicating the schema rather than adding new syntax or format guidance, and says nothing about the limit parameter.

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

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

The description states a specific verb and resource ('Search the user's contacts') and names the searchable fields (display name, phone, email), which tells an agent exactly what the tool retrieves. It does not explicitly distinguish itself from the sibling list_contacts, so the boundary between searching and listing is left implicit.

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 final sentence gives a concrete trigger ('when the user references someone by name to resolve them to a sendable phone/email handle'), which is clear actionable context. It omits when NOT to use it — most notably browsing the whole contact list via list_contacts — so the alternative routing is only implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the genuinely useful trait of newest-first ordering, but says nothing about what a page contains, how pagination terminates, or rate limits.

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

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

Two sentences, front-loaded with the core behavior and ordering, then the use cases. No filler or restatement of the name.

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

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

With a fully documented 6-parameter schema and no output schema, the description covers the essential behavior. A brief note on return shape (sender, timestamp, body) would close the last gap for a tool whose output the agent must interpret.

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 every parameter including the cursor, time bounds and direction enum is documented in-schema, so the description correctly adds nothing and the baseline 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 ('Return the message history of a single conversation') plus the ordering ('newest first'), which distinguishes it from the list_* siblings that span many conversations. It stops short of naming the sibling it displaces (list_recent_messages), so the differentiation is implicit.

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 concrete use cases — catching up on a thread, summarizing, extracting context before drafting a reply — which tell the agent when this is the right call. It offers no exclusions or explicit 'use X instead when Y', so it falls short of a 5.

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

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

Annotations cover the safety profile (read-only, non-destructive), and the description goes well beyond them: it explains that `held` is a rolling-24h park that resumes automatically, that `blocked` is never auto-retried, and that `sendError` only appears on failed/cancelled. That lifecycle detail materially changes how an agent reacts to each status.

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

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

Purpose and the send_imessage sequencing are front-loaded, and every sentence carries information. The status enumeration is dense and parenthetical-heavy, which is efficient but costs some scannability.

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

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

With no output schema, the description carries the full return-value burden and does so by naming every field (`status`, `hold`, `sent`, `sendError`, `sentMessage`) and its conditions. Nothing needed to interpret a response 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?

There is a single parameter at 100% schema coverage, with the schema already stating it is the draft id returned from send_imessage. The description adds no format, prefix, or sourcing detail beyond the schema, 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?

"Read a single draft" is a precise verb+resource, and the description immediately scopes it against the write path by naming send_imessage and its post-send use. An agent can distinguish this from list_drafts or cancel_pending_draft without opening the schema.

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

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

Gives an explicit trigger ("Use this after send_imessage to confirm the message was delivered") and clarifies that a `held` status is not a failure, which prevents a wrong follow-up action. It stops short of naming alternatives such as list_drafts for bulk polling, so no explicit when-not routing.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the safety burden is light. The description still adds real value by explaining that contacts are auto-populated from macOS Contacts by the Mac agent plus manual additions, telling the agent why data may be partial or in flux.

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 resource. Each sentence contributes something, though the last sentence repeats a bit of the 'saved contacts' framing.

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

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

For a one-parameter read tool with annotations and no output schema, this covers what the resource is, where the data comes from, and a typical use. Only the relationship to find_contact is left unstated.

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

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

Schema description coverage is 100% and the single limit parameter is fully documented with range and default in the schema. The description adds nothing about parameters, 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?

Clear verb+resource: lists the user's saved iMessage contacts. The provenance sentence adds specificity about what a 'contact' is in this system. It does not distinguish itself from the sibling find_contact, which appears to target the same resource.

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 offers one implied usage scenario ('resolving "Sarah" to a phone number before sending'), which is helpful context. But it never says when to use this instead of find_contact or create_contact, so the agent must infer list-vs-lookup from names alone.

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

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

Annotations already declare readOnlyHint=true/destructiveHint=false, so the safety profile is covered; the description adds ordering semantics, loose-format number normalization, and the fact that participant matches 1:1 AND group threads while handle returns only the 1:1 thread. It does not mention rate limits or result-size behavior beyond the schema's limit default.

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

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

Four sentences, zero filler, and the core purpose plus ordering lead the description before any parameter guidance. The dense final sentence is compact but carries two distinct, non-redundant rules.

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 9-parameter, zero-required list tool with annotations and no output schema, this covers ordering, GUID reuse, filter routing, and mutual exclusion. It leaves unstated what an unfiltered call returns (the most recent conversations up to the default limit) and how pagination terminates, though the cursor param documents the mechanics.

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 would be 3, but the description adds a constraint that exists nowhere in the schema: at most ONE of participant, handle, name, group, or unread may be passed. It also clarifies that active_since/active_before/limit/cursor apply across all filter modes and disambiguates participant vs handle by intent.

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 ("Find the user's iMessage conversations") plus a meaningful default ordering ("most recently active"). It also flags the return value's key affordance ("Each has a GUID you pass to other tools"), which orients the agent toward the downstream siblings without naming them.

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

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

Gives explicit routing rules among the filter parameters: use `participant` to find conversations with a phone number, `name` for contact/group name search, and it states the mutual-exclusion constraint "Pass at most ONE of participant, handle, name, group, or unread." What's absent is any statement of when to choose this tool over siblings like list_recent_messages or get_conversation_history.

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 this as a safe read-only operation. The description adds useful behavioral context—default returns drafts in any state, and status is the preferred filter—but does not cover ordering, pagination behavior, or return shape beyond what the schema implies.

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

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

Three compact sentences, front-loaded with the core action and followed by use cases and default/filter guidance. No filler or repetition.

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

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

For a read-only list tool with full schema coverage and safety annotations, the description covers purpose, default scope, filter preference, and practical use cases. It lacks explicit detail on ordering or how filters combine, but no output schema exists to require return-value explanation.

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 a small but meaningful preference signal by recommending 'status' over the boolean shorthand filters, which helps an agent choose among overlapping filter 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?

The description opens with a specific verb and resource: 'List outbound drafts.' It immediately distinguishes the tool from siblings like get_draft_status and cancel_pending_draft by focusing on listing rather than status lookup or cancellation.

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 usage contexts—checking the Mac agent queue, held drafts, recently sent, or failed—and states the default behavior. It also expresses a filter preference ('status (preferred)') but does not explicitly name alternative tools or exclusion conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds behavior beyond that — result ordering (newest first), scope across all conversations, and cursor-based pagination. It doesn't discuss rate limits or result shape, but for a read-only list tool that is a modest 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?

A single sentence with the scope constraint front-loaded in caps, followed by the use cases, then the filtering/pagination capabilities. No filler; every clause carries information.

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

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

For a simple read-only list tool with fully documented parameters and explicit annotations, the description covers scope, ordering, filtering, and pagination — enough to call it correctly. Only the returned message fields are unstated, which is acceptable given the tool's simplicity and the absence of an 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%, including the enum and the instruction to pass pagination.nextCursor verbatim, so the schema does the heavy lifting. The description only restates the filter/pagination categories without adding format or default details (e.g., the 50 default, the 1-200 range).

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 resource (messages), a precise scope (ACROSS ALL conversations), and an ordering (newest first). The 'ACROSS ALL conversations' emphasis implicitly distinguishes it from get_conversation_history, which is per-conversation, so an agent can discriminate without opening schemas.

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

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

Gives concrete use cases ('catch me up', 'what did I miss today') that map to the cross-conversation, recency-oriented design, plus hints on filtering and pagination. It stops short of explicitly naming an alternative or an exclusion, so it's clear context rather than full routing guidance.

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

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

Goes well beyond the annotations by disclosing that sending creates a draft, that messages are still accepted and queued when the outreach limit is reached, what meta.queued contains, and that held drafts remain until capacity frees. It also explains the 403 STOP behavior, which is critical context for a destructive, open-world send operation.

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

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

The description is front-loaded with the core action and draft mechanism, then moves through delivery confirmation, recipient format, queue semantics, and opt-out handling. Every sentence carries operational value for a tool with non-obvious queuing and error behavior.

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

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

With no output schema, the description still explains what is returned (a draft id) and how queued responses differ (meta.queued and status 'held'). It covers the main edge cases an agent needs: invalid recipient format, outreach limit, and STOP opt-out.

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

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

Schema description coverage is 100%, so the schema already documents recipient format, body limits, and webhook parameters. The description reinforces the E.164/email recipient requirement but does not add meaning beyond the schema for the webhook parameters; 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?

States a specific verb and resource: 'Send an iMessage from the user's Mac.' It immediately explains the draft-based mechanism, distinguishing it from sibling tools like get_draft_status and cancel_pending_draft.

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

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

Explicitly directs the agent to use get_draft_status to confirm delivery, states the required recipient format, explains the queued-limit case, and specifies that a 403 recipient_opted_out must not be retried. This leaves little ambiguity about when and how to use the tool versus alternatives.

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