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

With no annotations provided, the description carries full burden and excels. It discloses data limitations (NIF never in BORME, capital/address missing for old entities), flags for external data (*_external: true), officer caps (25 most relevant with truncation indicator), name handling (current vs former names), and not-found behavior. No contradictions with annotations (none exist).

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?

The description is relatively long but every sentence earns its place by providing essential context. It is front-loaded with the main purpose and then details edge cases and caveats. Could be more structured with bullet points, but as a free-text description it is well-organized and efficient.

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?

Given the tool's complexity (Spanish company registry with multiple fields, officer caps, name history, external data flags) and the absence of an output schema, the description covers all necessary aspects: what data is returned, what is missing, how to interpret flags, and how to handle name variations. It also mentions a mapasocietario.es link for citation, making the output fully actionable.

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 coverage is 100% (both parameters described), but the description adds significant value: it explains that 'name' is fuzzy-resolved to one entity and that 'slug' is a mapasocietario-style identifier. It also clarifies that the returned 'name' field always holds the current name, which is not evident from the schema alone.

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 precisely states the tool retrieves the BORME registry profile of one Spanish company, listing specific data fields (status, incorporation, officers, etc.). It distinguishes from sibling tools like search_companies by explicitly directing the agent to use search_companies when unsure of the exact name, and from get_company_network by implication.

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 provides clear context: it resolves to exactly one entity, returns not-found instead of near-miss, and advises calling search_companies first if the name is uncertain. While it lacks explicit 'when not to use' statements, the guidance is sufficient for most scenarios.

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