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

With no annotations, the description carries the full burden and does substantially: it discloses what the Court does (verifies the key opens the record and reproduces the fingerprint, holds the key under its own ring until judgment, reads in memory, erases at delivery), that every opening is logged, that the vault key is never sent, the required credential (party) and a 60/hour rate cap. This is unusually rich behavioral context; it lacks only return-value shape.

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 content is information-dense but wrapped in ornate courtroom prose ('lodged a sealed record and tendered it in a case'), and the genuine operational payload is not front-loaded ahead of the scenario framing. Every clause carries some signal, but the register makes it slower to parse than necessary.

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 parameterized mutation-like operation with no annotations and no output schema, the description covers behavior, credential, cost and limits well, but says nothing about the return payload or per-record error/success reporting. It is adequate but leaves real gaps for a 3-parameter tool with only 33% schema coverage.

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 only 33%, so the description must compensate. It does add meaning for dataKey ('the record's own data key... never the vault key') and fingerprintKey (where a fingerprint was lodged), and implies the matter scope. It does not explain the records array structure, id semantics, or the step enum values beyond what the schema already holds, so compensation is partial.

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: presenting a held record's own data key (and fingerprint key where lodged) so the bench can open/read it, explicitly excluding the vault key. That is a clear verb+resource with a scope constraint. It does not, however, differentiate itself from the sibling read_held_record or hold_record, which share the same domain vocabulary, so the agent cannot cleanly tell them apart from the description alone.

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 framing ('the bench needs to read it', 'A record not opened is a record not produced') suggests this is the mandatory step for producing a tendered held record, and it notes credential=party and cost/rate limit. There is no explicit when-to-use / when-not-to-use guidance or pointer to an alternative tool (e.g. read_held_record), so an agent must infer selection.

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