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 return content per branch (session handle, signed receipt, verification verdict plus digest and matched evidence) and the credit cost per op. It does not say whether issue_receipt persists or writes anything durable, what permissions/keys are needed, or whether evidence sessions expire, which are the behavioral facts an agent most needs for a mutating ledger-style 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, front-loaded with purpose before exclusions, returns and metering, and each sentence contributes new information. The metering sentence is dense but earns its place because cost varies per branch; the deprecated-alias sentence is borderline but useful for routing legacy calls.

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 purpose, alternatives, returns and pricing for a genuinely complex 25-parameter, three-branch tool with no annotations and no output schema. The remaining gap is significant: an agent cannot tell from the description which parameters are needed for begin_evidence versus issue_receipt versus verify_evidence, and there is nothing about failure modes, expiry, or signing prerequisites.

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?

Coverage is only 32% across 25 parameters, so the description needed to compensate and largely does not. Its only real parameter value-add is the metering split for kind (three offline kinds free, live reads billed C4); it never maps the many inputs (user, asset, action, providers, amount_usd, settlement, expected_order, decision_input, attestations) to the branch that requires them, and schema-supplied hints like decision being required for settle modes are only partially echoed.

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 set per branch (open a trade-evidence session, issue an execution receipt, verify an evidence artifact) and ties each to an explicit "op" value. It also states what the tool is NOT for, naming trade_guard and the venue guard tools, so an agent can separate it from siblings without opening 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?

Explicit exclusions are given (do not use to decide trade safety → trade_guard; do not use to settle a swap guard → venue guard tools), and the phrase "after a trade" frames the timing. What is missing is guidance for choosing among the three ops themselves and which inputs each op requires, so the agent still has to infer branch prerequisites.

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