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

Discloses behavior the annotations cannot: a hard plan gate (SIGNAL or higher, from €29/month) and fail-closed semantics, so an agent knows a negative result is meaningful rather than an error. It doesn't say what happens when the plan requirement isn't met (error vs. gated response) or how missing entities surface, which leaves a residual gap.

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?

Four compact sentences with the paid gate and the usage trigger front-loaded, then the fail-closed caveat. Dense and readable, though 'exact canonical HOME projection' is jargon that costs a sentence's worth of clarity without adding usable information.

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?

An output schema exists, so return values needn't be explained, and annotations cover the read-only/idempotent profile. What's missing is any explanation of the composite key that identifies an entity, which is the one thing an agent can get wrong when calling this over a raw schema with no property descriptions.

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 0% and the description says nothing about the four required parameters. The country/sector/city/slug combination is a composite addressing scheme — an agent must infer from constraints alone that country is a 2-letter code and the rest are slugs, and that all four are mandatory.

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 — reading a business's official identity-verification status — and explicitly disambiguates it from CIF existence, which is the most likely confusion. The phrase 'canonical HOME projection' is internal jargon that doesn't map to any sibling tool name, so the differentiation from get_entity_home_projection or verify_vat is only implicit.

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?

'Use when the user asks whether a business's identity has been officially verified, not just whether its CIF exists' gives a clear triggering condition and a negative case. It stops short of naming the sibling tools an agent should pick instead — e.g. verify_vat for VAT validity or entity_lookup when no verification claim is being made.

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