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

With no annotations, the description carries the full burden and does disclose meaningful behavior: guard and receipt are free inside the bundle (credit implications), the lifecycle_token is one-time, and it must not be reused after close (a mutation side effect). It does not state whether close itself costs credits, whether close invalidates lifecycle_id, or what errors occur on token misuse — notable gaps for a stateful mutation 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?

Front-loaded with the core action and op enumeration, then cost, then return, then constraints — a sensible order. The sentences are dense and multi-clause, but nearly every clause carries information; there is little 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?

No output schema and no annotations, so the description must cover everything, and it does state what is returned ('guard verdict, signed receipt, or the combined lifecycle summary'). Still missing are which parameters apply to which op (e.g. family for guard, receipt for receipt), the purpose of `transaction`, and lifecycle state behavior after close — substantial gaps for a 7-parameter, nested-object 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 coverage is only 43%, and the description compensates partially: it defines the three op values and the one-time nature of lifecycle_token, and implies lifecycle_id identifies the bundle. However, `family` (enum of six families, presumably required for guard), `params`, `receipt`, and especially `transaction` (which has no schema description at all) are never explained in the description, so several parameters remain opaque.

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 ('Run one step inside a purchased Position Lifecycle bundle') and enumerates the three operations with one-line meanings: guard as a family-specific safety assessment, receipt as a signed execution receipt, close as a combined summary. It is clearly distinct from position_lifecycle_begin, but it does not distinguish guard from the sibling check_trade_safety, leaving one obvious overlap unresolved.

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?

Explicit preconditions and exclusions are given: 'Use it only with a lifecycle token from position_lifecycle_begin', 'Do not use it for unrelated positions', and 'never reuse a token after close'. What is missing is routing guidance for an agent that wants a safety assessment without a purchased bundle, i.e. no statement to use check_trade_safety instead.

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