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

Annotations already cover readOnly/idempotent/openWorld, and the description adds genuinely new behavioral facts: the result taxonomy (match / ambiguous / no_match), the billing rule that only 'match' consumes a query, and the required plan tier. These quota and plan details are not derivable from annotations or schema and materially affect how the agent batches calls.

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 short, front-loaded sentences with no filler: capability, result semantics, cost/plan constraint, use case. Every sentence carries information the agent needs.

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?

With no output schema, the description adequately covers the shape of results (match/ambiguous/no_match) plus quota and plan constraints, so an agent knows what to expect. The only gap is the absence of routing guidance against sibling tools, which is minor given the strong capability and cost disclosure.

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 both parameters are already documented (names and the province tie-breaker). The description only restates the 100-item cap, adding nothing new about the parameters themselves; baseline 3 is appropriate when the schema does the work.

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 (find), a precise resource (CIF), and the input scope (a list of company names, up to 100). This is clearly distinguishable from siblings like get_company (lookup by identifier) and search_companies (fuzzy search), so an agent can select it without opening the schema.

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 names a concrete use case ('útil para completar hojas de clientes') and a hard precondition (Pro plan or higher), giving the agent clear selection context. However, it never states when NOT to use it or which sibling to prefer (e.g. get_company when you already have the CIF), leaving alternatives to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description contributes the subscription-tier requirement, which is genuinely new behavioral context, but says nothing about historical coverage limits or ordering of the returned acts.

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?

A single dense sentence that front-loads the resource and then illustrates the return content; the trailing ellipsis signals the list is non-exhaustive without padding. The act-type enumeration slightly lengthens it but earns its place given there is no output schema.

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 one-parameter, fully-annotated read tool with no output schema, the description enriches the picture by naming the kinds of records returned. Missing only minor operational detail such as volume or chronological ordering of the history.

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% and the single cif parameter is fully documented in Spanish (format, spaces and hyphens accepted, example). The description adds no parameter-level detail, so the baseline 3 applies.

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?

Names a specific verb+resource (retrieving BORME-published acts for a company) and enumerates the concrete event types returned, which makes the tool's scope understandable at a glance. It does not explicitly contrast itself with siblings like get_company, though BORME is distinctive enough to stand alone.

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?

Usage is only implied: the tool is for consulting a company's official gazette history. It does add a real gating condition ('Plan Pro o superior'), but there is no explicit statement of when to prefer this over get_company or get_risk_profile, nor any exclusions.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses three things an agent cannot get from structured fields: the cost ('Gasta 1 consulta'), that certain returned fields are plan-gated (domicilio, tramo de facturación, ownership, GLEIF group, administradores), and the provenance/liability caveat that the status is derived by APIEmpresas from the BORME and is not a Registro Mercantil certificate.

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?

Purpose is front-loaded in the first clause, followed by the field list and the cost/caveat notes. The enumeration is dense but justified because no output schema exists, so the field list is the only return-value documentation; still, it runs long enough that a reader must scan the whole opening sentence.

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?

With no output schema, the description carries the return-value burden and does so by enumerating fields, plan tiers, cost and data provenance. Remaining gaps are edge behavior (what happens for an unknown or malformed CIF) and nothing about response shape beyond the field list.

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 params documented with an example CIF and a plan note), so the baseline is 3. The description goes beyond it by tying include_directors to the concrete field it unlocks (administradores/cargos vigentes) and by listing which other fields depend on the plan, giving extra meaning over the schema text.

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 retrieval verb (fetch data for a Spanish company) plus the exact key it operates on (CIF/NIF), and enumerates the returned attributes. The 'by tax ID' framing implicitly separates it from name-based siblings such as search_companies and find_cif_by_name, and adds an English gloss for disambiguation.

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?

Usage is implied: call this when you already have a CIF/NIF and need company master data. It never explicitly names a sibling or states when NOT to use this tool (e.g. use verify_company to validate a CIF, search_companies when you only have a name). No exclusions or prerequisites beyond the plan note on optional fields.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the external data source (consistent with openWorld) and the 'Plan Business' subscription requirement, which is genuine access context, but says nothing about return shape, pagination limits beyond the schema defaults, or result completeness.

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 compact fragments with no wasted words and the core purpose front-loaded. The trailing 'Plan Business.' is terse but does carry information, so nothing is padding.

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?

With no output schema, the description should ideally indicate what a contract record contains or how results are paginated, but it does not. Annotations cover safety and the source is named, so it is minimally viable but leaves the agent guessing about the payload.

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%: cif, page and limit all have descriptions with defaults and format notes. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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+resource: public-sector contracts awarded to a company, and names the underlying source dataset (Plataforma de Contratación del Sector Público). This clearly distinguishes it from siblings like get_company or get_borme_history, though it never explicitly references those alternatives.

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?

Usage is only implied — an agent infers it should call this when it wants public procurement records for a company. There is no statement of when to prefer it over siblings such as get_borme_history, nor any exclusion. 'Plan Business' hints at a tier prerequisite but is not framed as a usage condition.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: the data provenance (derived from BORME publications), the output contents ('nivel y explicación'), and a plan/tier requirement ('Plan Business') that acts as an access precondition.

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?

One dense sentence, front-loaded with the resource and derivation, then the event categories, then the output and plan note. Every clause earns its place, though the parenthetical enumeration of BORME events is slightly long.

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?

With no output schema, the description carries the return-value burden and does so ('nivel y explicación'). The single required parameter is fully covered by the schema, and the plan limitation is disclosed. It falls short only on sibling routing, which matters given the overlapping BORME-oriented siblings.

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% and the single cif parameter is fully documented in the schema itself (format, example, accepted spaces/dashes). The description adds nothing about the parameter, so the baseline 3 applies.

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?

It names a specific resource (perfil de riesgo de una empresa), states the derivation source (publicaciones en el BORME), and lists the triggering event types (concursos, disoluciones, cierres de hoja, cambios de administradores). This is clearly distinguishable from siblings like get_borme_history, though it never explicitly contrasts itself with them.

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?

There is no statement of when to use this tool versus get_borme_history, get_company, or verify_company. The only usage-adjacent signal is 'Plan Business', which hints at an entitlement gate but does not tell the agent when this tool is the right choice.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavior: zero query consumption and Sandbox incompatibility, the latter being an environment-specific failure mode not visible anywhere else. Return format is not described, but the returned fields are enumerated.

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?

Three terse sentences: payload, cost, environment constraint. No filler, and the most decision-relevant facts (free to call, fails in Sandbox) are stated plainly at the end where they are easy to scan.

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?

With no output schema, the description carries the return-value burden and does so by listing plan, usage counts, and credit balance. Combined with annotations covering safety and the Sandbox caveat, an agent has everything needed to invoke it 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. No parameter guidance is expected or needed.

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 the exact resource and its payload: account plan, queries used/available, and credit balance. It is a noun-phrase enumeration rather than a verb+resource statement, but an agent can immediately tell this returns account-consumption data. Sibling differentiation is unnecessary since none of the company-lookup siblings overlap with account usage.

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 two concrete usage conditions: calling it costs no queries, and it is unavailable in the Sandbox. That tells the agent when the tool is safe/cheap to call and where it will fail. It does not name alternatives, but no sibling tool covers this domain, so no routing guidance is needed.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds only that matches include the CIF; it says nothing about result ordering, partial-name matching behavior, or default result count beyond what the schema states.

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 short sentences, front-loaded with the action and the return value. The English sentence is a near-verbatim translation of the Spanish one, which is mildly redundant but serves bilingual readers.

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 simple two-parameter, no-output-schema lookup tool, the description covers the action, the input basis (name), the returned key field (CIF), and the usage scenario. Only the exact match payload fields are left unspecified, which is a minor gap.

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 both 'query' (minLength 2) and 'limit' (1-25, default 10) are already documented in the schema. The description merely restates that lookup is by name and adds no syntax or matching-rule detail beyond the schema.

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?

Names a specific verb (busca) and resource (empresas españolas por nombre o razón social) plus what it returns (coincidencias con su CIF). However it does not differentiate itself from the very similar sibling find_cif_by_name, so an agent must still guess which lookup tool is preferred.

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?

Explicitly states the selecting condition: useful when the CIF is not known. That is real when-to-use guidance, but it names no alternative tool and gives no exclusion for the overlapping find_cif_by_name / get_company siblings.

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

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

Annotations already declare the safe read-only, idempotent, open-world profile, so the bar is lower. The description still adds value beyond them: query cost (2 consultas), plan gating, and the categorical verdict output (pass/review/fail). It does not discuss rate limits or failure/error behavior, which keeps it out of 5 territory.

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 main purpose and the enumerated checks are front-loaded in the first sentence, with cost/plan and the returns trailing. Dense but every clause carries information; the trailing English fragment 'KYB check for a Spanish company' is mildly redundant with the opening.

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?

There is no output schema, so the description appropriately carries the return burden, naming legal form, LEI, group parent and sole partner alongside the verdict. Combined with cost and plan gating, an agent has enough to invoke correctly; it only lacks guidance on sibling selection.

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 each parameter (cif, vat, name, person) is already documented in the schema. The description reinforces the purpose of 'name' (matching the declared razón social) and 'person' (administrator/sole partner) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (verificar) and resource (empresa) and enumerates exactly what the check covers: existence/active status, name match, administrator/sole-partner check, plus alerts and a pass/review/fail recommendation. That is well beyond a tautology. However, it never distinguishes itself from the sibling get_company, which an agent would plausibly confuse it with.

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?

Offers real operational constraints – 'Plan Pro o superior; gasta 2 consultas' – which tell the agent the cost and eligibility. But there is no explicit when-to-use vs get_company or get_risk_profile, so the choice between siblings is left to inference.

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