List supported national company registries

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds genuinely valuable behavior beyond that: stub/example modules are hidden, the registry set grows dynamically without schema changes, and — most notably — 'This tool has no error mode; a failure here is a bug, not something to retry differently.' This last disclosure directly shapes agent behavior by preventing useless retry loops.

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 tightly packed paragraphs with no filler. The first establishes the verb, resource, and return fields; the second delivers usage timing, a prohibition, a filtering behavior, and error semantics. Every sentence earns its place and the core purpose is front-loaded in the opening clause.

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 zero-parameter, read-only listing tool, this is complete. The output schema exists to document the return structure, annotations cover the safety profile, and the description covers everything else an agent needs: what is returned, when to call it, what is filtered out, and how to interpret failures. There are no gaps an agent would have to guess about.

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?

The tool has zero parameters with an empty schema at 100% coverage, so there are no input semantics to clarify. Per the baseline for zero-parameter tools, a 4 is appropriate; the description correctly spends no space on inputs and instead uses that space for output contents and usage guidance.

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 opens with a specific verb and resource — 'List every national company registry this service can answer for right now' — and goes on to enumerate exactly what each entry contains (id_scheme, source URL, licence, credential requirements). This clearly differentiates it from the sibling tools (lookup_company, search_company, company_deadlines, validate_company_id), none of which list available registries.

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 explicit invocation conditions: 'Call this before your first lookup in a country you have not used here before, or whenever a user names a country you are unsure is supported.' It also provides a strong negative rule — 'never hard-code a country list of your own' — which prevents the agent from caching or assuming a static list. No alternative tool is relevant for this operation, so no exclusion is needed.

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