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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond these by specifying what is read (durable state, output commitment, receipt reference) and explicitly negating side effects ('without creating a new purchase or retry identity'). No contradiction exists.

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

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

The description is a single front-loaded sentence that states the action, the target, and the key non-side-effect upfront. No filler words or redundant restatements of the title or schema are present.

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

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

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

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

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

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

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

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

The description uses a clear verb ('Read') with a specific resource ('authoritative durable state, output commitment, and receipt reference for one invocation'). The phrase 'without creating a new purchase or retry identity' explicitly contrasts this with sibling tools like ausca_prepare_invocation, making its purpose unambiguous.

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

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

The description clearly implies when to use this tool: when you need the authoritative state of an invocation and want to avoid creating a new purchase or retry. It does not explicitly name alternatives or state exclusions, but the semantic distinction from prepare/cancel tools is clear enough for an agent to route correctly.

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