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

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so the description's real contribution is behavioral nuance: sources are conditional ("when keyed", "when the operator enabled them") and `clear` is only returned when every list was actually checked, which is a non-obvious semantic the agent would otherwise misread. It also discloses the returned shape (standing, findings, per-section results) with no output schema available. It omits any mention of rate limits, cost, latency, or failure modes, keeping it from a 5.

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?

One dense opening question front-loads the purpose, then a single paragraph covers inputs, output semantics, source coverage, and the key caveat in that order. Every clause carries information; even the parenthetical format hints ("two letters", "state entity number") earn their place. Only the trailing "Served by NicheDB" attribution is arguably filler.

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 five-parameter, no-output-schema lookup, the description supplies what the schema cannot: the returned fields, the meaning of each standing value, the exact upstream sources per section, and the identity-confirmation caveat. What remains uncovered is operational (what happens on partial source outages, timeouts, or failures), which matters given several sources are conditionally enabled.

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 all five parameters including the note that EIN is "never checked"; the description mostly restates these. It adds only marginal semantics, chiefly that parameters other than name are optional cross-checks and that identifiers should be used to confirm identity. That is a small delta over structured data, so the baseline 3 applies.

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?

States a specific verb-and-resource pair ("Business Standing Check") and immediately makes it concrete by asking "Is a business on anybody's list?" followed by an explicit enumeration of every list consulted (OFAC, GLEIF, EDGAR, OpenCorporates, SAM.gov, RDAP, Spamhaus/URIBL/SURBL/Safe Browsing). This clearly separates it from siblings like nichedb_reputation_lookup or nichedb_check_domain, which are narrower lookups.

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?

Tells the agent exactly what to supply ("Give its name, and any of domain, state, number and ein") and under what condition a `clear` result is meaningful, which shapes when the tool is worth calling. It also adds a usage rule against over-trusting results: "A name match is not an identity." It never names an alternative sibling or states when not to use this tool, so it stops short of a 5.

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