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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds the human-in-the-loop confirmation requirement and the fact that AFIP assigns numbering and a CAE, which is meaningful context beyond the flags. It never states plainly that each invocation consumes the next sequential number and cannot be undone or retried safely — the single most important behavior for a non-idempotent fiscal write.

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?

Purpose is front-loaded correctly, but the body repeats itself: validation-before-execution is stated in the opening instruction, again as flow step 1, and again in the closing "Atención" paragraph. The "Recomendación clave" about PtoVta duplicates flow step 2 and is also already in the PtoVta schema description. Tightening to purpose + flow + confirmation gate would lose nothing.

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 22-parameter, 14-required, destructive issuance tool with no output schema, the description covers the pre-flight workflow and prerequisite lookups well. It is silent on what the agent receives on success (CAE, voucher number, expiry), on error/failure behavior when AFIP rejects the request, and on how this differs from create_voucher — gaps an agent must resolve before calling.

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 per-field semantics are already documented, which sets the baseline at 3. The description goes beyond that by enumerating the parameter categories that must be validated (concepto, tipo de factura, moneda, punto de venta, importes, fechas, ítems) and mandating that missing data be requested from the user rather than assumed — a cross-cutting constraint the schema does not express.

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 ("Crear el próximo comprobante electrónico en AFIP") plus two distinguishing traits: automatic numbering and CAE assignment, which tell the agent this is a real fiscal issuance, not a draft. However, the sibling list contains create_voucher and the description never explains how this tool differs from it, so the agent cannot disambiguate between the two write paths.

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?

Provides an explicit 5-step pre-execution flow (validate params, resolve PtoVta, present a summary, get explicit confirmation, then create) and a hard gate on user confirmation — far above typical guidance. It stops short of naming alternatives (create_voucher) or stating when NOT to use this tool, so it does not reach 5.

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

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

Annotations already declare this is non-read-only, open-world, non-idempotent, and non-destructive. The description adds useful behavioral context: user confirmation is required before generation, data must not be assumed, and DIRECCION_EMISOR_SELECCIONADA is validated against A13 rather than accepting arbitrary values.

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 front-loaded with purpose and then moves into workflow rules, which is appropriate for a complex 27-parameter tool. It is somewhat verbose and repeats some 'do not assume' guidance already covered in the schema, but most sentences earn their place given the workflow complexity.

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?

The description covers the generation workflow, confirmation requirement, and A13 address validation, which is substantial for a complex create operation. However, with no output schema, it does not explain what the PDF generation returns, such as a file path, URL, or inline binary, leaving an important gap for 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 the baseline is 3, but the description adds meaningful semantics beyond the schema. It explicitly clarifies the distinction between CbteTipo as the AFIP/QR numeric code and CbteLetra as the PDF display letter, and explains that DIRECCION_EMISOR_SELECCIONADA must match an A13-returned eligible address.

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

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

The description states a specific verb and resource: 'Genera un PDF dinámico de un comprobante electrónico' and explains that it combines voucher, emisor, and receptor data from AFIP. This clearly distinguishes it from sibling tools that create or retrieve vouchers rather than render a PDF.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear workflow guidance: gather data with the appropriate tools, do not assume missing information, summarize the invoice for the user, and proceed only after explicit confirmation. It also gives a specific retry path for A13 multiple-address cases, though it does not name create_voucher or another exact sibling as the prerequisite alternative.

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 destructiveHint=true, openWorldHint=true, and idempotentHint=false; the description only adds that a CAE is assigned. It does not warn that this issues a real fiscal document, is non-idempotent, or describe side effects. There is no contradiction, but added behavioral context is minimal.

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 repetition. It is structurally clean, though unusually terse for a complex destructive operation.

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 26-parameter destructive issuance tool with 17 required fields and no output schema, the description omits prerequisites, side effects, return behavior, and sibling routing. The schema carries field-level details, but the description is not complete enough for this 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 100% with detailed per-field descriptions, formulas, defaults, and sibling-tool references. The description itself adds no parameter meaning beyond what the schema already provides, so the baseline 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: 'Crear un comprobante electrónico en AFIP', plus the outcome 'con CAE asignado'. It is clear what the tool does, but it does not distinguish it from the sibling create_next_voucher.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus create_next_voucher or other siblings. Prerequisites and conditions for issuance are left to the schema and agent inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the data originates from AFIP and enumerates representative returned values (0%, 10.5%, 21%, 27%), but says nothing about failure modes, auth, or whether the list changes over time.

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?

A single well-formed sentence with the resource front-loaded and inline examples that earn their place; 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?

With zero parameters, full schema coverage, and annotations covering the read-only/open-world profile, the description supplies enough to call the tool correctly. It is only slightly thin on what the enumeration is used for downstream.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The example values compensate slightly by hinting at the shape of returned strings.

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 ('Obtiene') and a precise resource ('tipos de alícuotas de IVA disponibles en AFIP'), reinforced by concrete example values. It is distinguishable from generic siblings like get_tax_types, though the description never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is used when it needs valid IVA rates for voucher creation, but the description gives no explicit when-to-use condition, prerequisites, or named alternatives among the many sibling type-listing 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, yet the description adds genuinely new behavior: it ALWAYS runs non-blocking regardless of the wait flag, and it discloses the in-process response payload shape ({ id, status: 'in_process' }) versus the completed-result behavior. It does not say how long results are retained or how an agent should poll, which keeps it below 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?

Three short sentences, front-loaded with purpose, then the non-blocking constraint, then the two possible return states. Nothing is redundant with the title and no sentence could be dropped without losing 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?

With no output schema, the description carries the burden of describing returns and does so for the two main branches (in-process vs. finished). It leaves open the polling cadence and whether a completed result remains retrievable, minor gaps for a 2-parameter read tool whose annotations already cover the safety profile.

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 schema baseline is 3, but the description adds relevant meaning by asserting the wait parameter is effectively inert ('SIEMPRE consulta en modo no bloqueante'), which prevents an agent from setting wait=true expecting blocking behavior. The id parameter's provenance is also reinforced in prose.

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 ('Consulta el estado o el resultado final de una automatización') plus the key discriminator: it requires an ID of an already-started automation, sourced from 'mis_comprobantes'. An agent can distinguish this polling tool from the sibling that starts the automation 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?

'previamente iniciada' plus the 'mis_comprobantes' example clearly establishes the precondition for calling this tool and implies the sibling used to launch it. What's missing is an explicit statement of what to do when status is 'in_process' (re-poll vs. stop) and how often to poll.

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 openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful privacy guarantee (certificate, key, identity, issuer, subject and local paths are not exposed) and the 'loaded' cue implying an in-memory certificate, but it does not state what happens when no certificate is loaded or what the status values are.

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?

A single front-loaded sentence with the resource and the verb first and the disclosure clause second. Every clause earns its place; nothing is padded.

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 zero parameters, no output schema and thin annotations, the description carries the burden of explaining the return value, and 'validity status' is not concrete — an agent cannot tell whether it gets a boolean, an enum, or an expiry date, nor how a missing/unloadable certificate is reported.

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, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly introduces no parameter discussion.

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 and resource ('Returns the loaded X.509 certificate validity status'), so an agent knows this reports certificate health rather than reading certificate material. No sibling overlaps in this domain, so differentiation is not required, but the phrase 'validity status' leaves the exact payload shape ambiguous.

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 — an agent can infer it is the pre-flight check before signing/authenticated operations, but the description never says when to call it or what to do on failure. There are no alternatives to route between, which keeps this at minimum-viable rather than poor.

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 openWorldHint=true, so the safety profile is covered. The description adds that the result set is a small fixed AFIP enumeration with exactly three known values, which is genuinely useful context beyond the annotations, but it says nothing about caching, failure modes, or response shape.

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?

A single sentence, front-loaded with the action and resource, then the concrete value set in parentheses. Every clause earns its place and nothing is padded.

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, read-only enumeration with no output schema, the description supplies enough: the domain (AFIP) and the actual values returned. The only gap is that it does not tie the result to where it is consumed (e.g., the concept field of a voucher), which would fully close the loop.

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, so there is nothing for the description to disambiguate; baseline 4 applies. The enumerated values in the description also pre-answer what the caller will see, which is a small bonus.

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 ('Obtiene') and resource ('tipos de conceptos disponibles en AFIP') and enumerates the actual domain values (Productos, Servicios, Productos y Servicios), so an agent knows exactly what comes back. It does not explicitly distinguish itself from near-siblings like get_voucher_types or get_document_types, but the AFIP domain scoping makes the difference inferable.

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: an agent can deduce this is a lookup used to populate a 'concepto' field, presumably when creating vouchers. There is no explicit when-to-use statement, no mention of when it is not needed, and no named alternative among the many other type-lookup 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 and openWorldHint=true, so the safety profile is covered, but the description adds nothing beyond the bare purpose: no mention of whether the lookup hits an external registry, what happens on a miss, or whether the result can be cached/trusted. For an open-world lookup this leaves behavioral gaps.

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?

A single front-loaded sentence with zero waste. It is appropriately sized for a one-parameter lookup, though it is so terse that it leaves obvious questions unanswered rather than being an example of tight, complete phrasing.

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?

The tool is simple (1 param, no nesting) and annotations cover safety, but there is no output schema, so the description should say what the returned CUIT looks like (format, whether null on miss). That missing return-shape/edge-case context keeps it at minimum viable.

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 single nationalId parameter is documented as 'DNI del contribuyente', which matches the description's phrasing. The description adds no format constraints (digits only, with/without dots, length), so baseline 3 is appropriate.

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

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

States a specific verb (obtiene) and resource (CUIT del contribuyente) with the input (DNI), so an agent immediately knows the transformation performed. It does not distinguish itself from the related sibling get_taxpayer_details, which also deals with taxpayer data, 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 guidance on when to use this instead of get_taxpayer_details or other taxpayer lookups, and no mention of failure conditions (e.g., DNI not found, invalid DNI). 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=true and openWorldHint=true, so the safety profile is covered. The description adds useful context that the values come from AFIP and gives sample currency codes, but says nothing about auth requirements, caching/freshness, or whether the list is static or remote-fetched.

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?

A single front-loaded sentence with the resource named first and the examples parenthesized; every clause earns its place and there is 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?

For a zero-parameter, read-only catalog lookup, the description tells an agent what comes back well enough to use it, and the examples partially substitute for the absent output schema. It stops short of describing the shape of each entry (code, label, decimals) or whether inactive currencies are included.

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, so the baseline for this dimension is 4. Nothing in the description is needed to disambiguate inputs, and nothing conflicts with the empty 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?

Concrete verb + resource ("Obtiene los tipos de monedas disponibles en AFIP") plus example values (ARS, USD, EUR) make clear this returns a currency catalog, not rates. It does not explicitly name the sibling it is distinct from (get_exchange_rate), which is the main adjacent tool.

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: an agent can infer this is the lookup to run before supplying a currency code to create_voucher or get_exchange_rate. There is no explicit when-to-use, when-not, or alternative routing, and no mention of prerequisites such as authentication with AFIP.

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 openWorldHint=true, so the safety profile is known. The description contributes the fact that the values come from AFIP and are a fixed catalog (DNI, CUIT, CUIL, Pasaporte), which tells the agent this is a static reference lookup rather than a dynamic query. It says nothing about response shape or whether codes accompany labels, which matters since no output schema exists.

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?

A single front-loaded sentence with no filler. Every element, verb, resource, source (AFIP) and example values, earns its place.

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

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

For a zero-parameter AFIP catalog lookup whose annotations already cover safety and openness, the description supplies enough to call it correctly. The only gap is the return format (codes vs. labels), which is modest given how simple the tool is.

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, so the baseline is 4. No parameter semantics are needed and none are misleadingly implied.

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 (obtiene) and resource (tipos de documentos) and scopes it to AFIP. The parenthetical examples (DNI, CUIT, CUIL, Pasaporte) make clear that this is the identity-document catalog, distinguishing it in substance from siblings like get_voucher_types or get_tax_types, though no sibling is named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to call this versus the many other catalog tools (get_voucher_types, get_concept_types, get_aliquot_types). Usage is only implied: an agent needing a valid document-type value for AFIP-related operations would infer this is the lookup. No prerequisites or exclusions are 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 and openWorldHint=true, and the description usefully names AFIP as the external data source, reinforcing the open-world nature. However, it says nothing about behavior for non-business days, unsupported dates, or unknown currency IDs, which are the realistic failure modes for a rate lookup.

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?

A single front-loaded sentence with no filler; the resource and the two scoping dimensions appear immediately.

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 tool with annotations covering the safety profile, the essentials are present. But with no output schema, the description should indicate what comes back (e.g. a buy/sell rate pair), and it omits that entirely.

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 both parameters carry examples ('DOL', '20250221') plus a format pattern, so the schema does the heavy lifting. The description only restates 'una moneda específica' and 'una fecha determinada' without adding format or validity detail.

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?

Specific verb (obtiene) plus resource (cotización de una moneda) plus source (AFIP), scoped to a single currency and date. It implicitly contrasts with the sibling get_currencies_types (which lists currency types rather than quoting one), but never names that distinction.

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 / when-not guidance, no mention of prerequisites, and no reference to alternatives such as get_currencies_types for discovering valid MonId values. The agent must infer usage entirely from the name.

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 openWorldHint=true, so the safety profile is covered, but the description adds nothing extra — no mention of whether it fails when no voucher exists for that point-of-sale/type pair, nor of what value is returned. It does not contradict the 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?

A single short sentence with no waste, but it is under-specified rather than genuinely concise — there is simply nothing beyond the title to structure.

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 lookup tool whose whole value is the returned voucher number, the description never explains the return (a number, presumably the last assigned), and there is no output schema to compensate. Given the many sibling tools, more context is expected.

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% with both parameters (PtoVta, CbteTipo) documented, so the schema carries the burden. The description adds no further meaning about the required combination or numbering semantics, so the baseline 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?

Tautological: description restates name/title.

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 guidance on when to call this versus create_next_voucher or get_voucher_info, nor on prerequisites like needing a valid PtoVta/CbteTipo combination. Usage is only weakly implied by the phrase 'último comprobante creado'.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true; the description adds nothing beyond them, such as whether the catalog is static or fetched live from AFIP, whether it can fail or require authentication, or whether results are cached. The only added element is the domain context ('para los comprobantes'), which is not behavioral.

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. Brevity is appropriate here, though the one sentence leaves key ambiguity unresolved rather than wasting space.

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 parameters and no output schema, this is arguably the minimum acceptable description: it identifies a read-only AFIP catalog lookup. However, it never explains what an "opción" is or what the entries represent, which is the one thing the description could have supplied in place of structured fields.

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, so there is nothing for the description to disambiguate. The empty schema is self-explanatory and the baseline of 4 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?

It states a specific verb+resource ("obtiene los tipos de opciones ... para los comprobantes"), but "opciones" is an ambiguous term that is not resolved anywhere. Among siblings like get_voucher_types, get_concept_types, get_document_types and get_aliquot_types, the agent gets no clue about which catalog this one returns or how it differs from get_voucher_types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance, no prerequisites, and does not name any of the many sibling type-catalog tools. An agent choosing between this and get_voucher_types/get_concept_types must guess.

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 and openWorldHint, and the description adds non-obvious behavior beyond them: in testing it always errors because no sales points are configured, and point of sale 1 is used by default. That error-mode disclosure is exactly the kind of context an agent cannot infer from structured fields.

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, zero filler, with the primary purpose front-loaded and the testing caveat immediately after. Every sentence earns its place.

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

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

For a zero-parameter, annotation-covered read tool with no output schema, the description covers purpose and the notable failure mode. It doesn't describe the shape of the returned sales points, which would be the only remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description correctly implies a no-argument, environment-scoped call.

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 ('Obtiene los puntos de venta disponibles para facturación electrónica'), so the agent knows exactly what it retrieves. It doesn't explicitly distinguish itself from siblings like get_voucher_types, though the resource is distinct enough that confusion is unlikely.

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 when-to-use or when-not-to-use guidance relative to alternatives; usage is only implied (fetch sales points before invoicing). The testing caveat is a useful operational hint but is not a selection guideline.

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 openWorldHint=true, and the mention of values 'disponibles en AFIP' is consistent with the open-world hint. The description adds the useful signal that this returns a bounded enumerated catalog, but says nothing about caching, auth requirements, ordering, or whether the list is static.

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?

A single front-loaded sentence with the resource named first and illustrative values in parentheses. Nothing is redundant or padded.

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 return shape; it only gives example display names and does not mention that entries likely include an id/code plus a description, or whether the list is complete. Adequate for a trivial zero-arg lookup, but not fully self-sufficient.

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, so there is nothing to disambiguate; the baseline of 4 applies. The description correctly implies no filtering arguments are 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?

States a specific verb and resource ('Obtiene los tipos de condiciones frente al IVA') and clarifies the domain (AFIP) with concrete examples (Responsable Inscripto, Monotributista, Exento). It is clearly a catalog-listing tool, distinguishable from siblings like get_tax_types or get_aliquot_types, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this supplies valid VAT-condition values, but the description never says when to call it, that it takes no inputs, or that its output feeds fields in create_voucher / get_taxpayer_details. No alternatives or exclusions are named.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not mention that this hits an external service (openWorld), whether errors occur for unknown CUITs, or what the returned 'datos completos' comprise.

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?

A single front-loaded sentence with no filler, appropriate for a one-parameter read tool. It is efficient but so sparse that brevity shades into under-specification.

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 with annotations covering safety, the essentials are present. However, with no output schema, the description should hint at the shape of the returned 'datos completos' so the agent knows what it will receive.

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 single taxId parameter is fully documented in the schema. The description restates that the lookup is keyed by CUIT but adds no format guidance (e.g., digit count, separators), so the baseline 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 ('Obtiene') and resource ('datos completos de un contribuyente'), keyed by the identifier (CUIT). It is clear what the tool does, but it never distinguishes itself from the near-siblings in the list (e.g., get_cuit_from_dni, which performs the inverse lookup) or describes what 'datos completos' actually contains.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer usage from the name alone, which is risky given several similarly named lookup tools in the sibling list.

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 openWorldHint=true, so the safety profile is covered. The description adds that the catalog comes from AFIP and what it includes, but does not disclose whether the catalog is static/cached or what the return structure looks like.

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 focused sentence that front-loads the action and resource, with examples that earn their place. No filler or redundant restatement.

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 lookup, the description is adequate but not complete: it never says that the result is a list of tax type identifiers/descriptions, nor whether these values are needed before creating a voucher. With no output schema, a brief note about the returned catalog would improve completeness.

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, so there is no parameter semantics to explain. The description appropriately does not invent any parameter behavior, matching the empty input 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 and resource ('Obtiene los tipos de tributos disponibles en AFIP') and clarifies scope with examples (IIBB, impuestos municipales). It distinguishes itself by resource from the many sibling '*_types' getters, though it does not explicitly differentiate when to use this versus them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call it to list available AFIP tax types. There is no explicit guidance on when not to use it, no mention of prerequisites, and no routing among the many sibling type-listing 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, external read operation. The description adds that it retrieves 'información completa' of an already-issued voucher, but does not disclose authentication requirements, error behavior if the voucher is not found, or any 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 a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose without unnecessary elaboration.

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

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

For a read-only tool with three fully documented parameters and annotations covering safety, the description is minimally adequate. However, with no output schema, it should ideally hint at what 'información completa' includes (e.g., amounts, CAE, dates) or mention any authentication/authorization requirements for AFIP access.

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 all three parameters (PtoVta, CbteNro, CbteTipo) are already documented in the schema, including a reference to FEParamGetTiposCbte for CbteTipo. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Obtener') and resource ('información completa de un comprobante'), clearly indicating retrieval of full voucher details. However, it does not distinguish this tool from siblings like get_last_voucher or mis_comprobantes, leaving ambiguity about when this specific retrieval is appropriate.

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 'ya emitido' implies the voucher must already exist, but there is no explicit guidance on when to use this tool versus alternatives such as get_last_voucher or mis_comprobantes. No exclusions or prerequisites are mentioned.

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 openWorldHint=true; the description is consistent with them and adds that the catalog is AFIP-defined (external source, so values are not controlled by the server). It says nothing about whether results are cached, complete, or ordered.

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?

A single front-loaded sentence that identifies the resource and its scope with no filler. The parenthetical examples earn their place by disambiguating the domain term.

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-param catalog with no output schema, the description omits what actually comes back (e.g. an id/code plus description) — the very field an agent needs to pass into create_voucher. Otherwise complete given the low 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?

The tool takes zero parameters and the description correctly implies a parameterless catalog fetch, so there is no parameter semantics to explain. Baseline for a 0-param tool 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 ('Obtiene') and resource ('tipos de comprobantes disponibles en AFIP') and gives concrete examples (Factura A, B, C, Nota de Crédito) that pin down what a 'comprobante' is. It does not explicitly distinguish itself from closely named siblings like get_document_types or get_concept_types, which an agent could confuse with this catalog.

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 call this versus the many sibling lookup tools, nor any mention that the returned codes are the prerequisite input for create_voucher. Usage is only inferable from the name.

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 openWorldHint=true, and the description adds genuinely non-obvious behavior: the run is always asynchronous, the response payload is fixed at { id, status }, and credentials (CUIT, username, password) come from server config rather than parameters. It stops short of saying whether repeated invocations spawn duplicate jobs or how failures surface, which keeps it at a 4 rather than 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?

Three tight sentences with zero redundancy: action, forced async contract plus return shape, then the next-step tool, then credential sourcing. The critical constraint (always async, only id/status) is front-loaded.

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 10-parameter tool with no output schema, the description supplies exactly the missing pieces: the return shape { id, status }, the async contract, the follow-up tool, and where credentials come from. Nothing an agent needs to invoke and then poll it correctly is absent.

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 every one of the 10 parameters is already documented in-schema (including the 't' enum prompt-to-ask rule and the date-range pattern). The description adds no syntax or format detail beyond the emitted/received concept, so the baseline 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: initiates the ARCA 'Mis Comprobantes' automation to download issued or received vouchers for a CUIT. The scope (emitted vs received, CUIT-based) and the asynchronous nature are clear enough to distinguish it from data-retrieval siblings like get_last_voucher or get_voucher_info.

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?

Explicitly states the tool ALWAYS runs async (wait=false) and returns only { id, status }, then names the follow-up tool 'get_automation_details' with the returned id. This is a complete when/when-next routing instruction, not an implication.

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