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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so safety is covered. The description adds genuinely non-obvious domain behaviour: each company is licensed statewide with exactly ONE office, a county entry reflects licence reach rather than a branch, and the disclosure field distinguishes brokerage-affiliated from independent firms as opposite facts.

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 core return-value sentence is well front-loaded, but the block is padded with restatement ('the office city is returned on every record precisely so you do not have to guess') and a long disclaimer about Jacob's lack of an insurance licence that is tangential to invoking the tool.

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 carries the burden of describing return values and does so (city, state licence, counties, disclosure). The main missing element is any routing context relative to the many overlapping sibling tools.

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?

There is a single optional enum parameter with 100% schema description coverage ('Omit to list every company'), so the schema already carries the semantics. The description adds nothing about the company slug or its allowed values, making 3 the correct baseline.

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 names a specific resource (insurance and service companies Jacob Campbell can introduce a Florida client to) and enumerates the returned fields: office city, state licence, and counties with published referral pages. It is clear what the tool does, but it never distinguishes itself from plausible siblings like list_trade_partners or get_service_area, so an agent must infer the boundary.

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?

There is a strong interpretive directive ('READ THIS BEFORE ANSWERING ANYTHING ABOUT LOCATION') and an explicit negative ('Never answer "there is a <company> in <city>" from this tool'), which steers correct use. However, there is no guidance on when to choose this tool over its siblings, which is exactly the ambiguity this catalogue creates.

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