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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces this with 'This tool only READS' and adds richer behavior: shapes are sealed at open, never edited later, and it returns what the rail cannot do with reasons. It also clarifies that constraints are not backlog. No contradiction with 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?

The description is lengthy and multi-paragraph, with some redundancy (e.g., 'This tool only READS' repeated, and the distinction between reading and writing appears twice). While structured with bold terms, it could be tightened. It is not front-loaded as efficiently as possible, but the content is valuable.

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?

With no output schema, the description compensates by explaining return shapes, the exact phrase that earned each shape, and the list of constraints. It also covers the read-only nature and the separate act of writing terms. This is adequate for an agent to call the tool correctly, though examples of output structure are not provided.

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 100% so the parameter is documented. The description adds significant usage semantics: what to pass in `describe`, the expectation to quote the exact phrase back, and the behavior when omitted (whole catalog). It goes beyond the schema's basic description and gives operational guidance.

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 states a specific purpose: mapping money arrangement to owner/customer words, returning named shapes and constraints. It uses concrete terms like DEPOSIT LADDER and HOLD SHAPE, and explicitly distinguishes this read-only tool from sibling acts like writing terms onto a service. This clearly differentiates it from the sibling tools listed.

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?

Provides explicit when-to-use instructions: pass `describe` with their own words, omit for whole catalog, and ASK if nothing matches rather than defaulting. It also tells the agent what not to do (never a workaround, only buildable alternatives) and clarifies that writing terms is a separate act. This is thorough and actionable.

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