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

Annotations already cover the read-only, open-world, non-destructive, non-idempotent profile. The description adds value beyond them by disclosing the cost behavior ("the call is not charged when it cannot be" identify the entity) and the signed pass/warn/fail output framing, though it omits rate limits or latency expectations.

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?

Two sentences, front-loaded with the capability, then the inputs, then the outputs and the usage trigger. No filler, and it reads as a compact decision aid.

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?

Despite no output schema and an open-world, multi-section operation, the description enumerates what is returned (legal entity, LEI and parents, VAT validity, sanctions screen of company and officers, domain age/mail/TLS, signed checks with sources) and notes the default include set, so an agent has enough to act 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?

Schema description coverage is 100%, so every parameter is already documented, and the description only restates the input modes (name+country, registry number, VAT, LEI, domain) and the sections returned. The "send exactly one of" constraint lives in the schema, so the description adds little semantic value beyond it.

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 capability (company due diligence / KYB, vendor and supplier checks) and frames it as an aggregate that returns registry, LEI, VAT, sanctions and domain data. This clearly distinguishes it from the narrower siblings sanctions, vat, company and domain.

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 when-to-use trigger: "Use when you must decide whether to trust an unknown company." However, it never states when to prefer the narrower sibling tools (sanctions, vat, domain) over this broader call, so the routing guidance is present but incomplete.

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