Ausca

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

The description adds meaningful behavior beyond the annotations: the URL is short-lived, exactly one URL is returned, and access is gated on a clean safety verdict. It does not describe failure behavior when the verdict is not clean, but the disclosed conditional behavior 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?

A single sentence carries the core action, the object, and the governing safety condition with no filler. The most important 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?

The description covers the tool's core contract and safety gate, and an output schema exists so return-value documentation is not required. However, with zero parameter descriptions and no mention of how the required identifiers fit together or what happens when the safety check fails, an agent still has meaningful gaps to resolve before confident 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?

Schema description coverage is 0%, and the description does not explain any of the four required parameters: inbox_id, message_id, attachment_id, and idempotency_key. The reference to 'attachment' hints at attachment_id, but the idempotency_key semantics and the relationship among the three identifiers are left entirely to inference.

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 ('Return'), a concrete resource ('one short-lived Ausca download URL'), and a precise condition ('only when the exact stored attachment has a clean safety verdict'). This clearly distinguishes it from the sibling read/messages/delete tools.

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 exact stored attachment has a clean safety verdict' gives clear situational guidance for when this tool applies. It does not explicitly name alternatives or exclusion cases, but the uniqueness of the attachment-download purpose makes the usage context evident.

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=false, idempotentHint=true, and destructiveHint=true, so the bar is lower. The description adds genuine context beyond those flags: it specifies exactly what gets destroyed ('retained message and attachment content') and the observable side effect ('stop inbound visibility'), and 'idempotently' aligns with the idempotency hint. No contradiction with annotations. Minor gap: permanence/recoverability of the deletion is not stated.

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

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

One 16-word sentence, front-loaded with the action ('Idempotently stop... delete...'), with no filler. Every element earns its place: idempotency, the visibility side effect, the destroyed content, and the single-lease scope. The description is appropriately sized for a one-parameter destructive operation.

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 are documented elsewhere; annotations cover the safety profile (destructive, not read-only, idempotent); the description adds scope and the exact effects of the call. For a 1-parameter delete tool this is nearly complete. The only notable omission is whether the deletion is permanent/recoverable and whether the lease ID becomes invalid afterward.

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 should compensate, but it only ties the parameter to the operation via 'one inbox lease' without explaining how to obtain a valid inbox_id. That said, the single parameter is self-named and tightly constrained by the schema's pattern (^inb_[A-Za-z0-9_-]{22,64}$), so the practical risk of misusing it is low.

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-resource pair — 'delete... one inbox lease' — and goes beyond a generic delete by stating the concrete effects: 'stop inbound visibility and delete retained message and attachment content.' This clearly differentiates it from the sibling inbox tools (attachment, messages, read, status), which are non-destructive operations on the same lease.

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 context is implied by the purpose ('when you need to retire a lease and purge its content'), and the idempotency statement signals it is safe to retry. However, there is no explicit when-to-use versus when-not-to-use guidance, no mention of prerequisites, and no pointer to non-destructive alternatives like ausca_agent_inbox_read or ausca_agent_inbox_status.

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, so the safety profile is covered. The description adds useful behavioral detail: a 50-message cap, normalized summaries, opaque cursor continuation, and optional long-polling up to 30 seconds. This meaningfully supplements 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?

The description is a single, dense sentence that front-loads the core behavior, caps, cursor semantics, and wait option. Every phrase carries meaning and there is 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?

Given the output schema and annotations, the description covers the essential invocation semantics: max result count, normalized summaries, cursor-based pagination, and wait timeout. It does not explicitly state that the first page should omit the cursor, but that is inferable from the schema's optional 'after' field.

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, but it does not name or explain the parameters directly. It does reference the cursor ('after an opaque cursor') and waiting duration, but it leaves inbox_id and the precise relationship between cursor and inbox to be inferred from 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?

The description uses a specific verb and resource: 'Return at most 50 normalized message summaries' for the agent inbox. It also clearly conveys the two modes—listing after a cursor and waiting up to 30 seconds for a newer message—which distinguishes it from siblings like read, delete, and attachment.

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

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

The description implies usage as a paginated or long-polling inbox reader through 'after an opaque cursor' and 'waiting up to 30 seconds', but it never explicitly states when to prefer this over alternatives such as ausca_agent_inbox_read or ausca_agent_inbox_status. Context is present, but exclusions and alternative routing are not.

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 behavior, so the description's main contribution is the security-related disclosure that HTML is inert, untrusted, and never rendered by Ausca. 'Bounded normalized' also hints at platform processing behavior. This adds useful context beyond 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 with no filler. The primary action is front-loaded, and the second sentence earns its place by disclosing a meaningful safety 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?

For a low-complexity read tool with a rich output schema and clear annotations, the description covers the key behavioral and safety traits. The main gap is the absence of usage routing, but the core call context is sufficiently inferable.

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 adds no explanation of how to obtain or format inbox_id and message_id. The property names and regex patterns provide some self-evident meaning, but the description does not compensate for the missing schema descriptions.

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

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

The description states a specific verb and resource: 'Return one bounded normalized message.' It clearly indicates a single-message read and implicitly separates it from list-style siblings like ausca_agent_inbox_messages, but it does not explicitly name or contrast 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?

No when-to-use or when-not-to-use guidance is provided. The description and sibling names imply the tool is for reading a specific message, but there is no explicit context about when to choose it over attachment, delete, status, or messages 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds useful context about what is returned, including 'authoritative lease status,' but does not go beyond what annotations and schema already imply.

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

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

One concise sentence with no filler, front-loading the action and listing the three specific return values. 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?

The tool is simple, annotations cover the safety profile, and an output schema exists for return values. However, the description omits any guidance on when to use status versus sibling inbox tools and does not clarify how to interpret or acquire inbox_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?

The schema has 0% description coverage for the single required inbox_id parameter, and the description does not explain what inbox_id represents or how to obtain it. The phrase 'for one inbox' only weakly maps to the parameter, so the description adds little meaning beyond the schema's pattern.

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 ('Return'), a concrete resource ('agent-inbox lease status'), and the exact data points returned: random receive-only address, authoritative lease status, and expiry. This clearly distinguishes it from sibling tools like read, messages, and delete.

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 context is implicit through the name and title: this is the tool to check inbox lease status rather than to read messages or delete the inbox. However, the description does not explicitly state when to prefer this tool over alternatives or mention any prerequisites.

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 and idempotent behavior, but the description adds valuable context beyond those flags: exactly what is terminated, the lease scoping, and the billing-relevant guarantee that closing never creates another payment. This is concrete operational disclosure an agent can act on.

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 first puts the action and scope first, and the second adds the payment-relevant guarantee. Every clause contributes something meaningful.

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 mutating tool, the definition is nearly complete: the output schema covers return shape, annotations cover idempotency and destructiveness, and the description explains the target and billing side-effect. The only gap is explicit guidance on where session_id comes from, although 'one lease' plus the brs_ pattern provides enough grounding.

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?

Input schema coverage is 0% and the schema provides only the pattern and required flag for session_id. The description never explains what session_id represents, how it is obtained, or how it maps to a browser-session lease, so it does not compensate for the missing schema documentation.

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

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

The description uses a specific verb ('terminate') and resource ('the CDP relay and upstream browser') scoped to 'one lease', making the tool's action unambiguous. It distinguishes itself from sibling browser tools like connect and status by focusing on termination and idempotent closing.

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 intended use is implied by the wording 'terminate ... for one lease' and the reassurance about payments, but the description never explicitly states when to use this tool instead of an alternative. There are no exclusions or sibling comparisons beyond what the name already communicates.

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 provide idempotency and safety hints, and the description adds valuable behavioral context: the URL is short-lived, requires an active lease, and the upstream provider URL/credential are never disclosed. This goes beyond the structured fields with meaningful security and lifecycle information.

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 deliver all essential information with no filler. The core function is front-loaded and the security note is a valuable addition without bloating the description.

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 output schema, annotations, and the simplicity of the two parameters, the description covers the essential invocation context: active lease, short-lived relay URL, and credential handling. It could mention how to confirm an active lease exists, but that is 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% and the description does not explain either 'session_id' or 'idempotency_key'. Although the names and regex patterns give some clues, the description provides no additional meaning or guidance on how the parameters relate to the lease or the returned URL.

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 ('Return'), the exact resource ('Ausca CDP relay URL'), and a key condition ('for an active lease'). It clearly distinguishes this tool from siblings like status or close by indicating this one issues a connection artifact rather than inspecting or ending a 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 clearly implies usage on an existing, active lease, which is useful context. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to understand when to invoke 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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context by clarifying that the status is authoritative, that the lease capability is transport-supplied, and that the lease is neither a tool argument nor a response 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 sentences with no filler. The primary purpose is front-loaded, and the second sentence earns its place by preventing a common misunderstanding about the transport-level lease.

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 exists and annotations cover the safety profile, so return values and side effects are mostly handled. However, the description omits usage context and does not explain how to source the session_id, leaving an agent to infer these details.

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 only parameter, session_id, is not described in the schema or the description. With 0% schema description coverage, the description needed to explain how to obtain or interpret session_id, but it only clarifies what is not an argument rather than what the parameter means.

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 ('Return') and resource ('one browser-session lease') and states the exact outcome ('status and expiry'). This clearly distinguishes it from sibling tools like ausca_browser_session_connect and ausca_browser_session_close.

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 no explicit guidance on when to use this tool versus alternatives such as connect or close. An agent must infer usage from the tool name and read-only annotations rather than from stated conditions or exclusions.

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

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

Annotations already indicate idempotent, destructive, and open-world behavior. The description adds 'bounded', 'may be refused', and 'may lose a race with terminal completion', providing extra context on failure modes and semantics beyond the 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 concise sentences with zero waste. The action is front-loaded, and each clause adds relevant behavioral detail.

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 description covers idempotency, refusal, and race conditions, which are key behaviors for a cancellation tool. An output schema exists (though not shown here), so not explaining the return format is acceptable. Lacks explicit guidance on interpreting results, but that likely resides in 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?

Single parameter invocation_id is self-evident from the tool name and description. Although schema coverage is 0%, the description implies the target invocation, which compensates for the lack of schema descriptions.

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

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

The description states a specific verb ('cancel') and resource ('one invocation'), and the scope is clear. It is immediately distinguishable from sibling tools that get, prepare, or search invocations.

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 or alternatives are given, but the note about idempotency and possible refusal implicitly informs retry behavior. It does not guide on when to use this versus checking status first.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond these by specifying what is read (durable state, output commitment, receipt reference) and explicitly negating side effects ('without creating a new purchase or retry identity'). No contradiction exists.

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 a single front-loaded sentence that states the action, the target, and the key non-side-effect upfront. No filler words or redundant restatements of the title or schema are present.

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 operation with rich annotations and an output schema, the description is nearly complete. It covers what is read and explicitly notes that no new identity is created. Minor gaps remain, such as how to obtain a valid invocation_id, but these are not critical given the schema pattern and tool name.

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 required parameter, invocation_id, with no description coverage (0%). The description only refers to 'one invocation,' which weakly implies that invocation_id identifies the target, but it does not explain how the ID is formatted, where it comes from, or any additional constraints beyond the schema pattern. Given the low schema coverage, the description should compensate more than it 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?

The description uses a clear verb ('Read') with a specific resource ('authoritative durable state, output commitment, and receipt reference for one invocation'). The phrase 'without creating a new purchase or retry identity' explicitly contrasts this with sibling tools like ausca_prepare_invocation, making its 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 clearly implies when to use this tool: when you need the authoritative state of an invocation and want to avoid creating a new purchase or retry. It does not explicitly name alternatives or state exclusions, but the semantic distinction from prepare/cancel tools is clear enough for an agent to route correctly.

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 meaningful behavioral context beyond annotations by explaining active versus exact immutable revision semantics and noting that the result includes the schema and revision digests needed to build an invocation envelope.

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

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

A single, front-loaded sentence with no wasted words. It immediately states the core action and then adds the most important related detail about digests and 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?

Given the small parameter set, clear annotations, and presence of an output schema, the description covers the essential resolution behavior and why the result matters. It is slightly incomplete only in not routing the agent to sibling tools for discovery or listing.

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 0% schema description coverage, the description needs to compensate, and it partially does: 'active offer' maps to offer_id and 'exact immutable revision' clarifies revision_digest. However, it does not explicitly explain which parameter is required, that revision_digest is optional, or how the two parameters interact when both are present.

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

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

The description uses a specific verb ('Resolve') and a clear resource ('one active offer or an exact immutable revision'), and it distinguishes the tool from siblings like ausca_search_offers by emphasizing exact single-offer resolution and the revision/schema digests needed for an invocation envelope.

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 does not explicitly name alternatives or state when not to use this tool. It implies use when you need a specific offer or immutable revision with its digests, but it leaves the agent to infer that discovery/search belongs to ausca_search_offers.

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 annotations, the description adds meaningful behavior: results are 'immutable preparation terms', failures are 'typed refusal's, and payment material is categorically rejected from model-authored arguments. These traits are not already disclosed by readOnlyHint, openWorldHint, idempotentHint, or destructiveHint, so the description adds real value without contradicting 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 sentences with no filler. The core purpose and primary safety constraint are front-loaded, and every phrase earns its place. The description is compact while avoiding tautology.

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?

Although the output schema exists and annotations cover safety, the tool has a complex 9-parameter input schema with zero parameter documentation both in the schema and the description. The description also omits when-to-use guidance relative to siblings. For a tool this intricate, the missing parameter semantics make the definition incomplete for reliable 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?

Schema description coverage is 0%, so the description carries full responsibility for explaining the 9 parameters, but it does not. The only parameter-related clue is the payment-material restriction, which implicitly touches the 'input' field. The remaining parameters — offer_id, offer_revision, digests, canonicalizer_version, idempotency_key, parent_binding — receive no semantic explanation, leaving a major 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?

Description states a specific verb ('Validate'), a specific resource ('one exact invocation envelope'), and the outcome ('return immutable preparation terms or a typed refusal'). This clearly distinguishes it from sibling tools like cancel, get, or search, and the payment-material constraint adds further operational specificity.

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 the tool is for validation/preparation of an invocation and warns that payment material must never come from model-authored arguments. However, it never explicitly states when to use this tool versus siblings such as ausca_get_offer or ausca_get_invocation, nor does it name alternatives or exclusion conditions. Usage context is present but 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior, but the description adds valuable behavioral context: the catalog is immutable, no product or payment state is created, and results are stable identities plus revision digests. This 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 sentences with no filler; the primary action, target resource, and key behavioral guarantee are front-loaded. Every clause 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 rich annotations, the output schema, and the straightforward search operation, the description covers the essential behavioral context. It does not fully document all parameter semantics, but the presence of an output schema and the concise side-effect-free guarantee make the tool adequately callable.

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 does not explain q, limit, or cursor. The phrase 'free-text query' implies the meaning of q, but limit and cursor receive no semantic guidance beyond the schema's raw constraints; the description does not 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 uses a specific verb ('Search') and resource ('current immutable Ausca offer catalog') and specifies the return value ('stable offer identities and revision digests'), which clearly differentiates it from siblings like ausca_get_offer. It is immediately obvious what this tool does and how it is 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 provides clear context for using this as a read-only catalog search, and phrases like 'without creating product or payment state' imply when it is appropriate. However, it does not explicitly name alternatives or state when to prefer ausca_get_offer or ausca_prepare_invocation, so routing guidance is only implicit.

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