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

No annotations are provided, so the description carries the full burden. It says 'List all contracts', which implies a read operation, but offers no details about whether the status parameter filters results, no pagination or ordering info, and no statement about side effects.

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?

A single concise sentence that states the tool's purpose without unnecessary words. It is front-loaded, though the phrase 'with their status' is somewhat ambiguous and could have been made clearer.

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 simple list tool, this is borderline, but the missing explanation of the status parameter is a critical gap. An agent may not realize that providing status filters the list. There is also no mention of return shape or behavior when no status is 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?

The description adds no semantic meaning to the single 'status' parameter. 'With their status' might refer to the output, not to an optional filter. Schema coverage is 0%, and while the enum values provide allowed inputs, the description does not explain how or when to use the parameter.

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 action ('List') and resource ('all contracts'), and mentions status as a relevant field. It clearly differs from mutation siblings like contract_create and contract_cancel, though it does not clarify that status is a filter rather than simply an output field.

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?

The verb 'List' implies this tool is for viewing contracts, and sibling names suggest other operations. However, there is no explicit guidance on when to use contract_list versus contract_get (e.g., multiple vs single), nor any mention that it is read-only.

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