Ausca

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true), the description adds meaningful behavior: the URL lives at most 60 seconds and never past inbox expiry, a clean verdict does not imply trusted content, and the lease bearer must travel on the HTTP/MCP transport rather than in arguments. These are non-obvious operational and security constraints that go well past what the structured fields 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 core action is front-loaded in the first sentence, followed by expiry, trust caveat, and auth transport in tight succession. It is dense but every sentence carries distinct information, with little waste.

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 the annotations cover the safety profile. The description is strong on behavior and security but leaves the four parameters substantially under-explained, which is the main remaining gap for a gated access-minting tool.

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

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

Schema description coverage is 0% across 4 required parameters, so the description carries the full explanatory burden. It only obliquely evokes the parameters ('active inbox', 'exact stored attachment', 'idempotent') and never states what the idempotency key does, why it is required, or what message_id versus attachment_id mean; the JSON-schema patterns are the only format guidance.

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 operation (return an idempotent download URL for a stored attachment) and its gating condition (clean safety verdict on an active inbox). It is clearly scoped apart from read/status siblings, but it does not name or differentiate itself from nearby tools like ausca_artifact_access or ausca_agent_inbox_read, so sibling differentiation is only implicit.

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

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

It states preconditions for a successful call (active inbox, exact stored attachment, clean verdict) and gives auth guidance (supply the lease bearer on the transport, never in arguments). However it never says when to choose this over the artifact-access or inbox-read alternatives, so usage 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?

Adds meaningful behavior beyond the annotations: exactly what is destroyed (retained message and attachment content, inbound visibility), that terminal leases are included, and the non-obvious auth requirement that the bearer goes on the transport. The destructive/idempotent flags themselves are already covered by annotations, and it doesn't discuss irreversibility or throttling.

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 in which every clause carries distinct information — scope of deletion, terminal-lease applicability, and auth handling. No filler or repetition 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?

Output schema exists, so return values need not be described, and the destructive/idempotent profile is covered. The main gap is the parameter identifier meaning; otherwise an agent has enough to invoke 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% for the single parameter inbox_id, so the description must carry that burden. It only says 'one inbox lease' and never explains the inbox_id identifier or its inb_ pattern, leaving parameter meaning essentially 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?

States a precise verb and resource: 'stop inbound visibility and delete retained message and attachment content for one inbox lease.' This distinguishes it clearly from siblings like ausca_extend_inbox, ausca_open_inbox, and ausca_agent_inbox_read, which do not destroy content.

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

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

It gives a real usage condition — that the call applies to 'an already-terminal lease' as well as active ones, and that the bearer must be supplied on the HTTP/MCP transport rather than in arguments. It stops short of naming when to prefer an alternative (e.g., extend vs. delete), so it is not a full 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds genuinely non-obvious behavior: a hard 50-item page cap, a bounded wait that can legitimately return an empty page plus a continuation cursor, and the credential-placement rule ('supply the lease bearer on the HTTP or MCP transport; never place it in tool arguments'). The auth instruction is exactly the kind of operational detail an agent cannot get from annotations or 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?

Three sentences, zero filler, and the core contract (page size, cursor, bounded wait) is front-loaded before the secondary note about empty pages. The auth constraint is placed last, which is appropriate since it is a caveat rather than the primary 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?

An output schema exists, so return-value detail is correctly omitted, and the description still flags the surprising empty-page-plus-cursor case. The main remaining gap is the absence of any hint about obtaining the inbox_id or initial cursor, which an agent needs before it can call this tool successfully.

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% at the property level, so the description must carry the load. It supplies meaning for 'after' (opaque, inbox-bound, continuation) and 'wait_seconds' (bounded at 30 seconds, may yield an empty page), which is real added value. However, inbox_id is only gestured at via 'For an active inbox', and the description never explains where a valid inbox_id or cursor is obtained.

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 concrete verb and resource with scope: 'return at most 50 normalized message summaries after an opaque inbox-bound cursor'. That is far more specific than the title alone and implicitly separates it from single-message siblings like ausca_agent_inbox_read. It stops short of explicitly naming an alternative, so sibling differentiation is inferred rather than stated.

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

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

The phrase 'For an active inbox' establishes a precondition, and the wait semantics imply the polling/streaming use case, but there is no explicit 'use this when / use X instead' routing against ausca_agent_inbox_read, ausca_agent_inbox_status, or the cursor-acquisition tool. Usage is implied rather than prescribed.

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/non-destructive, but the description adds real value beyond them: content-trust semantics (sender-controlled fields), that HTML is inert and never rendered, and the auth requirement that the lease bearer goes on the transport and never in arguments. It stops short of explaining what 'bounded' means or how errors are surfaced.

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, all front-loaded, with no filler; the security-critical guidance is stated declaratively rather than hedged. 'For an active inbox' is slightly cryptic as an opener but earns its place as a 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-value details are unnecessary, and the description supplies the security and auth context an agent needs to call this safely. It is slightly thin on the lease/active-inbox lifecycle and on how this differs operationally from the other inbox read siblings.

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 carries the compensation burden and adds nothing about inbox_id or message_id semantics. The parameter names are self-explanatory and the schema's $defs patterns constrain their format, so the gap is mitigated but not filled.

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 ('return one bounded normalized message') and names the exact resource scope, clearly distinguishing a single-message read from the sibling list tool ausca_agent_inbox_messages. It does not explicitly name that sibling, so differentiation requires some 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?

'For an active inbox' implies a precondition (the inbox must be opened/leased) and the bearer-token sentence gives operational usage guidance. However, it never states when to choose this over ausca_agent_inbox_messages or ausca_agent_inbox_attachment, leaving the selection implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely beyond that: status remains observable after deletion or expiry, and the lease bearer must be supplied on the transport, never as a tool argument. That credential-placement rule is non-obvious behavioral context an agent could otherwise get wrong.

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 dense sentences, front-loaded with what is returned and followed by the one operational constraint that matters. Nothing is padded, though the second sentence could have been phrased more compactly.

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, the description needn't restate return shapes, and it covers the remaining gaps well: lifetime behavior (terminal status), authentication mechanics, and what the call is scoped to. An agent has everything needed to invoke this one-parameter read 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?

There is one parameter with 0% schema description coverage, so the description carries the burden. It only says 'for one inbox' and rules out adding the bearer as an argument; it never explains the inbox_id identifier format, provenance, or how it is obtained relative to the random receive-only address it returns.

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

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

The description names a specific verb and resource ('Return ... authoritative lease status ... for one inbox') and enumerates the returned fields (receive-only address, lease status, expiry). It implicitly separates this from siblings like ausca_agent_inbox_delete or ausca_extend_inbox, but never names an alternative, so it stops short of a 5.

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

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

Usage is implied rather than stated: the mention of 'terminal status after deletion or expiry' hints this is called after destructive lifecycle events, and the transport note tells the agent where to put the bearer. No explicit when-to-use or when-not-to-use versus the other inbox tools is 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?

Goes beyond annotations by disclosing the 60-second URL expiry, that the operation is idempotent, and that downloaded bytes should be verified against the returned content digest. It also explains the transport distinction (no HTTP body; artifact_uri as path parameter, Idempotency-Key as header). This is meaningful behavioral context for a non-read-only, open-world tool.

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

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

Four sentences that are front-loaded with the core purpose, then transport, expiry, and verification detail. Dense but mostly earns its space; the HTTP-body clause is slightly pedantic but prevents a real misuse case.

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

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

An output schema exists, so return values need not be explained, and the description covers expiry, idempotency, and integrity verification. The remaining gap is parameter-level detail (idempotency key constraints), but overall it is sufficient 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?

Schema description coverage is reported as 0%, so the description must carry the burden; it does clarify that artifact_uri is an opaque, immutable reference relayed unchanged and that idempotency_key maps from an HTTP header into a tool argument. However, it never addresses the idempotency_key's format or 16-character minimum, nor when a key should be reused, leaving gaps the schema does not fill.

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

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

States a specific verb and resource: 'Return an idempotent, short-lived download URL for one verified artifact this service holds,' and scopes it to a single artifact including result artifacts from a succeeded invocation. It does not explicitly contrast with any sibling tool, but the operation is unambiguous and clearly distinct from the inbox/browser/invocation 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?

Implies the usage context by tying the artifact to a 'succeeded invocation's output_artifact,' so an agent can infer this is the post-success download step. There is no explicit when-not guidance or named alternative, leaving the selection logic 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 destructiveHint=true and idempotentHint=true, so the 'Idempotently terminate' phrasing is largely redundant. The description does add two things annotations cannot carry: closing has no billing side effect ('never creates another payment') and the bearer must be supplied out-of-band on the transport. It omits what happens to in-flight work or whether sibling leases are affected.

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

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

Two tight sentences, front-loaded with the action and followed by the two constraints that matter (billing, credential placement). Nothing extraneous.

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

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

An output schema exists, so return values need no explanation, and the safety profile is covered by annotations. The description covers idempotency, billing, and auth placement; only post-close state (what happens to the relay's pending work, error behavior if already closed) is left implicit.

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

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

One parameter with 0% description coverage; the schema's BrowserSessionID pattern documents the id format but the description adds no format or example detail. It does usefully disambiguate the lease bearer (transport) from the session_id argument, which prevents a common misuse.

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 ('terminate') plus the exact resources affected ('the CDP relay and upstream browser for one lease'), which is more precise than the bare title. It is clearly separable from siblings like ausca_browser_session_connect and ausca_browser_session_status.

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

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

Gives clear operational context for invoking it correctly: the lease bearer goes on the transport, never in tool arguments. It does not name an alternative (e.g., status-checking before closing) or state a when-not condition, so it stops short of full routing guidance.

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

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

Annotations cover safety (readOnlyHint=false, idempotentHint=true) but the description adds substantial behavior beyond them: 60-second expiry, single live-connection limit, 64 unexpired ticket cap, compaction semantics (not a lifetime reconnect quota), transport-only credential handling, and non-disclosure of upstream URL/credentials.

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 dense sentences, front-loaded with the primary return value and its lifetime. Every sentence carries operational information (expiry, limits, compaction, credential transport, non-disclosure), though the compaction clause is slightly expositional.

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 fully described, and the description still covers the key behavioral constraints. The remaining gap is parameter meaning for the two required inputs, which is left to the schema-less names.

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 required parameters (session_id, idempotency_key), yet the description explains neither. It only clarifies that the lease bearer is not a tool argument, which distinguishes it from the params but does not compensate for the undocumented session_id and idempotency_key.

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: mint/return a single-use Ausca CDP relay URL for a ready lease. This clearly differentiates it from siblings like ausca_browser_session_close and ausca_browser_session_status, which manage or inspect sessions rather than mint connection tickets.

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 'for a ready lease' precondition and the instruction to place the lease bearer on the HTTP/MCP transport (never in arguments) give clear usage context. However, it does not explicitly name alternative siblings or state when-not-to-use, so it falls short of a full 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description still adds real value beyond them by stating the status is 'authoritative' and by disclosing the auth model — the lease capability comes from the transport and is never an argument or response field, which preempts an agent trying to pass a credential.

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

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

Two sentences with zero padding; the core action is front-loaded and the second sentence carries a distinct, non-redundant 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?

An output schema exists, so return-value detail is not required, and the description names the returned fields (status, expiry). For a single-parameter read tool this is nearly complete; only usage/routing guidance is absent.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partially does: it clarifies what is NOT a parameter (the lease capability) but never explains the single session_id beyond the schema's regex pattern. With one parameter and a credential-related clarification, this is roughly baseline.

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

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

States a specific verb ('Return') and resource ('status and expiry for one browser-session lease'), which is enough to distinguish it from the mutating siblings ausca_browser_session_close and ausca_browser_session_connect. It stops short of naming those alternatives explicitly, so sibling differentiation is implied rather than stated.

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

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

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives such as ausca_lease_browser or ausca_browser_session_close. An agent must infer that this is the read path for an existing lease purely from the name.

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 idempotentHint=true, so repeating idempotency earns nothing, but the description adds genuinely new behavior: cancellation may be refused and may race against terminal completion, which tells the agent the outcome is not guaranteed. It does not say what work is discarded despite destructiveHint=true, nor what refusal looks like.

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

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

Two sentences, zero filler, with the identification of the operation and its outcome caveats 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?

An output schema exists so return shape needn't be explained, and annotations carry the safety profile (destructive, open-world). The description covers the surprising semantics of an unreliable cancellation; only authorization requirements and the fate of in-flight work are 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?

Only one parameter with 0% schema description coverage, so the description must compensate; it clarifies that exactly one invocation is targeted (no batch or list form), which is useful. It adds nothing about the identifier itself, though the schema pattern and length constraints document the format.

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 ('cancellation of one invocation') and adds a meaningful qualifier ('bounded'), which no sibling tool carries. An agent can tell this apart from ausca_get_invocation or ausca_prepare_invocation without consulting the schema.

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

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

'of one invocation' implies the scope is a single target rather than a batch, and 'may be refused' hints at preconditions, but there is no explicit when-to-use versus when-to-use-an-alternative guidance and no stated 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?

The annotations already declare idempotentHint=true and destructiveHint=true, but the description adds meaningful business behavior: replay semantics, host-supplied settlement authority, active inbox requirement, preservation of address and contents, and the 30-day prepaid expiry ceiling. It does not detail failure modes or return behavior, but it adds substantial context beyond 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 dense but front-loaded: it leads with the action, then scope, then constraints. Every clause earns its place, though the jargon-heavy phrasing could be tightened for readability.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a complex seven-parameter mutation with 0% schema description coverage, the description leaves parameter meaning and error/authorization details incomplete.

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 seven required parameters, and the description does not explain offer_id, offer_revision, digests, input, or idempotency_key. It gestures at the offer envelope and idempotency concept but leaves essentially every parameter undocumented, which is a major gap for a seven-parameter mutation tool.

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

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

The description states a specific verb pair ("Admit or replay") and a specific resource ("Agent Inbox Extension invocation"), and it scopes the resource to inbox.extend offer envelopes. It does not explicitly name sibling tools like ausca_prepare_invocation, so it is clear but not fully sibling-differentiated.

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

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

It gives a usage condition ("when settlement authority is supplied by the host boundary") and an exclusion ("Only envelopes for the inbox.extend offer are admitted on this resource"), but it never names the sibling tool to use for other offers or explains when not to call this one. Usage is implied rather than fully routed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful side-effect clarity by stating it reads authoritative durable state and does not create a new purchase or retry identity.

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; the key scope and side-effect constraint are stated immediately.

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

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

An output schema exists and annotations cover safety/idempotency, so the description mainly needs to cover behavior. It does that well, though the missing invocation_id guidance is a minor completeness 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?

The only parameter, invocation_id, has no schema description (0% coverage). The description refers to “one invocation” but does not explain the identifier's expected source, format, or value beyond what the parameter name implies, so it fails to compensate for the schema 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 (Read) and resource (invocation state), and specifies the durable state, output commitment, and receipt reference. The clause about not creating a new purchase or retry identity helps distinguish it from prepare_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 this is the read-side counterpart to purchase/retry operations by saying it does not create a new purchase or retry identity, but it does not name an alternative tool or explicitly state when to use this versus prepare_invocation or cancel_invocation.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description usefully adds that the result includes schema plus revision digests and that resolution targets either an active or an immutable pinned revision, but says nothing about behavior on an unknown/expired offer_id or any auth constraints. With annotations carrying the heavy lifting, a 3 is appropriate.

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

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

A single dense sentence with the action and target front-loaded and no filler. It is appropriately sized for a two-parameter resolver, though the trailing clause about the invocation envelope packs in extra concepts without elaboration.

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

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

An output schema exists, so return-value detail is not required, and annotations cover the safety profile. What is missing is the workflow context an agent needs to call this correctly: where an offer_id comes from (search_offers), what happens for a missing or stale digest, and any selection guidance between this and preparing an 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 must compensate, and it partially does: 'one active offer or an exact immutable revision' implicitly explains the optional revision_digest – supply it to pin an exact revision, omit it to resolve the active one. However, neither parameter is named or given format guidance, and the digest/identifier patterns live only in the schema $defs.

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 ('Resolve one active offer or an exact immutable revision'), and the two resolution modes (live active offer vs. pinned immutable revision) give real scope precision. It does not name sibling tools like ausca_search_offers or ausca_prepare_invocation, so the differentiation is implied 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: the mention that the response carries 'the schema and revision digests required to construct a valid invocation envelope' tells the agent this is a prerequisite step before preparing an invocation, but there is no explicit when-to-use statement, no prerequisite (e.g. obtaining an offer_id), and no named alternative.

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 idempotent, destructive, and open-world, so 'idempotent' in the text is redundant. The description does add real context: settlement authority comes from the host boundary and only browser.session envelopes are accepted. But it never explains what the destructiveHint actually entails (what state is destroyed), so a 3 fits given annotation coverage.

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 tightly packed sentences with the action front-loaded and no filler. Dense domain jargon costs a bit of readability but nothing is wasted.

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

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

An output schema exists, so return values need not be described. But for a 7-parameter, destructive, settlement-dependent mutation with 0% schema coverage, the description does not explain the digest fields or idempotency semantics an agent needs to invoke 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% across all 7 required parameters, so the schema documents nothing. The description mentions idempotency and settlement authority in prose but maps none of the seven parameters (offer digests, idempotency_key, input) to their meaning, leaving the gap unaddressed.

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 pair (admit or replay) and names the resource (a Browser Session invocation), and it scopes admission to browser.session offer envelopes. It does not explicitly differentiate itself from siblings like ausca_prepare_invocation or ausca_get_invocation, keeping it from a 5.

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

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

It gives a usage condition ('when settlement authority is supplied by the host boundary') and an admission constraint ('Only envelopes for the browser.session offer are admitted'). However, it never names an alternative tool or states when-not to use this one, leaving routing 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 idempotent, destructive, open-world, and non-read-only behavior. The description adds useful context beyond those hints: settlement authority is host-supplied, only inbox.receive envelopes are admitted, the result starts a renewable inbox, and inbox.extend can add an increment without changing address or contents. It does not explain the destructive implication or payment/cost mechanics in detail.

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, front-loads the action and precondition, then adds admission scope and post-call behavior. It is dense but not padded; some jargon is unexplained, but each sentence contributes useful 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?

This is a complex tool with 7 required parameters and no schema field descriptions, so the description should carry more parameter and invocation detail than it does. It covers purpose, precondition, offer restriction, and follow-on behavior, and an output schema exists, but the missing parameter semantics leave an agent without enough guidance to construct a valid call confidently.

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 all 7 parameters are required, but the description does not explain offer_id, offer_revision, the three digest parameters, the nested input payload, or idempotency_key. The references to 'offer' and 'idempotent' are only generic hints and do not map meaning to specific fields.

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

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

The description names a specific verb pair, resource, and admission scope: 'Admit or replay one idempotent paid Agent Inbox invocation' and 'Only envelopes for the inbox.receive offer are admitted.' It distinguishes this from inbox.extend by describing the latter as a follow-on action, though it does not explicitly contrast with sibling tools like ausca_prepare_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?

It states a clear precondition ('when settlement authority is supplied by the host boundary') and an exclusion ('Only envelopes for the inbox.receive offer'), and mentions the extend path once the inbox is active. It does not comprehensively say when to choose this over all sibling preparation or lookup tools, but the main usage context is clear.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds beyond them: preparation terms are immutable, failures surface as a 'typed refusal', and payment material is rejected from model-authored arguments - meaningful behavioral context an agent cannot read off the annotations. It still omits auth/permission requirements.

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

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

Two sentences, zero filler, and the outcome (terms or refusal) is front-loaded before the security constraint. Nothing is redundant with the title or schema.

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

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

For a 7-required-parameter, 0%-coverage mutation-adjacent tool, the description leaves an agent unable to determine where offer_id, offer_revision and the schema digests come from or when this call must precede another. The output schema existing means return values need no explanation, but the input-side gap is serious.

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

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

All seven required parameters have 0% schema description coverage; the schema only supplies types, patterns and $refs. The description says only that the payload is 'one exact invocation envelope', which hints that the offer/digest fields bind an exact revision but explains none of offer_id, offer_revision, the three digests, input or idempotency_key.

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 ('Validate one exact invocation envelope') plus the outcome ('return immutable preparation terms or a typed refusal'), which is far more than a restated title. It does not differentiate itself from siblings such as ausca_get_invocation or ausca_cancel_invocation, so an agent must infer where this fits in the invocation lifecycle.

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 statement of when to call this versus ausca_get_invocation, ausca_cancel_invocation, or elsewhere in the flow, and no prerequisites. The only boundary given is a prohibition ('never accepts payment material from model-authored tool arguments'), which is a constraint rather than usage routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered; the description's 'without creating product or payment state' restates that in domain terms. It adds useful context about the catalog being immutable and returns being revision digests, but says nothing about pagination behavior for the cursor.

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

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

Two tight sentences with no waste, and the operation and scope are front-loaded. Nothing is padded, though the brevity comes partly at the cost of the missing parameter and pagination guidance.

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

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

An output schema exists, so return values need not be explained, and the safety profile is annotation-covered. However, for a paginated search tool the description omits how the cursor is meant to be used across calls, leaving a real gap for an agent driving multi-page retrieval.

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% top-level schema description coverage and three parameters, the description carries the burden but only implies the q parameter via 'free-text query.' The limit and cursor parameters are never mentioned, and while the cursor $def internally warns not to construct it, that is schema content, not description content.

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 (Search) and resource (immutable Ausca offer catalog) with the query mechanism (free-text). This distinguishes it implicitly from the sibling ausca_get_offer, which retrieves a single offer, but the description never names that sibling to make the contrast 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 implied by 'by free-text query' and 'Returns stable offer identities,' which hints at a search-then-fetch flow, but there is no explicit when-to-use guidance and no mention of the alternative ausca_get_offer for direct retrieval. The agent must infer the search-vs-fetch boundary itself.

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