Spanish Companies Registry gazette (BORME) joined with public grants (BDNS) and public procurement awards (PLACSP) per company, for KYB and due diligence. Every fact links to its official publication. Bearer API key (free: 500 calls/day) via https://asientouno.com/contacto.
Scored across 9 tools
Each tool targets a distinct data source or aspect (BORME acts, public contracts, subsidies, risk signals, corporate group, complete report), so overlap is limited. The main confusion is between asientouno_informe_completo, asientouno_actos_borme, and asientouno_riesgo_empresa, which partially re-aggregate the same underlying signals and could cause misselection.
All tools share the asientouno_ prefix and mostly follow a predictable noun-topic pattern (actos_borme, contratos_empresa, grupo_empresa, riesgo_empresa). The outlier is asientouno_buscar_empresa using a verb instead of a noun, a minor deviation that is still readable.
Nine tools is well-scoped for a company-intelligence server, and each one maps to a distinct data pull (search, acts, officers, contracts, accounts, group, report, risk, subsidies). No redundant or filler tools inflate the set.
The surface covers search, corporate history, officers, group structure, risk, contracts, and subsidies, giving strong lifecycle/due-diligence coverage. The gap is asientouno_cuentas_anuales, which is advertised but explicitly unavailable (Fase 2), creating a known dead end.
Lista los actos del BORME de una empresa, paginados, con enlace al PDF oficial de cada uno (provenance).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | Filtra por tipo de concepto (p.ej. 'nombramientos') | |
| desde | No | Fecha ISO (YYYY-MM-DD); solo actos publicados desde entonces | |
| limit | No | ||
| cursor | No | id de acto desde el que continuar (paginación) | |
| empresa_id | Yes |
| Name | Required | Description |
|---|---|---|
| actos | Yes | |
| siguiente_cursor | Yes |
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.
Busca empresas por nombre o NIF en el registro mercantil español (datos reales del BORME).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Nombre (parcial) o NIF de la empresa |
| Name | Required | Description |
|---|---|---|
| resultados | Yes |
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.
Busca una persona por nombre y devuelve sus cargos vigentes e históricos, con las empresas vinculadas (grafo de relacionadas). En el plan gratuito solo busca sociedades (administradoras, auditoras).
| Name | Required | Description | Default |
|---|---|---|---|
| nombre | No | Nombre completo o parcial de la persona | |
| persona_id | No |
| Name | Required | Description |
|---|---|---|
| aviso | No | Presente en el plan gratuito: qué queda fuera y cómo verlo |
| personas | Yes |
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.
Contratos públicos adjudicados a una empresa (fuente oficial: Plataforma de Contratación del Sector Público, PLACSP): órgano de contratación, expediente, importe y fecha de cada adjudicación, con enlace al detalle oficial.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | id desde el que continuar (paginación) | |
| empresa_id | Yes |
| Name | Required | Description |
|---|---|---|
| resumen | Yes | |
| contratos | Yes | |
| siguiente_cursor | Yes |
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.
Cuentas anuales de una empresa para un ejercicio. Nota: compra bajo demanda es Fase 2 — hoy responde honestamente que no está disponible.
| Name | Required | Description | Default |
|---|---|---|---|
| ejercicio | Yes | Año del ejercicio, p.ej. '2025' | |
| empresa_id | Yes |
| Name | Required | Description |
|---|---|---|
| motivo | Yes | |
| status | Yes |
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.
Grupo de empresas de una sociedad según el BORME: su matriz (la sociedad que es su socio único vigente) y sus filiales (las sociedades de las que ella es socio único vigente), cada relación con la fecha y el PDF oficial que la publicó. La respuesta incluye un campo cobertura: solo detecta socios únicos, no participaciones parciales.
| Name | Required | Description | Default |
|---|---|---|---|
| empresa_id | Yes | id devuelto por asientouno_buscar_empresa |
| Name | Required | Description |
|---|---|---|
| matriz | Yes | su socio único vigente, si es una sociedad |
| filiales | Yes | sociedades de las que es socio único vigente (hasta 100) |
| cobertura | Yes | |
| empresa_id | Yes | |
| denominacion | Yes | |
| total_filiales | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the returned relations carry a publication date and official PDF link, and the `cobertura` field documents a genuine detection limitation (sole shareholders only, not partial stakes). That caveat is exactly the kind of non-obvious trait an agent could otherwise misread as complete ownership data.
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 definition is front-loaded: the resource and its two components come first, the cobertura caveat last. It is dense but every clause carries information (parent, subsidiaries, date, PDF, limitation). The first sentence is somewhat run-on, which keeps it short of a 5.
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 1-param, fully documented schema, an output schema, and readOnly annotations, this description covers purpose, return shape, and the main correctness caveat. The only meaningful gap is the absence of sibling routing (when to pick this over informe_completo or cuentas_anuales), which the description never addresses.
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?
There is a single parameter with 100% schema description coverage, and the schema itself already explains that empresa_id comes from asientouno_buscar_empresa. The description adds no format, range, or source detail for empresa_id, so the baseline 3 for a fully documented single-param schema 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 states a precise verb+resource: it returns the corporate group of a company per the BORME, split into matriz (sole-shareholder parent) and filiales (companies it sole-owns), each with date and official PDF. It also draws an explicit boundary ('solo detecta socios únicos, no participaciones parciales') that separates it from generic company-data siblings like asientouno_informe_completo.
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 explicit when-to-use or when-not-to-use guidance, nor any named alternative among the siblings (informe_completo, contratos_empresa, etc.). The link to asientouno_buscar_empresa for the id lives in the schema, not the description, so routing guidance is only inferable from the resource definition itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Informe completo de una empresa: datos identificativos, órgano de administración vigente, actos recientes y señales (concurso, disolución). En el plan gratuito, los nombres de personas físicas van parcialmente ocultos.
| Name | Required | Description | Default |
|---|---|---|---|
| empresa_id | Yes | id devuelto por asientouno_buscar_empresa (el NIF no siempre está disponible en datos BORME) |
| Name | Required | Description |
|---|---|---|
| empresa | Yes | |
| senales | Yes | |
| actos_recientes | Yes | |
| otros_cargos_vigentes | Yes | |
| organo_administracion_vigente | Yes |
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.
Señales de riesgo de una empresa publicadas en el BORME: concurso de acreedores (declaración y conclusión), otras situaciones concursales, disolución y extinción, con la fecha y el PDF oficial de cada una, más el historial concursal de los edictos del BOE (liquidación, convenio, calificación…) en concursos_boe. Pensado para diligencia debida, prevención de blanqueo y análisis de crédito. La respuesta incluye un campo cobertura que explica qué NO cubre — no asumir ausencia de riesgo por ausencia de señales.
| Name | Required | Description | Default |
|---|---|---|---|
| empresa_id | Yes |
| Name | Required | Description |
|---|---|---|
| señales | Yes | |
| cobertura | Yes | Qué cubre y qué no esta respuesta |
| empresa_id | Yes | |
| denominacion | Yes | |
| concursos_boe | Yes | |
| estado_registral | Yes | activa | concurso | disuelta | extinguida |
| tiene_señales_de_riesgo | Yes |
Subvenciones y ayudas públicas recibidas por una empresa (fuente oficial: Base de Datos Nacional de Subvenciones, BDNS): organismo concedente, instrumento, importe y fecha de cada concesión, con enlace al boletín oficial. Dato que los informes mercantiles tradicionales no cruzan.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | id desde el que continuar (paginación) | |
| empresa_id | Yes |
| Name | Required | Description |
|---|---|---|
| resumen | Yes | |
| concesiones | Yes | |
| siguiente_cursor | Yes |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
asientouno_grupo_empresaasientouno_riesgo_empresa2 fields changedOutput schema / properties / concursos_boeAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cruce": {
+ "description": "nif | denominacion: cómo se asoció el edicto a la empresa",
+ "type": "string"
+ },
+ "fecha_publicacion": {
+ "type": "string"
+ },
+ "juzgado": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "procedimiento": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tipo": {
+ "description": "declaracion | liquidacion | convenio | conclusion | reapertura | calificacion | informe | subasta | otros",
+ "type": "string"
+ },
+ "url_oficial": {
+ "description": "edicto en el BOE",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tipo",
+ "fecha_publicacion",
+ "juzgado",
+ "procedimiento",
+ "cruce",
+ "url_oficial"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "empresa_id",
- "denominacion",
- "estado_registral",
- "tiene_señales_de_riesgo",
- "señales",
- "cobertura"
-]New value: +[
+ "empresa_id",
+ "denominacion",
+ "estado_registral",
+ "tiene_señales_de_riesgo",
+ "señales",
+ "concursos_boe",
+ "cobertura"
+]asientouno_cargos_persona1 field changedOutput schema / properties / avisoAdded value: +{
+ "description": "Presente en el plan gratuito: qué queda fuera y cómo verlo",
+ "type": "string"
+}asientouno_actos_bormeasientouno_buscar_empresaasientouno_cargos_personaasientouno_contratos_empresaasientouno_cuentas_anualesasientouno_informe_completoasientouno_riesgo_empresaasientouno_subvenciones_empresa
Add one secure layer between your agents and this server.