Conversor IAE-CNAE

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lowered. The description adds genuinely new operational context: no API key is required ('Sin clave') and results carry a canonical page URL. It does not discuss rate limits, result quality, or how the semantic match is scored, but for a read-only search this is solid.

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 sentences with the core capability front-loaded and the return-value note following. Nothing is padded, though the parenthetical '(búsqueda semántica)' and the '(url)' gloss are slightly redundant.

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 usefully names one return field ('url'), but it omits the remaining result fields and leaves three of four input parameters undocumented. For a 4-parameter search tool with zero schema coverage, this is not enough for an agent to invoke it confidently across the type/top_k/threshold options.

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 0% and there are 4 parameters, so the description carries the full burden but only obliquely covers 'q' via 'por descripción'. The enum values for 'type' (iae, cnae, cnae_2009, modelos, all), plus 'top_k' and 'threshold', are never explained, leaving the agent to guess what 'modelos' or 'all' mean or how threshold affects results.

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 and resource ('Busca códigos IAE/CNAE por descripción') and identifies the retrieval mode as semantic, which is meaningfully different from exact-code lookup tools. It does not name siblings such as detalle_iae, detalle_cnae or empresas_por_actividad, so the agent must infer the boundary itself.

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 phrase 'por descripción (búsqueda semántica)' implies the tool is for fuzzy/natural-language discovery rather than exact code lookup, which is a usable usage signal. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling code tools, so routing remains partially inferred.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two genuinely useful non-schema facts: 'Sin clave' (no API key required) and the returned fields ('número, asunto, criterio y enlace'), but it says nothing about result volume, pagination, or ranking.

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 tight sentences: the first front-loads the verb, resource, and query scope, the second carries auth and output facts. No filler or repetition.

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 usefully enumerates the returned fields and confirms no key is needed, which is adequate for a read-only search tool. However, it omits `limit` semantics and any notion of result count or pagination, leaving the definition slightly under-specified for a two-parameter 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 coverage is 0%, so the description must carry the parameter burden. 'por tema o texto' partially explains that `query` accepts either a topic or free text, but the `limit` parameter (1–20) is never mentioned and there are no format or length hints, leaving real gaps.

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 ('Busca') and a precise resource ('resoluciones y criterios del Tribunal Económico-Administrativo Central (TEAC)'), plus topical scope examples (IVA, IRPF, sociedades, procedimiento). This clearly separates it from siblings like consulta_dgt or texto_normativa, though it never names an alternative explicitly.

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 says what can be searched but gives no when-to-use guidance, no exclusions, and never routes the agent toward or away from sibling tools such as consulta_dgt (DGT criteria) or buscar_codigo. Usage is only inferable from the topical examples.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. 'Sin clave' adds genuine value beyond the schema by signalling no API key/auth is needed. However, nothing is said about the time horizon of 'próximos plazos', result shape, or pagination.

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 clauses with no filler and the subject front-loaded. It is close to under-specification rather than exemplary conciseness, but no sentence is wasted.

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 burden of explaining what comes back, and it does not: the meaning of 'Modelos' and the horizon of 'próximos plazos' are undefined. For a data-returning lookup tool, an agent lacks enough to predict or use the response.

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 0% for two parameters, so the description must compensate. It does so partially by tying the input to an IAE/CNAE code, which clarifies the meaning of the enum in code_type. It says nothing about the required format of 'code' (the schema allows digits and dots), leaving a real gap.

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 the resource precisely: 'Modelos AEAT y próximos plazos' (AEAT forms and upcoming deadlines) scoped to a given IAE/CNAE code. An agent can distinguish it from siblings like detalle_iae or detalle_cnae, which return code details rather than tax deadlines. The verb is only implicit (a lookup), so it stops short of a 5.

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 instead of alternatives such as obligaciones_fiscales or buscar_codigo. The only usage-adjacent hint is 'Sin clave', which speaks to authentication, not tool selection.

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/non-destructive/closed-world, and the description adds real context beyond them: free-vs-paid result scope, Spanish stemming/accent handling, 'Sin clave' (no API key required), and a content constraint (public doctrine only, no personal data). It stops short of error/pagination behavior, so not a 5.

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?

Front-loads the core action, then uses short colon-delimited clauses for tier behavior, constraints, and auth. Dense and mostly waste-free, though the tier split and constraint clauses could be marginally tightened.

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 2-parameter tool with no output schema and covering annotations, it supplies the missing pieces: what each tier returns, that no API key is needed, and what data is excluded. Return shape is described in terms of tier rather than structure, which is adequate but leaves some ambiguity on the paid response.

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%, so the baseline is 3, but the description adds meaning beyond the schema: the query is matched with stemming and accent normalization, and the IAE code filter is gated to the paid plan. These details explain how parameters actually behave, which the schema descriptions do 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?

States a specific verb (Busca) and resource (consultas vinculantes de la DGT) plus the search modality (texto libre en español). Naming the DGT source implicitly distinguishes it from the sibling buscar_doctrina_teac, so an agent can route correctly without opening either 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?

Explains the tiered behavior (free = summary of the most relevant consultation; paid = full list plus IAE filter), which is useful usage context. However, it never states when to prefer this over alternatives such as buscar_doctrina_teac or texto_normativa, so selection guidance is only implied.

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 cover the read-only/no-destruction profile, and the description adds genuinely behavioral context beyond them: the 50-item batch ceiling and the entitlement requirement (paid plan). It still says nothing about failure modes or how codes are validated, keeping it short of a 5.

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 capability and follow-up with the gating constraint. No wasted words; every clause carries 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?

There is no output schema, and the annotations only cover safety, so the description should carry more weight. It is missing code-format guidance, enum value clarification, and any hint of the response shape or error behavior for a 2-required-parameter 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 0%, so the description must compensate. 'IAE o CNAE' maps loosely to the `type` enum and the '50 fichas' phrasing mirrors maxItems, but the `codes` array format (dotted numeric pattern) and accepted enum values are never explained. It partially bridges the gap.

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 clear verb+resource: a bulk/batch lookup of up to 50 IAE or CNAE fichas in a single call. This is reasonably distinguishable from single-record siblings like detalle_iae and detalle_cnae, but the description never names those alternatives, so differentiation is left to inference.

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?

Communicates one real prerequisite ('Requiere un plan de pago') and implies batch usage via the 50-record cap, but gives no explicit when-to-use vs consulta single-record siblings or buscar_codigo. Usage context is implied rather than stated.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context (statutory public-data basis, no API key, excluded components) but says nothing about rounding, year coverage of the bracket tables, or result format.

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 short front-loaded sentences with no filler; scope and exclusions come before the access note. 'Datos públicos. Sin clave.' could arguably be trimmed but is cheap and useful for authentication expectations.

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?

No output schema and no annotations on the calculation contract, so the description should at minimum explain the 'escala' enum (general vs savings income) and that 'anio' selects the bracket set. With 3 params and 0% schema coverage, the current text is adequate but leaves key inputs ambiguous.

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 0%, but the description partially compensates by fixing the meaning of the required 'base' as the taxable base ('base liquidable'). 'anio' (default 2026) and the 'general' vs 'ahorro' enum values are left completely undocumented in both schema and description.

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 (Calcula) and resource (cuota íntegra ESTATAL del IRPF) and precisely limits scope: sum of marginal brackets, excludes regional scale and personal minimums. Clearly distinguishable from sibling escala_irpf (which likely returns the bracket table, not the tax amount).

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?

Implies usage ('a partir de una base liquidable') and states exclusions ('No incluye escala autonómica ni mínimos'), which steers away from total-IRPF expectations, but never explicitly says when to use it versus escala_irpf or cuota_reta.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond them by disclosing that no API key is required ('Sin clave') and that the source data is public, which is exactly the kind of auth context the annotations do not carry.

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 short sentences with no padding, front-loading the computation and its inputs before the data/auth notes. Efficient, though the trailing 'Datos públicos. Sin clave.' fragments could be merged.

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's mention of the two outputs (tramo and cuota mínima estimada) is genuinely helpful. However, for a calculation tool with a 'tabla' variant selector and a year parameter, the definition omits what distinguishes the tabla options and how the year affects results.

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 0% across 3 parameters, so the description must compensate and largely does not. It indirectly references the required 'neto' input ('por rendimiento neto') but never explains the 'tabla' enum (general vs reducida) or the 'anio' default of 2026, leaving two of three parameters undocumented anywhere.

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+resource: calcular el tramo y la cuota mínima of autónomos RETA based on rendimiento neto. Naming 'autónomos (RETA)' naturally separates it from cuota_irpf and escala_irpf, though no sibling is named explicitly, so it stops short of a 5.

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?

'Datos públicos. Sin clave.' implies an open, unauthenticated calculation context, but there is no explicit statement of when to choose this over cuota_irpf or escala_irpf, nor any exclusion or precondition. Usage is only implied.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral detail beyond them: 'Sin clave' tells the agent no API key/credential is required to call it, which is real auth context.

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 short sentence with no padding, and the subject (the service self-description) is front-loaded before the enumerated contents. It is terse to the point of being a fragment, but nothing is wasted.

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 zero-parameter discovery tool with no output schema, the description says enough: it is the service's own description covering catalogs, RPCs, and data freshness, and it needs no credentials. Only the absence of any routing/usage cue 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?

The tool takes zero parameters (schema coverage 100%, empty object), so there is nothing for the description to disambiguate. Baseline 4 applies for a no-param tool.

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 meta-resource (the service itself) and enumerates what the self-description covers: catalogs, RPCs, and data freshness. It is a noun-phrase fragment rather than a verb+resource statement, but an agent can tell what it returns and no sibling overlaps with this discovery role.

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?

Implicit usage only: an agent can infer you call this to learn the service's capabilities and data freshness. There is no explicit when-to-use/when-not guidance and no routing to any alternative among the 18 fiscal siblings, so the guidance stays at the implied level.

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, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond that: no API key is required, and AI-enriched fields (ai_summary, fiscal_signals) need a paid plan. This goes beyond the safety profile and is useful for an agent deciding on auth or feature availability.

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?

Front-loads the returned fields and then adds two short, high-value sentences about access and pricing. Slightly dense in the first sentence but no wasted words; appropriately sized for a simple lookup.

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 read-only lookup with no output schema, the description usefully enumerates return fields and clarifies access/pricing. Missing details on code format and error behavior are minor gaps, but the definition is nearly complete for its complexity.

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 0%, so the description must compensate. It only says 'un código CNAE 2025', which identifies the code family but does not describe the expected format, punctuation, or provide examples. The schema pattern hints at digits and dots, but the description adds little semantic meaning beyond the type name.

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 the resource clearly: a record for a CNAE 2025 code, listing the fields returned and distinguishing it from the 2009 sibling via 'CNAE 2025'. The verb is implied ('Ficha de') rather than explicit, but an agent can tell what it retrieves and how it differs from detalle_cnae_2009.

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 explicit guidance on when to use this versus buscar_codigo, detalle_cnae_2009, or other siblings. It mentions access conditions ('Sin clave') and paid AI features, but these are behavioral notes, not usage 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?

Annotations already cover safety (readOnly, non-destructive, closed-world). The description adds real behavioral context beyond them: what the response contains, that no API key is needed ('Sin clave'), and that AI fields (ai_summary, fiscal_signals) are gated behind a paid plan. This gating/auth detail is exactly the kind of extra context that earns credit over annotations.

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?

Compact and front-loaded: what it returns, the URL, then the auth and premium caveats. Slightly dense with parentheticals but no wasted sentences.

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 usefully enumerates the return fields and mentions the paid-plan gating, which is enough for an agent to call a single-param read tool correctly. Only the input code format is left unaddressed.

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 0% for the single 'code' parameter, so the description carries the full burden — and it does not compensate. It implies the input is a CNAE 2009 code but gives no format, example, or separator guidance (the schema only shows a generic pattern ^[\d.]+$).

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 verb+resource: it returns a 'ficha' (record) for a CNAE 2009 code, enumerating the fields returned (título, descripción, correspondencia a CNAE 2025, URL). Tagging it '(obsoleto)' implicitly distinguishes it from the sibling detalle_cnae, though no explicit routing statement is given.

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 '(obsoleto)' marker signals this tool is for legacy 2009 codes, but the description never states when to prefer it over detalle_cnae (the current-version sibling) or names any alternative. No when-not 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 cover readOnly/openWorld/destructive, but the description adds real behavioral context beyond them: no API key required for base data, and AI enrichment fields (ai_summary, fiscal_signals) are gated behind a paid plan. That tiering is exactly what an agent needs to interpret partial results, though reversibility/rate-limit detail is absent (mostly irrelevant for a read).

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?

Front-loaded with the returned payload, then short sentences for key requirement, paid-plan gating, and parameter format. Dense but every clause carries information; 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?

For a single-record lookup with no output schema and full annotation coverage, the description tells the agent what fields come back, that no key is needed, that some fields are paywalled, and how to format the code. Little is missing that the structured fields don't already supply.

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 0%, so the description must compensate for the single 'code' parameter. It does: gives an example value ('B831'), explains the qualified-code format, and states the reason for it (disambiguating epígrafes with several sections). Meaningfully more than the bare pattern in 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 resource (IAE epígrafe record) and enumerates its contents: título, descripción, elegibilidad de módulos, correspondencia IAE↔CNAE 2025, url. An agent knows it returns a single record's detail. It never names a sibling (e.g. detalle_cnae) as a contrast, so it stops short of full cross-tool differentiation.

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 by the resource: fetch one IAE epígrafe's detail. The disambiguation hint ('Acepta un código cualificado... para desambiguar epígrafes con varias secciones') gives situational guidance, but there is no explicit when-to-use-this-vs-detalle_cnae/buscar_codigo routing or stated prerequisites.

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?

Adds substantial behavior beyond the annotations: data is company-level under Ley 37/2007 with no personal data, output is truncated to a 3-item sample without a Professional key, and the full listing is paywalled. The annotations only declare read-only/non-destructive/non-open-world; the description supplies the tiering and data-protection context an agent needs.

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 tight sentences, front-loaded with the returned fields before the licensing caveat. The 'sin clave' condition is stated twice (once about keys, once about the 3-item sample), a minor 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?

With no output schema, the description does the necessary work of enumerating the returned statistics (count, average/median capital, monthly trend, provinces) and the access limitations. Nothing an agent needs to call it correctly is 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?

Schema description coverage is 100% and the single parameter is fully documented (CNAE-2025 code, with or without dots). The description only restates that the code must be a CNAE-2025 code, adding no syntax, validation, or example detail beyond the schema, 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?

States a specific verb and resource: returns company-incorporation statistics (count, capital, monthly trend, provinces) for a CNAE-2025 code. Very clear about what it produces, but never names or contrasts itself with closely related siblings such as detalle_cnae or subvenciones_por_actividad, so differentiation is left to inference.

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?

Gives concrete access conditions: no key needed for the statistics, a Professional key is required for the full list of recent incorporations (company names), and without a key a sample of 3 is returned. It stops short of stating when to prefer this tool over its CNAE-related 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context not in the annotations: the data is public and requires no API key ('Datos públicos. Sin clave.'). It says nothing about the shape of the returned brackets, but for a static lookup that gap is minor.

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 short fragments with no padding, and the core identity (what is returned) is front-loaded ahead of the access note. The telegraphic style is efficient, though it borders on under-specification rather than true concision.

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 two-parameter, read-only lookup with no output schema, so the description carries the burden of describing the return value (bracket thresholds and rates) and it does not. The safety and access profile is adequately covered by annotations and the 'sin clave' note, making it minimally viable but thin.

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 0%, so the description must compensate, and it does name both dimensions: the enum values 'general o ahorro' and the year. However, it presents 2026 as fixed ('año 2026') while the schema exposes an 'anio' parameter with a default, leaving it unclear whether other years are valid or how the year affects the result.

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 the specific resource (tramos de la escala IRPF estatal) and its two variants (general/ahorro) plus the year, so an agent knows it returns bracket tables rather than computing a tax amount. It does not, however, explicitly distinguish itself from the closely related sibling cuota_irpf, which an agent could easily 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?

There is no statement of when to use this tool versus alternatives such as cuota_irpf or tarifa_at_ep, nor any prerequisite or exclusion. 'Sin clave' hints at access conditions but gives no invocation guidance. The agent must infer usage from the name alone.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that the data is public and requires no API key, which is real operational context an agent needs before invoking.

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 short fragments, front-loaded with what the tool returns and scoped immediately. Nothing wasted, though the telegraphic style leaves little room for the missing parameter and usage 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?

A simple two-parameter lookup tool, so a brief description is defensible, and no output schema exists to relieve it of explaining returns. However, with zero schema coverage on parameters, the definition leaves an agent guessing about year and category values.

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 0%, so the description carries the full burden for the two parameters. '(todos o por categoría)' vaguely gestures at the categoria filter, but anio, its default, the category vocabulary, and the maxLength=40 constraint are all undocumented in both schema and description.

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 resource (gastos deducibles del IRPF del autónomo) and its scope (todos o por categoría), so an agent can tell it returns deductible-expense data rather than a calculation. Sibling differentiation is only implicit — no explicit contrast with cuota_irpf or escala_irpf — but the resource is concrete.

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 alternatives such as cuota_irpf or obligaciones_fiscales, and no prerequisites or exclusions. 'Datos públicos. Sin clave.' tells the agent it can call freely but not when it should.

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, non-destructive and closed-world, so the safety profile is covered. The description adds two genuinely non-annotation facts – the data is public and no key/credential is required ('Datos públicos. Sin clave.') – but says nothing about response shape, coverage, or failure modes when the code is unknown.

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 short, front-loaded Spanish sentences with no filler; the core purpose leads and the optional-parameter note follows. Nothing is redundant, though it is arguably terse enough to leave gaps.

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 2-parameter, read-only lookup with no output schema and adequate annotations, the description is close to sufficient. It would be stronger if it summarized what the módulos response contains (indexes, limits, activity assignment) so the agent knows what to expect.

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 0%, so the description carries the load. It explains the 'slug' parameter's purpose (disambiguating codes with multiple activities) but offers nothing on 'code' beyond it being an IAE identifier, and does not surface the string pattern constraints in 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/domain: it returns the 'Régimen de estimación objetiva (módulos)' for an IAE code, which is a concrete resource that an agent can distinguish from generic IAE lookups. It stops short of explicitly contrasting itself with nearby siblings like detalle_iae, so it earns a 4 rather than a 5.

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 looking up módulos data for a given IAE/activity code. The description does give a conditional hint for the slug ('para desambiguar códigos con varias actividades'), but never states when to prefer this tool over buscar_codigo or detalle_iae.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by stating "Datos públicos. Sin clave." (public data, no API key needed) and by enumerating the kind of output returned (confianza, motivo, periodicidad, plazo) — genuine auth and payload context.

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 short fragments with no filler, and the core purpose is front-loaded. The parenthetical list of output fields sits a bit awkwardly for a description of an input-driven tool, but nothing is wasted.

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 read-only public tool this covers purpose, output shape and auth adequately, and no output schema exists to carry the return contract. The gaps are the undocumented code_type parameter and the missing distinction from sibling lookup tools, leaving it minimum-viable rather than 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?

Schema description coverage is 0%, so the description must carry the burden and largely does not. It only alludes to "un código" as input and never explains the code_type enum (iae vs cnae), the default, or the numeric/dot pattern constraint. An agent cannot tell from the description what code family it should pass.

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 concrete resource and behavior: returning the AEAT tax forms ("Modelos AEAT") applicable to a given code. An agent can distinguish it from pure lookups like buscar_codigo or detalle_iae in intent. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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 when-to-use guidance and no mention of alternatives, despite a crowded sibling set (detalle_iae, detalle_cnae, buscar_codigo, calendario_fiscal). The agent gets a purpose but no routing rule for choosing this tool over the near-neighbors.

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 a safe read-only, closed-world operation. The description adds real behavioral context beyond them: it returns only a free-tier sample unless a payment plan applies, discloses 'Solo convocatorias públicas, sin datos personales', and notes 'Sin clave' (no API key required).

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?

Dense but front-loaded: the core purpose and return shape come first, then the paid-tier caveat and privacy note. Every clause carries information, though the single run-on sentence with parentheticals is slightly heavy.

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 well, enumerating total open grants, autónomo/PYME counts, and sample fields (título, órgano, ámbito, dotación, enlace oficial). Privacy and access requirements are also covered, leaving nothing essential for correct invocation.

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 in the schema. The description restates that 'code' is a CNAE-2025 and references the 'solo_actividad' filter, but adds no syntax or edge-case detail beyond what the schema provides. Baseline 3.

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 ('Devuelve') and resource ('subvenciones/ayudas públicas ABIERTAS (convocatorias BDNS)') scoped to a CNAE-2025 code. The subject matter clearly separates it from siblings like detalle_cnae or empresas_por_actividad, though it never names them explicitly.

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 by the input (query grants for a CNAE code), and the free-vs-paid split ('Con plan de pago: lista completa') hints at tiering, but there is no explicit when-to-use guidance or routing to alternatives. A note that this is the grant lookup for an activity code would raise 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?

Annotations already declare this a safe, read-only, closed-world lookup, so the bar is lower. The description adds genuinely useful behavior: what the free tier returns (total rate + application note), the autónomo rate of 1.30%, and that IT/IMS breakdown plus source_anchor are gated behind a paid plan.

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 tight sentences with the core purpose front-loaded, followed by free-tier contents and the paywall boundary. No filler, though the parenthetical autónomo note could be trimmed.

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 partially: it names the free outputs and the paid ones. For a single-parameter lookup this is close to complete, missing only error behavior for invalid or unmapped CNAE codes.

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% and the code parameter already documents CNAE-2025 format and accepted dot variants. The description only reaffirms 'actividad CNAE-2025' and adds no syntax, validation, or defaulting 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?

States a specific verb+resource: it returns the AT/EP contribution rate for a CNAE-2025 activity. An agent can distinguish it from detalle_cnae or detalle_iae without opening the schema, though no sibling is named explicitly to sharpen the boundary.

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 use case (look up the AT/EP rate for a CNAE activity) but never states when to use this versus detalle_cnae or other CNAE-related siblings. The free-vs-paid framing reads as product tiering rather than invocation 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 and destructiveHint=false. The description adds useful scope such as 'VIGENTE', 'no histórico', and 'citable como fuente oficial', but the fragment 'Sin clave. Con clave: hechos + texto completo' is ambiguous and may imply keyed access behavior without schema support.

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 is front-loaded and compact, but telegraphic fragments such as 'Sin clave. Con clave: hechos + texto completo.' reduce clarity and do not fully earn their 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?

There is no output schema, so the description carries the return-value burden. It lists returned fields and explains the index-vs-article mode, but leaves the ambiguous 'clave' behavior unclear.

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 the baseline is 3. The description adds meaningful conditional semantics: omitting 'articulo' returns the article index, while providing it returns article content and facts.

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 resource and scope: consolidated and current BOE article text, and explains the mode without 'articulo' returns an index of current articles. It does not explicitly differentiate itself from any sibling tool, so it falls short of a 5.

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?

Explains the key usage distinction between omitting and providing 'articulo', and excludes historical texts with 'Solo texto en vigor (no histórico)'. It gives clear context but does not name alternative tools for historical or other legal research.

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