Ausca

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

The description discloses important behavioral traits beyond the annotations: idempotency (matching annotation), URL expiry (≤60 seconds, never after inbox expiry), the trust caveat (clean verdict does not make content trusted), and the transport instruction (lease bearer on HTTP/MCP, never in arguments). These add significant value beyond the idempotentHint and openWorldHint annotations.

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

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

The description is three sentences, each densely informative: the main action and condition, the expiry/trust caveats, and the transport instruction. It is front-loaded with the core behavior and contains no fluff.

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

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

Given that an output schema exists (return format is already covered), the description covers all operational essentials: the active-inbox precondition, the safety-verdict condition, expiry behavior, the trust caveat, and the lease-bearer transport requirement. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It does not mention inbox_id, message_id, attachment_id, or idempotency_key at all. The schema itself provides names and patterns, but the description adds no semantic meaning, leaving the agent to infer from names alone.

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) and resource (download URL for an attachment) with a precise condition (only when the exact stored attachment has a clean safety verdict). It clearly distinguishes this from sibling tools like ausca_artifact_access by scoping it to inbox attachments and the safety gating.

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 provides clear context for when to use the tool ('For an active inbox') and the condition of a clean safety verdict, but it does not explicitly name alternatives or state when not to use it. The context is sufficient for an agent to decide, though exclusions are absent.

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

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

Beyond the annotations (destructiveHint, idempotentHint), the description discloses what gets destroyed (retained message and attachment content), how terminal leases are handled, and that the lease bearer must be supplied on the HTTP or MCP transport, never in tool arguments. This adds meaningful operational context beyond the structured fields.

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

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

The description is two sentences with no filler. The core action and edge-case behavior are front-loaded, followed by the transport/auth instruction. Every sentence earns its place.

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

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

For a single-parameter destructive operation with annotations and an output schema, the description covers the operation's effect, the terminal-lease edge case, and authentication/transport requirements. Nothing essential for calling the tool correctly is missing.

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

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

There is only one parameter, inbox_id, and the schema provides only a pattern with no description. The description does not explicitly explain inbox_id's meaning or format, but it does clarify that the lease bearer is not a tool argument, which is important parameter-adjacent guidance. With 0% schema description coverage, more direct parameter explanation would be stronger.

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 ('delete') and resource ('agent-inbox lease'), and further clarifies the effect by mentioning stopping inbound visibility and deleting retained message/attachment content. It also covers the already-terminal lease edge case, making it easy to distinguish from sibling read/status 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 description gives clear context for when the tool is appropriate: when an inbox lease should be terminated and its retained content removed, including terminal leases. It does not explicitly name sibling alternatives or exclusions, but the destructive purpose and 'including an already-terminal lease' phrasing provide sufficient usage direction.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds meaningful behavioral details: the bounded wait may return an empty page with a continuation cursor, the result limit is at most 50 summaries, and the lease bearer must be supplied on the transport rather than in tool arguments. These details inform the agent about edge cases and security handling that annotations alone do not convey.

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

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

The description is three sentences of dense, high-value prose with no fluff. Each sentence adds distinct information: (1) return behavior and limits, (2) empty-page edge case, (3) authentication/transport handling. The structure is well-organized and front-loaded with the core purpose.

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

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

Given the tool's complexity (3 parameters, output schema, sibling tools for read/delete/attachment/status), the description covers the essential aspects: pagination semantics, wait behavior, result limits, empty results, and authentication. It does not explicitly articulate the relationship to siblings beyond implication, but the output schema covers return format, making the description reasonably complete for this listing tool.

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

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

With 0% schema description coverage, the description compensates by semantically covering all three parameters: inbox_id ('active inbox'), after ('opaque inbox-bound cursor'), and wait_seconds ('optionally waiting up to 30 seconds for a newer message'). While not deeply detailed, each parameter's purpose is at least mentioned, which is sufficient given the description's brevity.

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

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

The description clearly states the action ('return at most 50 normalized message summaries'), the resource ('inbound messages' for an 'active inbox'), and the distinguishing features (cursor-based pagination, optional 30-second wait). The title 'Wait for or list inbound messages' further clarifies the purpose, which differentiates it from sibling tools like ausca_agent_inbox_read (reading a single message) and ausca_agent_inbox_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?

The description implies usage scenarios — listing messages with an opaque cursor and optionally waiting up to 30 seconds for new messages (long-polling) — but does not explicitly state when to prefer this tool over alternatives. It does not name sibling tools or provide explicit 'use this when...' guidance, leaving the agent to infer the distinction from the title and context.

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

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

The description goes beyond annotations by explicitly flagging sender-controlled content as untrusted, stating that HTML is inert and never rendered, and instructing to supply the lease bearer on the transport rather than in arguments. These are important behavioral disclosures not present in the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false). It adds meaningful safety and transport context.

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

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

The description is concise, consisting of two sentences that front-load the purpose and then add essential behavioral and auth notes. There is no fluff, and each sentence earns its place, though the parameter semantics gap could be addressed without much added length.

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 key operational aspects: it returns a single normalized message, flags untrusted content and inert HTML, and specifies the auth transport. It does not mention error conditions or pagination, but the presence of an output schema likely handles return structure. For a simple read operation, this is largely 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%, and the description does not explain what inbox_id or message_id represent beyond their existence. It does not clarify that inbox_id identifies the inbox and message_id identifies the specific message, nor does it describe their formats beyond the schema patterns. The description fails to compensate for the lack of parameter 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 states a clear verb ('return') and resource ('one bounded normalized message') from an 'active inbox', making the primary purpose obvious. However, it does not explicitly differentiate from sibling tools like ausca_agent_inbox_messages, which likely lists messages, so the agent must infer the distinction from the singular 'one' and the need for a message_id.

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 'For an active inbox' gives a precondition, and the requirement to supply a lease bearer is a clear usage note. But there is no explicit guidance on when to use this tool instead of alternatives (e.g., listing messages or deleting one), nor any mention of scenarios where this should not be used. The usage context is 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?

The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavior beyond that by explaining the lease bearer transport requirement and the inclusion of terminal status after deletion or expiry, which is not covered by 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?

The description is two sentences long, front-loads the purpose, and contains no extraneous information. It efficiently combines the return values and the transport instruction.

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

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

The tool has a single required parameter and an output schema, but the description does not explain the structure of the output beyond listing the fields returned. It also does not clarify the parameter meaning or the context in which the terminal status would be relevant, so some context 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?

The schema has zero description coverage for the inbox_id parameter, and the tool description only refers to 'one inbox' without explaining how to identify it or what the ID represents. This leaves the agent to infer the parameter's meaning from its name and pattern, so the description 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 clearly states the tool 'return[s] the random receive-only address, authoritative lease status, and current expiry for one inbox', which is a specific verb and resource. It distinguishes from siblings by focusing on lease status, which is unique among the listed 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 description provides specific usage guidance about supplying the lease bearer on the HTTP or MCP transport and never placing it in tool arguments. However, it does not explicitly state when to use this tool versus alternatives like the delete or messages tools, so some inference is required.

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 discloses the 60-second URL expiry, the exact HTTP request shape, path/header parameter mapping, and the requirement to verify downloaded bytes against the returned content digest. It also states that the immutable artifact reference is the only authority, adding meaningful behavioral context.

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

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

Four sentences, all load-bearing: purpose, HTTP/MCP argument mapping, expiry, and integrity verification. The most important information is front-loaded and there is no filler.

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

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

For a two-parameter tool with an output schema, the description covers the applicable artifact scope, URL lifetime, invocation mechanics, and verification expectations. Nothing essential is left to inference for an agent to call this tool correctly.

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

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

With schema description coverage at 0%, the description must compensate. It usefully maps artifact_ref to a URL path parameter and says to relay it unchanged, and maps idempotency_key to the Idempotency-Key header. However, it does not explain the idempotency key's generation or deduplication semantics beyond that mapping.

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: it returns an idempotent, short-lived download URL for one verified artifact, explicitly including result artifacts named by a succeeded invocation's output_artifact. This distinguishes it clearly from the sibling invocation, offer, and inbox tools, none of which mint download access.

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 clear selection context by scoping the tool to verified artifacts the service holds, including invocation result artifacts. It does not explicitly name alternatives or say when not to use it, but no sibling tool serves the same purpose.

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

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

The description adds behavioral context beyond the annotations. It explicitly states idempotency (matching idempotentHint), explains that closing never creates a payment (a unique side-effect not in annotations), and details what gets terminated (CDP relay and upstream browser). It also provides transport-level guidance on the lease bearer, which is beyond the structured annotations. No contradictions.

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

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

The description is three sentences, compact, and front-loaded with the core action. Each sentence adds value: action and scope, payment side-effect, and transport security. No filler or redundant wording.

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

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

For a simple single-parameter destructive tool with rich annotations (idempotent, destructive), the description covers the essential behavior, side effects, and security considerations. It doesn't mention the return value or error handling, but an output schema exists. It could also explicitly state when to use it, but the core usage is clear enough. Overall, it's nearly 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?

The schema has one required parameter (session_id) with a regex pattern but no textual description, giving 0% schema description coverage. The description mentions 'for one lease' and refers to the lease bearer, implying session_id is the lease identifier, but it does not explicitly state what session_id represents. It also cautions not to place the lease bearer in tool arguments, which could confuse whether session_id is the bearer. More explicit parameter explanation would help.

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 ('terminate'), a specific resource ('CDP relay and upstream browser'), and a specific scope ('for one lease'). It clearly distinguishes from sibling tools like connect and status by describing the closing action. The phrase 'Idempotently terminate' also conveys the operation's nature.

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 a critical usage guideline: 'Supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments.' It also notes that closing never creates another payment, implying it's a cleanup operation. However, it does not explicitly state when to use this tool over its siblings (e.g., when a session is done) or mention any prerequisites like an active lease.

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

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

Beyond the annotations, it discloses the 60-second expiry, single-live-connection cap, 64-ticket coexistence limit, compaction behavior, and the fact that upstream credentials are never disclosed. This richly characterizes the tool's side effects and constraints without contradicting any annotation.

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

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

The purpose is front-loaded in the first sentence, followed by tight constraints and one usage rule; every sentence carries distinct information and there is no filler.

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

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

For a two-parameter tool with an output schema and rich annotations, the description covers the important quotas, expiry, and transport-security behavior. It may leave error states or the precise meaning of a 'ready lease' implicit, but it is fundamentally complete for correct invocation.

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

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

The schema has zero prose descriptions for session_id or idempotency_key, and the description never explains their meaning or how they interact with the minting/lease flow. The bearer-transport instruction is useful but does not compensate for the undocumented 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 first sentence names an exact action and artifact: 'Return one single-use Ausca CDP relay URL for a ready lease.' This clearly distinguishes it from sibling status/close tools, which concern checking or terminating sessions rather than minting a connection.

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 frames the tool's role—'for a ready lease'—and gives concrete invocation guidance: put the lease bearer on the transport, never in tool arguments. It does not explicitly name alternative tools or exclusion conditions, but the context is unambiguous for an agent selecting a connect operation.

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?

Beyond the annotations (idempotent, destructive, openWorld), the description adds meaningful behavior: cancellation 'may be refused' and 'may lose a race with terminal completion.' This goes beyond what the annotations provide and usefully sets expectations for a mutation 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?

Two sentences: the first states the core action, the second efficiently lists caveats. There is no filler or redundant restatement of the title.

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

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

With an output schema present and annotations covering idempotency and destructiveness, the description covers the essential behavioral nuances (refusal, race condition). A minor gap is explaining what 'bounded' means in practice, but this does not block correct invocation.

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

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

The only parameter, invocation_id, has 0% schema description coverage. The description implicitly identifies it as the target invocation via 'one invocation,' but does not define the parameter explicitly, its provenance, or format beyond the schema pattern. The semantics are largely inferable from the tool name and context.

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

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

The description states a clear verb ('Request bounded cancellation') and a specific resource ('one invocation'). It distinguishes this from sibling tools like ausca_get_invocation and ausca_prepare_invocation by focusing on cancellation, so an agent can tell intent without deeper inspection.

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 guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no reference to siblings or broader workflow context, so an agent must infer usage from the tool name 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying what is read (durable state, output commitment, receipt reference) and by explicitly stating the operation has no side effects on purchase or retry identity. 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?

One sentence, front-loaded with the core action and resource, and ends with a meaningful exclusion clause. Every word earns its place; no fluff or repetition of 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?

The tool has a single parameter, a rich output schema (not shown but present), and annotations covering safety and idempotency. The description explains the purpose and side-effect profile sufficiently. It doesn't describe the return value, but the output schema exists, so that burden is shifted. It could mention error cases or when the invocation state might be unavailable, but for a simple read tool this is adequate.

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 for parameter semantics. However, the single parameter invocation_id is self-explanatory given the tool name and description, and the schema defines its format (pattern, maxLength). The description doesn't add detail about the parameter, but the parameter is simple and unambiguous. Baseline 3 is appropriate because the description doesn't actively compensate but the parameter is trivially clear from context.

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

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

The description states a specific verb ('Read'), a specific resource ('authoritative durable state, output commitment, and receipt reference'), and a clear scope ('for one invocation'). It also distinguishes itself from sibling tools by explicitly noting it does not create a new purchase or retry identity, which separates it from ausca_prepare_invocation and ausca_cancel_invocation.

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 when to use this tool: when you need the authoritative state of an invocation without side effects. It does not explicitly name alternatives or exclusions, but the negative clause ('without creating a new purchase or retry identity') provides clear context that this is a read-only lookup, distinct from preparation or cancellation flows. It lacks an explicit 'use X instead when...' statement, so it doesn't reach a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by noting that revisions are immutable and that the result includes envelope-construction digests, but it does not go beyond that into error behavior, auth, or response details.

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

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

A single, front-loaded sentence that names the resource, the operational mode, and the key output without any filler. Every phrase contributes to understanding what the tool does and why it exists.

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, idempotent tool with an output schema and only two parameters, the description is largely sufficient. It covers the core purpose and the central concepts of active offers and immutable revisions. The main gap is not explicitly stating which parameter is required versus optional, though the title and schema partially imply it.

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

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

Schema description coverage is 0%, so the description must carry semantic weight. It effectively maps 'one active offer' to offer_id and 'exact immutable revision' to revision_digest, and explains the purpose of the returned digests. However, it still leaves room for ambiguity about optionality and the exact relationship between the two 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 clearly identifies the verb 'Resolve' and the specific resource: 'one active offer or an exact immutable revision'. It further specifies the key output ('schema and revision digests') but does not explicitly differentiate itself from siblings like ausca_get_invocation or ausca_search_offers, so it falls short of a 5.

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

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

The description gives clear context for when to use the tool: when the caller needs the schema and revision digests to construct a valid invocation envelope. It does not explicitly state when not to use it or name alternatives, so it misses the full exclusions that would earn a 5.

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

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

With annotations already covering idempotency and non-destructiveness, the description adds meaningful operational context: results are immutable terms or a typed refusal, and model-authored arguments must not carry payment material. Nothing in the description contradicts the annotations; 'validate' does not explicitly claim read-only behavior.

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 long, with the core action and result in the first sentence and a terse security constraint in the second. Every sentence adds value and contains 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?

The structured schema and output schema cover many operational details, and annotations handle idempotency/destructiveness, so the description is adequate for a moderately complex 8-parameter tool. It still leaves gaps around how the envelope relates to the offer and how parent_binding/digests are used, and around when to use this step relative to the sibling tools.

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 offer_id, revision/digest fields, idempotency_key, or parent_binding. It only provides one semantic cue for the 'input' envelope by warning that it never accepts payment material, which is insufficient for correctly constructing the required 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 names a specific verb ('Validate') and a specific object ('one exact invocation envelope'), and specifies the return as 'immutable preparation terms or a typed refusal.' This is distinct from sibling get/cancel/search tools, though it does not explicitly call out an alternative.

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 implies this is the validation/preparation step before an invocation and sets a hard input boundary with the payment-material sentence. However, it does not explicitly state when to prefer this tool over siblings such as get_offer or cancel_invocation, leaving placement to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by stating it does not create product or payment state, aligning with readOnly, and noting it returns stable identities and revision digests, which hints at the immutable nature. It does not contradict annotations and provides extra context beyond the safety profile.

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 core purpose ('Search the current immutable Ausca offer catalog by free-text query') and then adds return details and a side-effect note. There is no wasted wording, and the most critical information appears first.

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 is adequate for a read-only search tool with an output schema, covering purpose and side effects. However, it omits essential usage details for the parameters, particularly the cursor for pagination and the limit semantics. An agent could not correctly page through results without consulting the schema, and even then the cursor's opaque nature is only partially described. Given the tool's moderate complexity, this is a notable incompleteness.

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 for parameter documentation. It only mentions 'free-text query' which relates to q, but gives no guidance on limit (default 20, max 100) or cursor (opaque continuation token). The schema itself has a description for cursor, but the tool description fails to explain how to use these parameters or that pagination is involved. This is a significant 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 clearly states the tool searches the immutable Ausca offer catalog via free-text query, and specifies it returns stable offer identities and revision digests. This distinguishes it from sibling tools like ausca_get_offer (which retrieves a specific offer) and ausca_prepare_invocation (which creates state). The verb, resource, and scope are explicit.

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

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

The description provides context that this is a search operation on the current catalog, implying it should be used when an agent needs to find offers rather than retrieve a known one. However, it does not explicitly name alternatives or state when not to use this tool, such as 'for a specific offer, use ausca_get_offer instead.' The guidance is clear but not fully explicit.

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