asientouno

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

The readOnlyHint annotation already covers safety, and the description adds meaningful behavioral context: results are paginated and each act includes a link to the official PDF, i.e. provenance. These are not deducible from the annotation alone, though auth and rate-limit behavior are not mentioned.

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 a single front-loaded sentence with no filler. Every clause contributes: what is listed, for whom, pagination, and the official-PDF provenance detail.

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 output schema and the readOnlyHint, the description plus schema is largely sufficient for calling this simple read-only tool correctly. The main gap is the absence of explicit usage guidance relative to the sibling tools, so it is not a perfect 5.

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 schema already documents `tipo`, `desde`, and `cursor`; `limit` has bounds, type, and default. The description only adds the general company scope and pagination, and it does not compensate for the undocumented `empresa_id`. With 60% schema coverage, this is adequate but not especially informative at the parameter level.

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 states the specific verb ('Lista'), the resource ('actos del BORME'), and the scope ('de una empresa'), and adds pagination plus official PDF links. This clearly distinguishes it from sibling tools for contracts, annual accounts, risk, subsidies, and person roles.

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 use case is implied by naming the BORME acts resource, but there is no explicit statement of when to use this tool over the siblings or when not to use it. It gives the agent enough to infer the basic purpose, but no routing guidance.

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=true, covering the safety profile. The description adds the source context (BORME real data) but does not disclose additional behavioral traits like pagination, result limits, or any special handling. Since annotations cover the main safety aspect, a neutral score is appropriate.

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 a single, concise sentence that front-loads the core purpose (search companies by name or NIF) and includes the relevant source context. Every word adds value, and there is no redundancy.

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 search tool with an output schema and read-only annotations, the description is reasonably complete. It covers the essential search criteria and data source. It does not elaborate on result structure or interactions with sibling tools, but given the simple search nature and available structured metadata, this is adequate.

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 50%: only 'query' has a description, and the description text 'por nombre o NIF' aligns with that. 'limit' has no description in the schema, but its name, default, and range make its purpose self-evident. The description does not add extra nuance beyond the schema, so it meets the baseline without fully compensating for the uncovered parameter.

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 clearly states the verb 'Busca' (search), the resource 'empresas' (companies), and specifies the search method (by name or NIF) against the Spanish commercial registry with real BORME data. This clearly distinguishes it from sibling tools that focus on specific aspects like acts, charges, contracts, or reports.

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 indicates the tool is for searching companies by name or NIF, which implies its primary use case. However, it does not explicitly state when to prefer this tool over siblings like asientouno_informe_completo or asientouno_riesgo_empresa, nor does it exclude scenarios. The context is clear but without explicit alternatives or when-not instructions.

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?

The readOnlyHint annotation already signals safety, and the description adds behavioral nuance by disclosing the free-plan limitation: only corporate roles such as administradoras and auditoras are searched. It also sets expectations about historical and current charges without conflicting with the annotation.

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 concise sentences that front-load the core purpose and add only one relevant restriction afterward. No filler or repeated annotation 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?

For a read-only person search with an output schema, the description covers the main invocation path and the plan restriction. The only meaningful gap is the undocumented persona_id parameter, which keeps it from being fully complete.

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?

Only 'nombre' is described in the schema and reinforced by the description; 'persona_id' has no schema description and is not mentioned anywhere. With 50% schema coverage, the description needed to compensate for the undocumented parameter, and it does not. It also does not clarify that both parameters are optional.

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 action ('Busca una persona por nombre') and a concrete result ('devuelve sus cargos vigentes e históricos, con las empresas vinculadas'). This clearly differentiates it from sibling tools, all of which are company-focused, while this one is person-focused.

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 provides clear context: use it when searching a person by name to obtain current and historical positions and linked companies. It stops short of explicitly naming alternatives or stating when not to use it, but the sibling set and person-vs-company distinction make the use case evident.

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?

The readOnlyHint annotation already signals a safe read operation, lowering the burden on the description. The description adds useful context about the official data source (PLACSP) and the nature of the returned data, but does not disclose pagination behavior, ordering, or any other operational traits beyond what annotations and schema already imply.

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 a single, focused sentence that front-loads the core purpose and includes the source and output fields without unnecessary words. Every part contributes to understanding the tool.

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 an output schema present and readOnlyHint annotation, the description does not need to explain return values or safety. It clearly identifies the source and content, though it omits pagination details. The cursor parameter is at least partially described in the schema, so the overall picture is adequately complete for a read-only list tool.

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 only 33%, covering only 'cursor'. The description does not explain the required 'empresa_id' parameter or the meaning of 'limit', relying entirely on the parameter names and schema metadata. Since the schema is mostly undocumented, the description should have compensated but does not.

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 clearly states the tool's function: public contracts awarded to a company, with an official source (PLACSP). It enumerates the specific data returned (órgano de contratación, expediente, importe, fecha, link), making it easy to distinguish from sibling tools like subvenciones_empresa or cuentas_anuales.

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 for when to use this tool: when you need public contract awards for a company. It does not explicitly exclude alternatives or name sibling tools, but the domain is specific enough that an agent can infer when it applies, especially alongside sibling names.

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 carry readOnlyHint=true, so the safety profile is covered. The description adds a genuine behavioral trait beyond the annotation: for on-demand purchase requests the tool will honestly respond that the capability is unavailable rather than fabricate a result — useful anti-hallucination guidance. It is consistent with the read-only annotation, so no contradiction.

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 core purpose is one short sentence and the note adds one more, which is appropriately compact for a two-parameter read tool. However, the note contains roadmap jargon ('Fase 2') that belongs in release notes rather than a tool definition, and its meaning is ambiguous — the sentence is confusing, not merely concise.

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?

This is a simple 2-parameter read-only tool with an output schema and a clear resource, so the description is close to sufficient. It is adequate but leaves unspecified what the returned annual accounts contain (e.g., balance sheet, income statement) and provides no context on data coverage; the odd note wastes a sentence that could have carried that information.

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 only 50% (ejercicio has a format example; empresa_id has no description), and the tool description does not compensate. It merely re-states that the tool involves a company and a fiscal year, which just echoes the parameter names, adding no format, source, or meaning for either parameter.

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 clearly identifies the resource — annual accounts of a company for a fiscal year — which is distinct from all seven siblings (BORME acts, contracts, risk, subsidies, etc.), so an agent can select it correctly. It lacks an explicit verb (it is a noun phrase, not 'retrieves/gives'), and the appended roadmap note slightly muddies the core purpose sentence.

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?

No guidance is given on when to use this tool versus alternatives: no siblings are referenced and no conditions or exclusions are stated. The Phase 2 note hints at an unavailability for on-demand purchase but does nothing to help an agent choose between this and asientouno_informe_completo or asientouno_riesgo_empresa.

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?

With readOnlyHint already set, the description adds useful behavioral context beyond the annotation: in the free plan, names of natural persons will be partially hidden. This is a concrete caveat an agent needs to interpret results correctly.

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 one substantive sentence plus one short caveat. It front-loads the resource and its contents, and every sentence earns its place.

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 a single fully documented required parameter, an output schema present, and a read-only annotation, the description provides everything an agent needs to select and invoke the tool correctly. The free-plan caveat adds useful extra context.

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 empresa_id parameter is already well documented in the schema, including its provenance from asientouno_buscar_empresa. The tool description itself adds no parameter-specific semantics, so the baseline score of 3 is appropriate.

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 'Informe completo de una empresa' and enumerates the report contents: datos identificativos, órgano de administración, actos recientes, and señales. This clearly defines a broad company-report resource and distinguishes it from the more specialized sibling tools.

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 clear context for when to use the tool: when a complete company overview is needed across several dimensions. It does not explicitly name sibling alternatives or state when not to use it, so it misses the fully explicit guidance of a 5.

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?

The readOnlyHint annotation already indicates a safe read; the description adds valuable behavioral context by disclosing that the response includes a cobertura field explaining what is NOT covered and warns against inferring absence of risk from absence of signals. This is meaningful beyond the annotation.

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 sentences: the first delivers the core content, the second gives use cases, and the third adds an important caveat. There is no repetition of schema or annotation information and no filler.

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 one simple parameter, an output schema, and a readOnly annotation, the description supplies the essential domain context, return content expectations (date and PDF), usage scenarios, and an important interpretation caveat. Nothing critical appears missing.

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?

With 0% schema coverage, the description carries the burden of explaining the single parameter. It only indirectly anchors empresa_id by saying the tool reports signals 'de una empresa'; it does not describe how the ID is used or where it comes from. For a single obvious integer ID this is adequate but not fully compensating.

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 resource (risk signals published in BORME), enumerates the concrete signal types (concurso de acreedores, disolución, extinción), and mentions the returned date and official PDF. This clearly distinguishes it from siblings such as asientouno_actos_borme, which would cover BORME acts more broadly, and asientouno_cuentas_anuales.

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 explicitly states the intended use cases: due diligence, anti-money-laundering, and credit analysis. It does not name sibling alternatives or exclusions, so it stops short of a full when-to-use vs. when-not-to-use guide, but the context is clear.

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?

The readOnlyHint annotation already covers the safety profile, so no contradiction exists. The description adds provenance and output-field context, but it does not disclose additional behavioral traits such as pagination behavior, result ordering, or any limitations beyond what the schema and output schema already provide.

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 compact and well-structured: the core purpose and data source are front-loaded, followed by a concise list of returned fields and a one-sentence value proposition. Every sentence earns its place; there is no redundant filler.

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 read-only lookup tool with an output schema, the description covers the essential context: source, entity, fields, and official link. The remaining gaps, such as explicit pagination guidance and sibling comparisons, are partially mitigated by the input schema and tool naming.

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 low at 33%, so the description must compensate. It does map the main parameter through 'recibidas por una empresa' and the company context, but it does not explicitly clarify limit's role or pagination semantics. The schema's default/min/max and the cursor description still give enough information for a likely correct invocation.

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 states a specific verb and resource: retrieving public subsidies and aid received by a company from the official BDNS database. It lists the concrete data points included (granting body, instrument, amount, date, official bulletin link) and clearly differentiates the tool from siblings like contracts, annual accounts, or risk data.

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 clear context: this is the tool for official public grant data, and it explicitly notes that traditional mercantile reports do not cross-reference this data. It does not enumerate sibling alternatives or explicit exclusion cases, but the context is strong and actionable for an agent.

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