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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial beyond them: the exact cost ($0.002 USDC per successful call), the payment rails (x402 on Base, Solana or Arc), and the refund behavior for failed calls. It also discloses the authoritative-source constraint and that results include a total match count. These are material operational traits an agent cannot get from structured fields.

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 capability and its scoping are front-loaded, followed by the alternative source and then pricing. Every element is relevant, though the single long sentence with stacked parentheticals is dense and could be split for scanability.

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?

An output schema exists, so return formatting needn't be explained, and the description still notes that a total match count is returned. Combined with read-only/openWorld annotations, the source authority note, and full pricing disclosure, an agent has everything needed to decide and call correctly.

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?

With 100% schema description coverage, the schema already documents all seven parameters including the prefix semantics for names and the state/province code format. The description restates the filter set (last name, first name, city, state/province, country) without adding syntax or format detail beyond the schema. Baseline 3 applies because the schema carries this dimension.

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 verb and resource (retrieve NCARB-certified architects from the official Certificate Lookup) and enumerates the returned fields (name, city, state/province, country) plus the total match count. It also states the population definition (US certificate holders licensed in at least one US jurisdiction), which separates it from generic architect directories. It does not explicitly name a sibling tool, so it stops short of 5.

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 an explicit exclusion-plus-alternative: 'To confirm a specific license number use the state board roster,' which tells the agent when this source is insufficient. The filtering options are described, giving clear context for use. However, the alternative named is an external data source rather than a sibling tool, and there is no guidance on when to prefer this over other people/business directories in the catalog.

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