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

With no annotations, the description does real work by declaring the call 'Read-only' and by explaining that results come from the canonical transition map, the role, and the durable authorization scope — so the agent knows the output is a deterministic authorization call, not a free-form query. It also states the caller is verified by EIP-712 proof. However, it says nothing about what an empty action set means, how an invalid or mismatched role is handled, or what the response looks like, which matters more for a tool without annotations or an output schema.

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?

Two sentences plus a short routing pointer, with the identifying scope and the 'Read-only' safety marker front-loaded. No filler; every clause contributes either scope, derivation basis, or an alternative tool. There is a minor encoding artifact ('commitment —' rendered as a garbled character), which does not affect comprehension in context.

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 4-required-parameter tool with a nested EIP-712 proof object, no annotations, and no output schema, the definition explains the inputs and the authorization basis well but leaves the return value undefined — an agent cannot tell whether it gets an array of action identifiers, objects with metadata, or a boolean-per-action. It also omits failure modes (invalid proof, role/enum mismatch). Adequate, but not complete given zero structured behavioral coverage elsewhere.

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 100%, so all four parameters (commitmentId, agentId, role with its enum, proof) are already documented in the schema. The description reinforces that role and durable authorization scope drive the result and that proof is an EIP-712 credential, but adds no format, matching, or consistency rules beyond the schema. Baseline 3 applies because the schema carries the parameter detail.

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?

States a specific verb and resource: it returns the lifecycle actions the caller may currently perform on a commitment, and explains that these are derived from the canonical transition map, the caller's role, and the caller's durable authorization scope. This meaningfully separates it from the mutation siblings (accept/cancel/close) and from get_commitment, but it does not explicitly contrast with the other read-side checks such as get_commitment_status or get_authority_validation.

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?

Offers an explicit routing rule: 'For full recovery context, use get_recovery_status,' which names the alternative and the condition that selects it. The core 'when' case (checking what actions are permitted before acting) is clear by implication from 'may currently perform,' but no explicit exclusion or prerequisite flow is spelled out for the remaining read siblings.

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