Outbound

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

Annotations already declare idempotent=true, destructive=false, readOnly=false, so the safety profile is partly covered. The description adds real behavioral detail beyond them: the saved body is overwritten with the suggestion, the record transitions to draft, and it stays unapproved until approve_sendable_wording. It omits auth requirements and what happens on a revision mismatch, but the state-transition disclosure is valuable.

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

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

Three tight sentences, front-loaded with the action and its effect on the record, then the approval caveat, then the non-obvious parameter note. No wasted words.

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 annotations cover the mutation safety profile. The description supplies the state transition and the parameter caveat, leaving only minor gaps like error handling on revision conflicts.

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

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

Schema description coverage is 0%, so the description carries the burden. It usefully disambiguates expectedRevision ('the wording revision, not the suggestion'), a genuinely non-obvious distinction, but says nothing about suggestionId or the failure behavior when expectedRevision is stale.

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 (accept) and resource (an open suggestion) and describes the resulting state change. It also names the sibling that governs the follow-up approval, so an agent can distinguish it from approve_sendable_wording without opening either 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?

Clearly frames the context of use ('Accept an open suggestion') and routes the agent to approve_sendable_wording for the related approval step, showing it is distinct from approval. It does not mention dismiss_sendable_change as the competing alternative when a suggestion is rejected, so the when-not guidance is 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 declare the safety profile (idempotent, non-destructive, mutating), so the bar is lower. The description still adds real behavioral value beyond the structured fields: 'Approval does not rewrite the body' clarifies the state-change-only nature, and the expectedRevision match requirement discloses the optimistic-concurrency guard.

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, with the core action and the no-rewrite constraint front-loaded before the revision precondition.

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 described, and annotations already carry the safety profile. The description covers the mutation semantics and the revision guard, leaving little an agent needs beyond distinguishing it from accept_sendable_change.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains expectedRevision ('must match the current draft') as a concurrency token, adding genuine value, but says nothing about wordingId beyond its self-evident name. Partial compensation for the coverage gap.

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

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

States a specific verb+resource ('Approve a draft') and clarifies the target is a user-accepted sendable draft. It does not explicitly contrast itself with the similarly named sibling accept_sendable_change, leaving mild ambiguity, 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?

The precondition 'the user has explicitly accepted as sendable' gives implied usage context, but it never names an alternative or states when-not-to-use this versus accept_sendable_change or save_sendable_wording. Adequate but with clear gaps.

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, idempotentHint=true, openWorldHint=false). The description's only addition is the semantic clarification that creating a library is not an approval action, which is useful but thin; nothing is said about permissions, duplicate-name behavior, or side effects.

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

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

Two short sentences with the action front-loaded and no filler. The second sentence is oddly granular in its list of non-approvable items, but it is brief and does not bloat the definition.

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

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

An output schema exists so return values need not be described, and annotations carry the safety profile. Still, for a create tool with two undocumented parameters and no explanation of what a 'library' represents or how duplicates are handled, the description leaves meaningful gaps.

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

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

Schema description coverage is 0% and neither 'name' nor 'description' is annotated in the schema. The description adds no meaning to either parameter — no naming conventions, uniqueness expectations, or what the optional description field is for — leaving both under-specified.

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 ('Create') and resource ('a library for sendable wording'), which is enough to distinguish it from read/list siblings like list_outbound_libraries and get_sendable_wording. The term 'sendable wording' is domain jargon but is consistent with the sibling naming convention.

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 second sentence acts as a when-not clause ('does not approve... any other sentence'), which implicitly routes approval intent to approve_sendable_wording. However, it never states when to use this tool versus list_outbound_libraries or the save/suggest tools, so the guidance is implied 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?

Annotations already declare destructiveHint=false and idempotentHint=true, so safety and repeatability are covered. The clause 'The saved wording record stays as it is' adds real semantic value by clarifying that dismissal only closes the suggestion and does not alter the underlying wording record.

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

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

Two short sentences with no filler, and the action is front-loaded before the clarifying note. Efficient, though it is arguably too terse to carry usage context.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. However, for a mutation-style tool the description omits prerequisites (which suggestion states can be dismissed) and any mention of the required identifier.

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

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

Schema description coverage is 0% for the single suggestionId parameter, and the description never mentions it. The parameter is self-evident from name and type (uuid, required), but the description does nothing to compensate for the coverage gap.

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

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

The description states a specific verb and resource ('Dismiss an open suggestion') that is distinguishable from the sibling accept_sendable_change. It does not explicitly name that sibling, but the action is clear enough to route correctly.

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

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

There is no guidance on when to dismiss versus accept or otherwise act on a suggestion, and no alternative is named. The sibling accept_sendable_change is the obvious counterpart, but the description never references it or any condition for choosing this path.

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 non-destructive, so the safety profile is covered. The description adds real domain semantics beyond that: 'sendable is the exact body only when the record is approved' and 'Suggestions are not the record,' which prevents misreading the payload.

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, and the core action is front-loaded before the two disambiguating clauses about 'sendable' and 'suggestions.' 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?

An output schema exists, so return structure need not be explained, and the description appropriately focuses on the semantic caveat about what 'sendable' means, which is essential given the ambiguous domain jargon. Only the absence of routing guidance to siblings leaves a minor 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 0%, so the description carries the burden, yet it says nothing about wordingId beyond what the name implies (a uuid identifier). With a single self-evident required parameter, the gap is small, but no added meaning is provided.

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

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

The description states a specific verb and resource: 'Read one wording record and its suggestions.' The word 'one' implicitly separates it from the list_sendable_wording sibling, but no sibling is named, so the differentiation is inferential 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 is only implied by 'one' versus the sibling list tool; there is no explicit when-to-use or when-not-to-use guidance, and alternatives such as list_sendable_wording or suggest_sendable_change are never mentioned. Adequate minimum, but the agent must infer the 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered elsewhere. The description adds the downstream-use warning about not guessing a library id, which is genuinely useful, but says nothing about pagination or result ordering despite exposing an offset.

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 core action front-loaded and no filler. The trailing 'Do not guess a library' is slightly awkward phrasing but still earns its place as a usage constraint.

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?

Because an output schema exists, return values need not be explained, and for a simple read-only list tool the definition is close to adequate. The remaining gap is pagination behavior around offset, which an agent would need before paging through a large library list.

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 one parameter (offset) with 0% schema description coverage, so the description carries the full burden of explaining it — and it says nothing about pagination, page size, or what offset means. The mention of a 'returned id' relates to the output, not to the input parameter.

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

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

States a specific verb (List) and resource (wording libraries) scoped to 'this account', which distinguishes it from the sibling create_outbound_library. The only weakness is that it never reconciles 'wording libraries' with the tool's own name 'outbound libraries' or with siblings like list_sendable_wording.

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 a returned id. Do not guess a library.' implies this tool is a prerequisite step for other operations, which is useful context. However, it gives no explicit when-to-use versus alternatives and never says when NOT to call it, so guidance is only implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely useful semantic nuance: drafts are returned and "a draft in this list is not permission to send it," which clarifies that visibility does not imply sendability. It stops short of describing result shape or pagination limits.

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

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

Four short sentences, front-loaded with the core operation and free of filler. The warning sentence is the longest but earns its place by preventing a misuse.

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 described, and annotations cover safety. However, with 4 parameters at 0% schema coverage, the description should have explained kind and includeRetired; those gaps keep it at minimum viable rather than complete.

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

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

Schema description coverage is 0%, so the description carries the full burden. It only gestures at paging ("Page with offset") and says nothing about libraryId, the kind enum values (refund/date/feature/price/notice), or what includeRetired does, leaving three of four parameters effectively unexplained.

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 wording") plus the scoping container ("in a library"), so the agent knows it enumerates stored wording. It does not, however, differentiate itself from siblings like get_sendable_wording or list_outbound_libraries, leaving the boundary to inference.

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?

No explicit when-to-use versus when-not, and no alternative tool is named. The note that drafts are included implies a use case (reviewing/approving), but the agent is left to infer that this is the browse step feeding approve_sendable_wording.

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 readOnly, idempotent, and non-destructive, so the bar is lower; the description still adds real value by clarifying that this is a validation gate that performs no email/post, that only the stored wording is returnable, and what the two outcome states mean.

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?

Short, front-loaded, and every clause carries information (outcome states, refusal rules, non-sending disclaimer). The clipped fragments ('A draft is refused. A suggestion is refused until...') read tersely but remain efficient rather than wasteful.

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 structure needn't be explained, and the description handles the SENDABLE/REFUSED semantics well. However, for a four-parameter tool with zero schema descriptions, the meaning and constraints of kind and libraryId are left entirely unstated, leaving a real 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 0% across four required parameters, so the description must compensate. It partially does: 'exact sentence' maps to text and 'emailed, posted, or quoted' maps to the channel enum, but kind and libraryId are never explained, leaving half the parameters undocumented.

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 ('Check whether') and resource ('an exact sentence may be emailed, posted, or quoted') and explicitly negates the obvious misreading by saying 'This tool does not email or post.' That distinguishes it from the send-flavored siblings, though it never names get_sendable_wording or approve_sendable_wording directly.

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 decision rules: SENDABLE returns the stored wording with no substitution allowed, REFUSED means do not send, drafts are refused, and suggestions are refused until accepted and approved. It lacks explicit 'use X instead' routing to siblings, but the when/when-not conditions are 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 declare destructive=true, idempotent=true, readOnly=false, so the safety profile is covered; the description still adds real value by naming what is destroyed (emailable/postable/quotable status) and flagging the optimistic-concurrency requirement ('expectedRevision must match'), which is behavioral context not present in the schema.

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

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

Two short sentences, front-loaded with the effect and then the precondition. No filler, nothing repeated from 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 no explanation, and annotations carry the destructive/idempotent profile. The description covers effect and precondition but omits whether retirement is reversible and what happens when expectedRevision does not match.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate. It clarifies expectedRevision (must match, implying a concurrency check that can fail) but says nothing about wordingId beyond it being the target, and does not describe what a mismatch does.

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 (retire) plus resource (wording) and the concrete consequence (no longer emailable, postable, quotable). It does not explicitly contrast with near siblings like dismiss_sendable_change or approve_sendable_wording, so an agent must still infer which lifecycle action applies.

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 effect sentence implies the situation for use, but there is no explicit when-to-use, no when-not-to-use, and no named alternative among the ten siblings (dismiss/approve/save). The agent is left to infer that 'retire' is the terminal removal action.

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 (idempotentHint=true, destructiveHint=false, readOnlyHint=false). The description adds real value beyond them: the draft (unapproved) state, the constraint that drafts must not be emailed/posted/quoted, and that approved records are not overwritten. It omits concurrency/error behavior beyond the revision note.

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, front-loaded sentences with no filler; purpose comes first and constraints follow. Slightly telegraphic in places (e.g., the bare expectedRevision clause), but every sentence carries information.

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

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

An output schema exists, so return values needn't be described, and the draft/approval semantics are well covered. However, with five required parameters at 0% schema coverage, the description leaves most parameter meaning unexplained, which is a gap for a multi-parameter mutation.

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

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

Schema description coverage is 0%, so the description must compensate, yet it explains only one of six parameters ('A changed draft requires expectedRevision'). libraryId, name, kind, channels, and body semantics are left entirely to the schema. Partial compensation only.

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

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

States a specific verb+resource+output state: 'Save exact wording as a draft.' It also delineates scope against approval-oriented siblings ('An approved record is not replaced by this tool. Suggest a change instead'), effectively pointing to suggest_sendable_change. Siblings aren't named by exact identifier, but the distinction is clear.

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 explicit when-not guidance ('must not be emailed, posted, or quoted') and an alternative path ('Suggest a change instead') that maps to suggest_sendable_change. The routing is present, though the alternative isn't named formally and no prerequisites for the surrounding workflow 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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description adds genuinely useful context beyond them: the saved body, status, and revision are untouched, and the suggestion is not sendable. That scope clarification is valuable for an agent choosing between this and accept/dismiss siblings.

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

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

Three short sentences, front-loaded with the action, then the two most important behavioral constraints. Every sentence earns its place with no filler.

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

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

An output schema exists, so return values need no explanation, and the side-effect semantics are well covered. The gap is parameter meaning: with 0% schema coverage and three params, the definition leaves the agent guessing about wordingId vs proposedBody.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters (wordingId, proposedBody, note). With low coverage the description should compensate by explaining what wordingId identifies and what proposedBody/note mean, but it does not.

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

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

States a specific verb+resource: 'Record a proposed replacement.' The follow-up sentences distinguish it from mutation siblings by clarifying it does not alter the saved body, status, or revision. It doesn't name the accept/dismiss siblings explicitly, but the non-mutating framing differentiates it adequately.

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

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

Usage is implied rather than stated: the tool is for staging a proposed replacement that is not yet sendable, which hints at a draft-before-accept workflow. However, no explicit when-to-use, prerequisites, or reference to accept_sendable_change/dismiss_sendable_change as follow-ups is given.

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