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

Annotations already declare readOnlyHint and openWorldHint, so the bar for added behavioral detail is lower. The description goes beyond them by disclosing the per-call cost, the x402 payment mechanism with the required metadata path, the endpoint, the max of 10 entities, the returned fields, and the surprising fact that an empty result is still a paid 200. This is substantial, non-obvious behavior.

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?

Every sentence earns its place: pricing, payment routing, resource and query keys, states, limits, and paid-empty behavior. It front-loads the cost and payment requirement, which is exactly what an agent needs to know before invoking, and contains no wasted prose.

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?

The description is largely complete for invocation: payment, endpoint, states, query parameters, limits, and return-field categories are all present, and the output schema exists to document return structure. The only notable ambiguity is 'Up to 10 entities'—whether that applies to input batch size, response size, or something else is not fully specified.

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 0% schema description coverage, the description must carry the semantic weight. It explains that name means exact name and entity_number means a registry entity number, and 'Served states: FL, OR' maps to the state enum. It does not explicitly tie each property to its schema field or clarify the meaning of 'Up to 10 entities' relative to the single-object input, but it compensates for the bare schema better than most.

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 clearly identifies the resource: state business-registry records, and the query keys: entity number or exact name. It also lists the served states, which differentiates it from license- and transport-oriented siblings. However, the core sentence lacks an explicit verb like 'retrieve' or 'look up', leaving the action to be inferred from the tool name.

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 gives concrete conditions for use: only FL and OR, and only by entity number or exact name. This establishes when it is appropriate and implicitly rules out other states or fuzzy name matching. It does not explicitly name alternatives or say 'use license_search for licenses', but the domain is clear enough from the sibling set.

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