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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description meaningfully extends this by stating the lesson is 'permanent' and that 'settlement happens exactly once', which makes the irreversibility concrete. It also discloses a `needs_confirmation` response path despite there being no output schema — useful granularity beyond 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?

It is short and front-loaded, but the opening clause ('The ritual moment: evidence has landed, the expectation closes, the lesson is written') is atmospheric framing that consumes prime space without adding operational content. Trimming it would leave a purely actionable description.

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 5-parameter mutation tool with no output schema, the description covers the important ground: prerequisites, irreversibility, one-shot settlement, and the confirmation path. It omits guidance on workspace/approvalId handling, which the schema partially covers, but nothing critical to calling it 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?

Schema coverage is 80%, so the schema already documents lesson, entryId, verdict and workspace. The description adds only that `lesson` is permanent and should cite evidence; verdict, workspace and approvalId semantics are left entirely to the schema. Baseline 3 is appropriate when the schema does most of the work.

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 conveys the operation — closing an entry once evidence lands and writing a lesson — and distinguishes it from siblings like ledger_entries_add_evidence by requiring that evidence 'actually answers the prediction'. The opening metaphor ('the ritual moment') is evocative rather than literal, so the exact verb+resource must be inferred, but it is recoverable.

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 an explicit precondition for use ('Only propose settlement when attached evidence actually answers the prediction') and routes the agent to `ledger_entries_get` to verify first. It stops short of naming the correct alternative when the precondition fails (e.g., add_evidence), so the exclusion is implied rather than fully specified.

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