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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is low; the description still adds the three distinct outcome states (single match with match reason, ambiguous with all candidates and reasons, not_found) and the not_found quirk for register/Crunchbase/Wikidata keys. However, much of the return description overlaps the existing output schema, and 'Read only' restates readOnlyHint=true.

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?

Front-loaded with purpose, then returns, then a one-line safety note — a sensible ordering with no filler sentences. The first sentence is long and clause-heavy, and the trailing 'Read only' duplicates the annotation, so it is efficient rather than exemplary.

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 two-parameter resolver with a full output schema and comprehensive annotations, the description covers purpose, accepted inputs, rejected input kinds and the three result states. Nothing essential is missing, though an explicit alternative-tool pointer and reliance on the output schema instead of restating return fields would tighten it.

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 both parameters, including that kind is inferred from the identifier's form when omitted. The description adds only the not_found consequence for three specific kinds, which is behavioral rather than parameter-meaning information; the baseline 3 is appropriate.

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 ('Find the published Trooth Network record for a company') and immediately bounds the acceptable identifier space (domain, URL, slug, name), which cleanly separates it from list/search siblings. The explicit not_found behavior for register, Crunchbase and Wikidata inputs further marks it as a single-company resolver, not a search.

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 real routing guidance on the input side: which identifier forms are accepted and, notably, that registry identifiers, Crunchbase addresses and Wikidata IDs are accepted but always answered not_found because Trooth keeps no such lookup. What is missing is an explicit pointer to an alternative (e.g. trooth_search_companies) for partial or name-fragment lookups.

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