Asiento Uno — Registro Mercantil de España

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 annotations already declare readOnlyHint=true, covering the safety profile. The description adds scope information ('por nombre', 'cargos vigentes e históricos', 'grafo de relacionadas') which is useful but does not disclose other behavioral traits such as required permissions, rate limits, or whether the graph is computed on demand. With annotations handling safety, this is adequate but not exceptional.

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, tightly written sentence that front-loads the main action and result. Every phrase is informative: search by name, return current/historical positions, and linked companies graph. There is no redundant or filler content.

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 are documented. However, the description does not explain how persona_id relates to the search or when to use it, and it lacks guidance on input combinations. For a tool with two optional parameters, this leaves some ambiguity about invocation patterns.

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 50% (nombre has a description, persona_id has none), and the tool description adds no parameter semantics beyond the schema. It never mentions persona_id as an alternative lookup key or clarifies its role. The description fails to compensate for the missing persona_id documentation.

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 action ('Busca una persona por nombre') and a precise result ('devuelve sus cargos vigentes e históricos, con las empresas vinculadas'). This clearly distinguishes the tool from siblings like asientouno_buscar_empresa or asientouno_contratos_empresa by focusing on a person's roles and related companies.

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 implies the tool is for searching a person and retrieving their positions, but it does not explicitly state when to use it over alternatives or provide any exclusions. Sibling tools are listed in context but never referenced in the description, leaving usage guidance 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?

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?

Annotations already declare readOnlyHint=true, so the description is not required to restate safety. It adds useful content-level context (that the report surfaces 'señales' like bankruptcy and dissolution), but it does not disclose other behavioral traits such as output size, latency, or any aggregation behavior beyond the listed contents.

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 compact sentence that leads with the core purpose and then lists the report contents with a colon. Every element earns its place, and there is no redundant or filler wording.

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 aggregator tool with a single well-documented parameter and an output schema present, the description is largely sufficient. It leaves the exact response structure to the output schema and only lightly implies the tool's relationship to sibling tools, which is a minor completeness 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%: the single parameter is clearly documented as the id returned by asientouno_buscar_empresa, with the caveat that the NIF is not always available. The tool description itself adds no additional parameter meaning, so the baseline of 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?

The description states a clear resource ('informe completo de una empresa') and enumerates the specific content areas: identifying data, current board, recent acts, and signals such as bankruptcy or dissolution. It is distinguishable from the narrower sibling tools by its 'complete report' framing, though it could more explicitly contrast 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?

The parameter description provides useful context: the empresa_id comes from asientouno_buscar_empresa, implying a search-then-report flow. However, the main description does not explicitly state when to choose this tool over the specific sibling tools, nor when not to use it.

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.