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

With no annotations provided, the description carries the full burden. It discloses what the tool returns (codes and names) and that these values feed other tools' state filters, but it stays silent on ordering, whether USPS territories are included, and what 'tracked projects' means for membership in the list — minor gaps for a trivial read-only lookup.

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 sentence that front-loads the output content and closes with the operational purpose. Every word earns its place, and the title adds the scope qualifier ('with tracked projects') without redundancy.

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 zero-parameter tool with no output schema or annotations, the definition is nearly complete: an agent knows what comes back (state codes and full names), for which states (tracked projects), and why to call it. The only gap is the unspecified return shape (object vs. plain list), which is a minor issue for a tool this simple.

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 tool has zero parameters, so the schema (an empty object) conveys nothing; the baseline is 4. The description adds the cross-tool hint that these values are consumed as the `state` filter in other tools, giving the no-argument invocation a clear purpose.

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 title 'List states with tracked projects' supplies a specific verb and resource, and the description names the exact output content: 'USPS state codes and full names'. This clearly differentiates list_states from sibling reference listers list_causes and list_policies, which cover different entities.

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 description states its use context explicitly: the output is 'usable as the `state` filter in other tools,' which tells an agent when to call it (when it needs valid state filter values). It doesn't name alternatives or exclusions, but for a zero-parameter static reference tool, the condition for use is essentially self-evident.

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