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

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the $350 full charge at checkout, the full-refund conditions, the acceptance precondition, and that the link is e-mailed to the named person. It omits the most decision-critical behavior for an unannotated tool — whether invoking it is a read-only retrieval or itself triggers a charge, and whether the link expires or is reusable.

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?

Three sentences with no gross padding, but the opening leads with product and pricing context instead of the tool's action, and the final sentence about e-mail delivery is secondary information placed where the return value should be. The structure is serviceable but not front-loaded on what the agent must decide.

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 two-parameter, fully documented, unannotated tool, the description should settle the read-vs-charge question and indicate the return value (a URL). Neither is addressed, leaving the agent unable to predict the effect of calling or what it receives, which is the main gap this description needed to close.

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 both matterId and matterToken are already documented as coming from open_matter. The description adds no parameter-level meaning and its reference to 'the named person' does not map to either parameter, so the schema baseline of 3 applies.

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 identifies the resource (the firm's card payment page for $350) and its preconditions, but never states the action the tool performs — nothing says it returns or generates a link URL. The 'get_' name and the described resource make the intent inferable, but the purpose is left implicit rather than stated as a verb+resource.

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?

It gives a real precondition — usable only once the named person has accepted the engagement — which narrows when to call it. However, it names no alternatives and no exclusions, so the agent gets implied rather than explicit guidance on when this beats talking to the user directly or checking get_matter_status first.

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