Conversor IAE-CNAE

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

Annotations already indicate readOnlyHint=true, so the description adds minimal behavioral context. It includes 'Sin clave' (no key), hinting at authentication requirements, but does not elaborate on other behaviors.

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 extremely concise with two sentences, no wasted words, and directly states the core purpose.

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?

Despite having 4 parameters and no output schema, the description fails to explain parameters, return values, or usage details, making it incomplete for effective tool selection and 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 0%, and the tool description provides no explanation of parameters (q, type, top_k, threshold). The agent gains no additional meaning beyond the raw 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?

The description clearly states the tool searches for IAE/CNAE codes by description using semantic search, which is specific and distinct from sibling tools that retrieve details by code.

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 provided on when to use this tool versus alternatives like detalle_cnae or detalle_iae. The description only explains what it does, not usage context.

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 indicate readOnlyHint=true, so the tool is read-only. The description adds 'Sin clave' (without key), implying no authentication is needed, but this is vague. No behavioral traits beyond what annotations provide are disclosed. No contradiction with 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?

The description is a single, front-loaded sentence. It is concise with no wasted words. However, it is so brief that some necessary information is omitted, making it less effective than a slightly longer but more complete description.

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 tool's simplicity (2 params, no nested objects, no output schema) and the presence of sibling tools, the description is minimally complete. It names the output 'Modelos AEAT y próximos plazos' but lacks details on format, pagination, or error cases. The agent may need to infer the response structure.

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 schema description coverage at 0%, the description must compensate. It mentions 'código IAE/CNAE', hinting that the 'code' parameter is such a code, and implies 'code_type' exists via the mention of 'IAE/CNAE'. However, it does not explain the default value, the pattern, or the optional nature. The agent may struggle to construct valid input.

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 it provides AEAT models and upcoming deadlines for a given IAE/CNAE code. It identifies the resource (calendario fiscal) and the action (retrieve deadlines). However, it does not differentiate it from sibling tools like 'obligaciones_fiscales', which may overlap.

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. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred. 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 provide readOnlyHint=true. The description adds the batch size limit ('Hasta 50 fichas') and authentication requirement, enhancing transparency without contradicting 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?

Two sentences, front-loaded with the core function, no redundant words. Every sentence provides critical 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?

Given the low complexity (2 simple params, no output schema), the description covers purpose, constraints, and auth. It is missing explicit mention of return format or error handling, but these are not critical for basic usage.

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 description coverage, the description should compensate, but it only hints at the 'type' parameter ('IAE o CNAE') and does not explain the 'codes' parameter beyond its existence. The schema provides the structure, but the description adds minimal meaning.

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 it performs a batch query of up to 50 IAE or CNAE records in one call. This distinguishes it from sibling tools like 'detalle_iae' and 'detalle_cnae' which handle single records.

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 specifies the requirement of a payment key ('Solo con clave de pago') and the batch limit, implying it's for bulk queries. However, it does not explicitly state when to use this tool versus individual lookup tools.

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 description adds useful behavioral context beyond the readOnlyHint annotation: it specifies the calculation method (suma marginal de tramos), that it does not include autonomous scale or minimums, and the authentication requirement. No contradiction with 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?

The description is very concise with three sentences. The first sentence delivers the core purpose, the second adds key exclusions, and the third provides authentication requirement. No superfluous 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?

For a simple calculator tool with 3 parameters and no output schema, the description covers the main function, exclusions, and auth. However, it lacks explanation of the 'escala' parameter and default year range, which limits completeness for a new user.

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 has 0% description coverage. The description only implicitly references 'base liquidable' for the 'base' parameter but does not explain 'anio' or 'escala' (e.g., what 'general' vs 'ahorro' means). Given the low coverage, more parameter explanation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates the 'cuota íntegra ESTATAL del IRPF' using marginal sum of brackets from a taxable base. It specifies an exact verb and resource and distinguishes from siblings by mentioning exclusions of 'escala autonómica' and 'mínimos'.

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 about when to use (with Authorization header) and what is excluded (autonomous scale and minimums), implying when not to use for full IRPF. However, it does not explicitly mention alternative sibling tools like 'escala_irpf' or 'modulos_irpf_iva' for those cases.

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 provide readOnlyHint. Description adds auth key constraint but no details on effects of missing keys or rate limits.

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 covering purpose and auth requirement with no fluff.

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?

Covers purpose and auth constraint. Missing output format details, but sufficient for a simple calculator 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?

0% schema description coverage; description only mentions 'neto' implicitly. Does not explain 'anio' or 'tabla' options or their defaults.

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?

Clearly states it calculates the bracket and minimum estimated quota for self-employed (RETA) based on net income. Distinct from siblings which cover tax codes and calendars.

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?

Specifies auth requirement but no explicit when-to-use vs alternatives. Context is clear but lacks exclusions or comparison.

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 indicate readOnlyHint=true. The description adds that no key is required and mentions data freshness, providing useful context beyond 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?

The description is a single sentence with no wasted words. It is front-loaded with the core purpose.

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 zero parameters, no output schema, and a simple self-descriptive purpose, the description fully covers what the tool does and what it returns.

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 are no parameters (schema coverage 100% trivial). The description explains the tool's purpose, which serves as sufficient semantic context for an inputless 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?

The description clearly states it is a self-description of the service covering catalogs, RPCs, and data freshness. This distinguishes it from sibling tools focused on specific tax/code lookups.

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 (get metadata about the service), but there is no explicit guidance on when to use this vs alternatives or conditions like authentication.

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 description adds little beyond the annotation readOnlyHint=true. The phrase 'sin clave' is ambiguous and does not significantly clarify behavior. No additional constraints or side effects are 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, well-structured sentence that front-loads the key purpose without any wasted words.

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 low complexity (1 param, no output schema), the description provides basic context but lacks detail on the return structure or what 'complete file' entails. It is sufficient for a simple lookup but not fully comprehensive.

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 the description only mentions the code concept without elaborating on format or meaning beyond the schema's pattern. This does not adequately compensate for the missing schema descriptions.

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 provides a complete file for a CNAE 2025 code and its associated IAE, distinguishing it from sibling tools like detalle_cnae_2009 and detalle_iae.

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?

Although not explicitly stating when to use, the title and description imply it is for CNAE 2025 codes, and the sibling names provide implicit usage context. No exclusions are given.

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 adding the mapping context is adequate. No mention of other behaviors, but nothing contradictory.

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 sentence with no wasted words. It could add minor details without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain what the return value includes (e.g., description, correspondence). It only says 'Ficha' (file), leaving the agent unsure of the response structure.

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%, but the description clarifies that the 'code' parameter is a CNAE 2009 code. However, additional details like format beyond the regex pattern are not provided.

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 it provides details of an obsolete CNAE 2009 code and its correspondence to CNAE 2025. It distinguishes itself from the sibling 'detalle_cnae' which presumably handles current codes.

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 indication that the code is 'obsoleto' implies use for legacy codes, but no explicit guidance on when to use this tool versus siblings like 'detalle_cnae' or 'buscar_codigo' is given.

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 indicate readOnlyHint=true, so safety is clear. Description adds that no key is needed ('Sin clave') and qualified codes disambiguate sections, providing useful behavioral context beyond 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?

Two concise sentences front-loaded with the core purpose. No redundant words, each phrase adds value (purpose, caveat, input example).

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 one-parameter lookup without output schema, the description covers purpose, input format, and a key caveat. Minor gaps: no mention of error behavior or response structure, but sufficient for typical use.

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 description coverage, the description fully compensates by explaining the 'code' parameter: it accepts a qualified code (e.g., B831) for disambiguation, adding crucial meaning missing from 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?

The description clearly states it returns a complete record of an IAE heading and associated CNAE codes ('Ficha completa de un epígrafe IAE y sus CNAE asociados'). It distinguishes from siblings like 'detalle_cnae' by specifying IAE focus and mentions disambiguation for qualified codes.

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 usage by mentioning qualified code input but lacks explicit guidance on when to use this tool vs alternatives. No when-not or alternative tool names are provided.

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 benefits from that baseline. The description adds 'public data' and 'sin clave', clarifying no authentication is needed, which is useful context. However, it does not describe potential rate limits or data freshness, which is acceptable for a simple data retrieval tool.

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 sentence that front-loads the key information: what data is returned, the year, and the type of scale. It is concise with no wasted words. However, it could be slightly more structured to improve readability for an agent.

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 tool's simplicity (2 optional parameters, no output schema, read-only), the description covers the core function. However, it does not describe the return format or structure of the data, which would be helpful since there is no output schema. The description is minimally complete but could be more informative.

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?

Input schema has 0% description coverage for parameters, so the description must compensate. The description mentions 'año 2026' and 'general o ahorro', which partially maps to the two parameters (anio and escala). However, it does not explain the meaning of the parameters beyond their names and enum values, which are somewhat self-explanatory but not fully disambiguated for an AI agent unfamiliar with Spanish tax terminology.

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 returns brackets of the state IRPF scale for general or savings income for the year 2026. It specifies 'public data' and 'no key needed', making the scope clear. However, it does not explicitly differentiate from sibling tools like 'cuota_irpf' or 'gastos_deducibles'.

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 tool versus alternatives such as 'cuota_irpf' or 'calendario_fiscal'. The description implies use for retrieving tax brackets but does not provide context on prerequisites, other tools covering related concepts, or 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?

Beyond the readOnlyHint annotation, the description adds that the data is public and requires no API key. This is valuable behavioral context. However, it omits pagination, rate limits, 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?

The description is a single, front-loaded sentence with no filler. Every word adds value, efficiently conveying purpose, scope, and access constraints.

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 tool with no required fields and no output schema, the description covers the essential inputs and access model. However, it lacks any indication of the output format (e.g., list of items, total amounts), leaving some ambiguity for the agent.

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 description explains 'todos o por categoría', which directly maps to the 'categoria' parameter. However, the 'anio' parameter is not explicitly discussed; its purpose is only implied by IRPF context. With 0% schema coverage, this partial compensation is adequate.

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 returns deductible expenses for self-employed IRPF, either all or by category, and notes it's public data without authentication. This verb and resource combination is unambiguous.

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 context (public data, no key) but does not explicitly compare to sibling tools like 'cuota_irpf' or 'modulos_irpf_iva'. An agent can infer usage from the 'deducibles' keyword, but no when-not guidance is given.

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 description states it requires a payment key (Bearer cvr_…), which is a behavioral trait. The annotation 'readOnlyHint: true' aligns with the read nature. However, it does not disclose what happens on invalid codes or rate limits.

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 two sentences, front-loaded with the core purpose, and every sentence is informative. 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 simple lookup tool with 2 parameters and no output schema, the description covers the main purpose, the disambiguation feature, and auth requirement. It is fairly complete but could mention expected response structure.

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 carries the burden. It explains the 'slug' parameter (optional disambiguation) but does not add meaning to the required 'code' parameter beyond its pattern.

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 it retrieves the objetiva estimation regime (módulos) for an IAE activity. It mentions the optional slug for disambiguation. However, it does not explicitly differentiate from siblings like 'detalle_iae', which might also provide details on an IAE.

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 only notes authentication requirements (payment key). It provides no guidance on when to use this tool versus sibling tools (e.g., 'detalle_iae', 'consulta_masiva') or 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?

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds an important behavioral detail: the necessity of a payment key (Authorization header). No further disclosure of traits like error handling or response structure is provided.

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 sentence with no wasted words, effectively front-loading the core purpose and a key requirement. However, it lacks structure and could benefit from a brief mention of parameters.

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 simple input schema and presence of annotations, the description covers the main purpose and authorization requirement. It lists some output attributes, providing partial completeness. However, it omits parameter details and error handling, leaving minor gaps.

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 the description does not elaborate on the two parameters. It mentions 'código' generically but does not explain 'code' format or 'code_type' enum values. The description adds minimal semantic value 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?

The description clearly states that the tool returns 'Modelos AEAT' applicable to a code, listing specific attributes (confianza, motivo, periodicidad, plazo). This distinguishes it from siblings like buscar_codigo (which searches codes) or calendario_fiscal (fiscal calendar).

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 mentions a payment key requirement ('Solo con clave de pago'), but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. It implies a usage scenario but lacks exclusions or comparisons to sibling tools.

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