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

With no annotations, the description carries the full burden and does add useful behavior: verified listings are ranked first, listings have rules that must be respected, and the network carries no prices. It still omits other operational traits such as result limits, pagination, authentication needs, or return structure, so transparency is only moderate.

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 four short sentences and front-loads the core search action and filters. The later sentences about verified ordering, listing rules, and no prices each add relevant context without waste.

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 search tool with complete parameter schema coverage and no output schema, the description covers purpose, ranking behavior, a key limitation (no prices), and the next-step workflow around listing rules. It could be more complete by explaining result shape or pagination, but the essentials for invoking it correctly are present.

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 the schema already documents trade, service, and location. The description mirrors that meaning by saying trade and city-or-ZIP location plus an optional service keyword, but adds no deeper syntax, taxonomy, or format details beyond the schema.

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 verb and resource: search the network registry for local home-services pros, filtered by trade and location with an optional service keyword. It is clearly a search/discovery tool rather than a request-sending or listing-detail tool, though it does not explicitly name sibling alternatives to differentiate itself.

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?

Usage is implied by the workflow note to read each listing's rules before sending a request, which suggests this tool is used before send_job_request. However, it does not explicitly say when to use search_pros versus get_listing, network_stats, or other siblings, nor does it give when-not-to-use guidance.

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