RESET Verifica

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

Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds valuable context: it consumes balance (LEGAL service) only when results are found, and includes a disclaimer. This goes beyond the annotations and clarifies side effects and cost behavior, which is important for agent decision-making.

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 three sentences long, starting with the core purpose, then filters, then cost and disclaimer. It is efficient and front-loaded, with no redundant phrasing. The structure is logical and easy to parse.

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 six parameters, no schema descriptions, and an output schema present, the description covers purpose, filters, and cost but leaves gaps. It does not explain the meaning or accepted values of parameters like materia, ambito, or entidad, nor does it clarify the required 'q' parameter. The return format is presumably covered by the output schema, so that is acceptable. Overall, it is adequate but not exhaustive.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions filters for materia, ambito, entidad, and documento, mapping to four of the six parameters. However, it omits the required 'q' parameter (the search query) and 'limite' (limit), leaving the most essential parameter undocumented. This partial coverage earns a 3.

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

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

The description clearly states the tool performs full-text search in Mexican legislation and returns articles with excerpt, citation, and source. It specifies the resource and action distinctly, though it doesn't explicitly contrast with sibling tools like consultar_ley or catalogo_leyes. The filters are mentioned, but the differentiation from alternatives is not explicit.

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 no guidance on when to use this tool versus alternatives like consultar_ley or catalogo_leyes. It notes the cost implications, which is relevant for usage decisions, but there is no explicit statement of use cases or exclusions. An agent would have to infer when to choose this tool.

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 only indicate non-read-only, non-idempotent, non-destructive, but the description adds crucial behavioral context: it consumes saldo (a financial side effect), it only works within the loaded validity period, and it declares version and disclaimer. These are significant disclosures that go beyond annotations and help the agent understand side effects and constraints.

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 concise, with three sentences that carry essential information. It front-loads the core purpose and then adds behavioral notes. No filler or redundancy. The only slight issue is the density of jargon (e.g., 'SBC', 'NOMINA', 'deslinde') which may require domain knowledge, but it is efficient.

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 complexity (4 parameters, output schema present), the description covers key behavioral constraints (validity period, balance consumption) but omits details about the 'dias' and 'fecha_calculo' parameters. It also does not mention error conditions or output format specifics, though an output schema exists. The description is adequate but leaves gaps for an agent unfamiliar with IMSS terminology.

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

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

Schema description coverage is 0%, so the description must compensate. It explains sbc_diario (daily SBC) and prima_riesgo (optional for Riesgos de Trabajo), but it does not clarify the meaning of 'dias' or 'fecha_calculo'. With four parameters and half undocumented, the description falls short of providing sufficient parameter semantics.

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 (calculate) and resource (IMSS and Infonavit quotas) based on daily SBC. It distinguishes itself from sibling calculation tools like calcular_isr and calcular_laboral by naming the exact subject matter. The mention of 'Riesgos de Trabajo' as an optional component adds further specificity.

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 contextual guidance: it consumes balance (saldo) and references consultar_precios for current rates, implying it's a paid service. However, it does not explicitly state when to use this tool versus alternatives like calcular_isr or calcular_laboral, nor does it give exclusion criteria. The condition for using prima_riesgo is clear, but the overall routing guidance is implicit.

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 goes well beyond annotations by disclosing that the tool 'Consume saldo (servicio NOMINA; tarifa vigente en consultar_precios),' which is important cost behavior. It also explains date-dependent table validity and the warning behavior when the date falls outside the loaded table, plus the caveat 'Resultado matematico, no resolucion oficial.' These are meaningful non-obvious behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the core operation first, then cost, validity behavior, and the official-status caveat. Every sentence contributes a distinct, non-redundant fact with no filler.

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

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

For a two-parameter calculation tool with an output schema, the description covers purpose, parameter semantics, cost, date-dependent failure behavior, and the limitation that the result is not an official resolution. Nothing critical needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It maps base_gravable to the taxable payroll base and links fecha_calculo to the table validity and out-of-range warning, adding real meaning beyond the schema titles. It does not explain default behavior or formats, but the schema already provides types.

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: 'Calcular ISR mensual de nomina (LISR art. 96) sobre una base gravable, para una fecha.' This identifies the operation, the legal basis, and the domain, making it clearly distinguishable from sibling tools like calcular_imss and calcular_laboral.

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 context is implied: it is for monthly payroll ISR calculations on a taxable base for a given date. However, it never explicitly states when to use this tool versus alternatives, nor does it name conditions or exclusions beyond the date-out-of-table behavior.

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 annotations (readOnlyHint false, destructiveHint false), the description discloses that the tool consumes balance (cost), that results are mathematical and not official resolutions, and that each response declares the table/version used. These are valuable behavioral traits not captured in 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?

The description is a single dense sentence that packs in purpose, cost, and disclaimer. It is not front-loaded with the most critical info first and could benefit from bullet points or segmentation, but it is not overly verbose.

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 9-parameter tool with no output schema, the description is inadequate. It does not specify which parameters are required for each concept, the expected input formats, or the return structure beyond mentioning table/version declaration. An agent would struggle to invoke it correctly without additional information.

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

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

With 0% schema description coverage, the description must compensate, but it only mentions the 'concepto' parameter's possible values. The other eight parameters (fecha_baja, salario_diario, etc.) are left completely unexplained, leaving an agent without guidance on their meaning or which are relevant per concept.

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 Mexican labor concepts (aguinaldo, prima_vacacional, finiquito) under LFT, with breakdown, legal basis, and disclaimer. It distinguishes itself from sibling calculators like calcular_imss and calcular_isr by naming specific labor concepts, leaving no ambiguity about its domain.

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 listing the supported concepts, but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or refer to sibling tools. It does warn that it consumes balance, which is a usage consideration, but no explicit routing guidance is 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond those annotations: it returns a document_id, it is free, and it exposes only the catalog, not the full content. It omits details like pagination or result limits, but the annotation coverage lowers the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: scope, filter options, return value, and cost/positioning. It is front-loaded with what the tool is and avoids filler or repetition of the schema.

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 catalog tool with four optional parameters and no output schema, the description gives the essential invocation context: available filters, the returned document_id, and the relationship to consultar_ley. Minor gaps remain around how filters combine and what happens with multiple matches, but this is sufficient for correct selection and basic 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%, so the description must carry the parameter meaning, and it largely does: it maps materia to examples (Civil/Penal/Fiscal/Laboral), ambito to examples (Federal/Estatal/Nacional), entidad as a filter, and 'texto en el nombre' to the q parameter. It does not explain matching semantics or all valid entidad values, but it makes every parameter understandable.

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 a specific resource: the index of available Mexican legislation, including the scope (Constitution, codes, federal/national/state laws). It also names the action (filter and return document_id) and distinguishes itself from content tools by saying it is 'el catalogo, no el contenido.' This makes its purpose and difference from consultar_ley explicit.

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

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

The description says it returns the document_id needed for consultar_ley, which tells the agent to use it as a lookup step before fetching content. It also clarifies that it is only the catalog, not the content itself. However, it does not explicitly mention alternatives like buscar_ley or state when not to use them.

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?

Aporta contexto útil más allá de las annotations: el catálogo es público, no exige llave, y describe los dos modelos de pago (prepago y x402). Todo es coherente con readOnlyHint, idempotentHint y destructiveHint=false.

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?

Dos frases densas pero bien estructuradas: la primera define qué es y qué contiene, la segunda explica cuándo usarlo y los modelos de pago. No hay relleno ni repetición del título o del schema.

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?

Para una herramienta sin parámetros y sin output-schema, la descripción cubre lo necesario: alcance, contenido devuelto, requisito de llave y utilidad práctica. Las annotations ya cubren el perfil de seguridad y efectos, así que no falta información crítica para invocarla correctamente.

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?

El input-schema no tiene parámetros y la cobertura de descripción del schema es 100%, por lo que no hay semántica paramétrica que aclarar. La mención de 'inputs' se refiere al contenido del catálogo, no a argumentos de esta herramienta. Aplica el baseline de 4 para 0 parámetros.

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?

Define con precisión el recurso: catálogo público de servicios de RESET Verifica, y especifica su contenido: qué hace cada servicio, precio, inputs, determinismo y forma de pago. Se distingue de herramientas hermanas como consultar_precios o consultar_catalogo al destacar que es público y que no requiere llave.

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?

Indica cuándo usarlo: para decidir si RESET resuelve el problema antes de autenticarse o pagar. Añade que no requiere llave, lo que orienta al agente sobre prerequisitos. No nombra explícitamente alternativas ni exclusions, pero el contexto de uso es claro.

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 explicitly discloses a non-obvious side effect: the tool consumes saldo as service DATO, which aligns with readOnlyHint=false and idempotentHint=false. This goes beyond what annotations alone indicate by explaining the cost model and pointing to the pricing sibling. It does not discuss output format or limits, but the main behavioral risk is covered.

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 dense sentences with no filler. It front-loads the core purpose and immediately adds the critical cost/balance information and a pointer to the pricing tool. Every clause adds value.

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 four parameters with no schema descriptions, no enums, and no output schema, the description leaves important gaps: possible values for 'tipo', the meaning of 'subtipo', expected result format, and error/insufficient-balance behavior. The examples help but do not fully compensate for the absence of structured parameter documentation.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does so by implying 'clave' for SPEI, 'numero' for phone/LADA, and 'tipo/subtipo' for SAT catalog categories, but it never formally defines each parameter, valid values, or how they combine. Required 'tipo' remains underspecified.

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 uses the specific verb 'Consulta' and clearly identifies the resource as official Mexican catalogs/data, listing concrete examples such as SPEI bank codes, SAT catalogs, and phone/LADA lookups. This makes the tool's purpose understandable and differentiates it from generic validators, though it does not explicitly name sibling distinctions.

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

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

The description gives clear context: use this tool for official Mexican catalog/datum lookups and mentions that it consumes balance, directing the agent to consultar_precios for current pricing. It lacks explicit exclusions or comparisons to sibling validators, but the intended usage is clearly 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?

Beyond the limited annotations, the description discloses that the call consumes balance under the LEGAL service, points to consultar_precios for current pricing, and warns that the output is dated reference text whose validity should be verified. These are material behavioral traits not present in the annotation 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?

Three dense sentences cover outcome, required parameters with examples, and billing/legal caveats. No filler or repetition; the most identifying information 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 two-required-parameter lookup with an output schema, the description is complete: it explains how to obtain the inputs, what the result includes, that it costs money, and that it is not certified legal advice. There are no major gaps for an agent deciding whether and how to call this 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?

Although the schema has no descriptions and 0% coverage, the tool description explains both parameters precisely: documento_id comes from catalogo_leyes with the example 'codigo_civil_federal', and articulo accepts numbers like '1793' or '49 Bis'. This fully compensates for 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?

The description identifies the resource as the exact text of a Mexican law article and lists the contained elements (citation, location, official source, last reform date, disclaimer). It implies a direct lookup by documento_id and articulo, but does not explicitly contrast itself with buscar_ley, so sibling differentiation is not fully explicit.

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 clearly says to pass the document_id from catalogo_leyes and an article number, gives examples, and states this is reference text, not legal advice or certified copy. It lacks an explicit 'when to use this vs buscar_ley' statement, but the instructions and exclusion are clear.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful context beyond those annotations: prices are current (MXN, IVA included) and no key is required, which helps the agent understand authentication and data semantics. 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?

The description is extremely concise, with only two short clauses, and both carry meaningful information: the price table's nature/content and the lack of an authentication key. Every word earns its place, and the most important detail 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 zero-parameter, read-only tool with rich annotations, the description covers what an agent needs: the data is a current price table in MXN with IVA included, and no key is required. No output schema exists, but the phrase 'tabla de precios' sufficiently indicates the return shape for this simple case.

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 input schema has zero parameters and schema description coverage is effectively 100%, so the baseline of 4 applies. The description does not need to explain parameters, and it correctly avoids fabricating any.

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

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

The description states the resource clearly: a current price table in MXN including IVA. It lacks an explicit verb like 'returns' or 'queries', but the tool name 'consultar_precios' supplies that action, and the scope is distinct from sibling tools. It is not vague, though it does not explicitly differentiate from alternatives.

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 guidance on when to use this tool versus any sibling, and it does not mention exclusions or alternatives. 'No requiere llave' is a useful prerequisite about authentication, but it is not a usage condition or comparison against other 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, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value by stating the operation has no cost and by outlining result contents, but it does not go deeper into recency, limits, or data source behavior.

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 concise sentence states exactly what information is returned and adds only the essential cost fact. Nothing is wasted and the key content 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 zero-parameter, read-only tool with complete annotations, the description is sufficient. It tells the caller what result data to expect (balance, usages, expirations, movements) and that the operation is free, so no output schema or further context is strictly necessary.

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 has zero parameters and an empty schema, so parameter semantics are trivially complete. The description does not need to explain parameter meaning and instead focuses on the result content, which is appropriate here.

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 title supplies the verb 'Consultar', and the description names the resource: package balance, per-product usage with expiration, and recent movements. It clearly identifies what information is returned and is distinguishable from siblings like consultar_uso by also covering balance and movements.

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 guidance on when to use this tool versus alternatives such as consultar_uso or consultar_precios. 'No tiene costo' is a pricing note, not a usage condition, so an agent gets little help selecting this tool over nearby 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?

Las anotaciones ya cubren readOnly, idempotente y no destructivo; la descripción añade el dato de que no tiene costo y que el resultado es por servicio y detalle. No aclara qué ocurre si se omite 'mes' ni describe autenticación o límites, pero aporta algo más allá de las anotaciones.

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?

Tres frases breves sin relleno: propósito, formato del parámetro y costo. La información importante está al inicio.

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?

Para una herramienta simple de solo lectura, cubre propósito, formato y costo, pero no hay esquema de salida y no se describe la forma de la respuesta más allá de 'por servicio y detalle'. La ausencia de comportamiento ante 'mes' vacío deja un vacío relevante.

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?

Con cobertura de esquema al 0%, la descripción debe compensar; aporta el formato AAAA-MM para 'mes', que es útil y no está en el esquema. Sin embargo, no explica el significado exacto del valor, si es obligatorio/opcional (aunque el esquema tiene default '') ni el comportamiento cuando se omite.

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?

La descripción identifica el recurso ('consumo del periodo') y el alcance ('por servicio y detalle'), dejando claro que devuelve el uso asociado al periodo. Aunque no diferencia explícitamente de herramientas hermanas como 'consultar_saldo' o 'consultar_precios', el término 'consumo' lo distingue razonablemente.

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 ofrece pautas de cuándo usar esta herramienta frente a alternativas; en una lista con varias 'consultar_*' no se menciona, por ejemplo, que 'consultar_saldo' es para saldo y esta para consumo. Tampoco se indica cuándo no usarla.

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=false (a mutation), and the description adds that it has no extra cost and returns a folio that is freely validatable. It doesn't detail any side effects or idempotency, but the annotations cover the basic mutability and non-idempotency, so the description adds some context without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (2 sentences) and front-loads the core purpose and the key parameter. It avoids repetition of the schema and provides essential information efficiently.

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 (1 param, no output schema), the description covers the main purpose and points to the validation sibling. However, it could benefit from clarifying what constitutes a 'verification you already did' and any prerequisites, but it is generally adequate.

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

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

The schema has 0% coverage, as the parameter verification_id is just a string with no description. The description mentions it is the verification_id of a previously performed verification, but does not explain format, example, or how to obtain it, leaving the agent with limited guidance for a critical parameter.

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

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

The description clearly states the tool emits a constancia (verifiable receipt) for a previously performed verification, identified by verification_id. It distinguishes itself from validar_constancia by noting it produces a folio that can be validated by that sibling 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?

The description implies the tool is used after a verification has been completed, and references validar_constancia as the alternative for validating the folio. However, it does not explicitly state when not to use this tool, but the context is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds that the tool requires no key and details what status information it provides (update times, validity, versions). This adds value beyond the annotations by clarifying the scope of the status report, though it does not describe the output 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 concise sentence that front-loads the tool's purpose ('Estado del servicio y de las fuentes/tablas oficiales') and then enumerates what it covers. There is no redundant information, and it efficiently communicates the essential function.

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 tool with no parameters, no output schema, and strong safety annotations, the description provides adequate context: it states what the tool reports and that no key is required. It could be more detailed about the exact response structure, but for a status check, this is acceptable. The description covers the necessary essentials.

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 has zero parameters, so the schema covers 100% by being empty. Per the baseline for 0 parameters, the description doesn't need to explain parameters, and it doesn't; it simply confirms no key is needed. This is sufficient.

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 reports service status and official sources/tables, enumerating what it covers (SAT list updates, tax table validity, catalog versions, rates). This distinguishes it from sibling tools like consultar_catalogo or validar_* which operate on specific data. The verb 'estado' makes the purpose explicit, though it could be more specific about the exact output.

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

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

The description implies the tool is for checking service health and data freshness but does not explicitly state when to prefer it over alternatives. It notes that no key is required, which hints at accessibility, but lacks explicit usage guidance or exclusions. Given the many sibling tools, more explicit routing would help.

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 this is a mutating, non-idempotent operation, so the description is not required to restate that. It adds useful context: the registration is for later reconciliation and has no cost. However, it does not explain side effects, duplication behavior, or what happens after a successful registration.

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: two short sentences with no filler. The core action and purpose are front-loaded, and the additional cost note is relevant and compact.

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 low-complexity tool with only two required parameters and no nested objects, the description gives enough surface-level context to attempt a call. However, it omits any guidance on what 'referencia' means, what a successful response looks like, and any edge conditions around the amount, making it only minimally complete.

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

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

Schema description coverage is 0% and the description does little to clarify the two parameters. 'Monto' can be reasonably inferred as the amount of the receivable, but 'referencia' is ambiguous: it could be an invoice number, customer reference, or internal ID, and no format or uniqueness requirements are given.

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 a specific verb ('Registra') and resource ('obligacion (cuenta por cobrar)'), and adds the purpose of later reconciling against a payment. This strongly differentiates it from the sibling tools, which are mostly consultar/validar/calcular operations.

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: use this tool when you need to register an accounts-receivable obligation that will later be reconciled with a payment. It does not explicitly name alternatives or state when not to use it, so it falls short of a full 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?

Beyond the annotations, the description discloses meaningful behavioral details: it consumes paid balance (servicio SCREEN), returns scores 0-100, produces one record per consulted list, and explicitly warns that a 'no match' result is not a compliance certification. This is substantial value-add over the structured annotation flags.

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 dense but well-structured: purpose, parameter usage, output shape, cost, and compliance caveat each get their own sentence. Every clause earns its place, and the most important operational details are front-loaded before the caveat.

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 complexity and the presence of an output schema, the description is thorough: it names the lists and countries covered, explains the optional parameters, describes the return format, flags the cost, and clarifies the legal/evidentiary limitations. Nothing critical needed to call it correctly is missing.

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

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

The input schema has 0% description coverage, so the description carries the full burden for parameter semantics. It compensates well: it explains that 'name' is the required input, 'country' is an ISO code like MX, 'tax_id' is used for national cross-checking, and 'certificate=true' returns a base64 PDF. All four parameters are given practical 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 a specific verb and resource: screening a name/entity against international sanctions lists, PEP lists, and national lists, naming exact sources (OFAC, EU, UK, Canada, etc.). It is clear, but it does not explicitly differentiate itself from the sibling screening_monitorear, so the agent has to infer the one-time vs. monitoring 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?

The description provides clear usage context: it tells the agent what to send, optional parameters, the fact that it consumes balance, and that the result is evidence rather than certification. However, it does not explicitly state when to prefer this tool over screening_monitorear or other verification siblings, so it stops short of full when/when-not guidance.

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

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

The description adds behavioral context beyond the annotations: the MONITOREO_SCREEN webhook, the signed event, the NEW-match trigger, and the need to register the endpoint separately. 'El alta' also confirms a registration side effect, consistent with readOnlyHint=false. It does not discuss duplicate registrations, but annotations already signal non-idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler. The core purpose, webhook behavior, parameters, and cost are all front-loaded or clearly separated, and every sentence earns its place.

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

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

For a simple 3-parameter tool, the description is mostly adequate: it explains the async outcome (webhook) and a key prerequisite (endpoint registration). However, with no output schema, it does not describe the immediate confirmation response or the webhook payload, and it does not mention how to stop monitoring.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It only repeats that 'name' is sent and 'country' and 'tax_id' are optional, which the schema already expresses through required/default fields. It adds no format, value, or semantic detail for country or tax_id.

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

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

The description states a specific action ('vigila un nombre'), the resource (sanctions/PEP/national lists), and the outcome (a signed webhook on a NEW match). It implies a monitoring behavior distinct from a one-time list search, though it does not explicitly name the sibling screening_listas 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?

Ongoing monitoring is implied through 'recibirás un webhook' and 'coincidencia NUEVA', but the description never states when to choose this tool over a one-time search or provides explicit exclusions. It gives context about registering a webhook endpoint but no direct alternative guidance.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the tool is a paid DATO service that consumes balance, and it points to 'consultar_precios' for the fee. It also states the return content (date and official series), which adds value beyond the annotations. No contradiction 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?

Two compact Spanish sentences front-load the core purpose, then add the cost warning and return description. No filler or redundancy, each clause carries distinct information.

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

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

For a simple 2-parameter lookup with an output schema, the description covers the main usage points: optional date, optional amount conversion, cost implication, fee lookup route, and output summary. It falls short only on date format and conversion semantics, which prevents a 5.

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

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

With 0% schema description coverage, the description must compensate for the bare schema titles 'Fecha' and 'Monto'. It says both are optional and that 'monto' is for conversion, but it does not specify the expected date format or the direction/currency of the amount conversion (USD to MXN vs MXN to USD), leaving ambiguity.

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

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

The description clearly identifies the tool as the official Banxico FIX USD/MXN exchange rate service, with optional date filtering and amount conversion. It states the resource (official Banxico FIX rate), the scope (by date, optional amount conversion), and the observable output (date and official series). Although no sibling is named, no sibling tool provides exchange rates, so it is effectively distinguishable.

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 explicitly warns that the tool consumes balance ('Consume saldo') and directs the user to 'consultar_precios' for the current fee, which is actionable usage guidance. It does not explicitly state when not to use it, but the fee pointer and optional-parameter explanation provide clear context for deciding to invoke it.

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

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

The description discloses that the tool consumes saldo (a side effect) and is a UTIL service with a fee, which is beyond the annotations (readOnlyHint=false does not capture this). It also clarifies that it only validates structure, not existence, adding behavioral detail not present in 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 three sentences, each earning its place: purpose, cost/where to check, and limitation. It is front-loaded with the core action and has no redundant 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?

For a single-parameter validation tool with an output schema, the description covers all necessary aspects: what it validates, the cost and where to check it, and a key limitation. The output schema handles return values, so no further explanation is needed.

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

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

Schema coverage is 0%, so the description must compensate. It explains the structural requirements of a CLABE (18 digits, control digit, bank prefix), which directly informs the expected format of the 'clabe' parameter. While it does not explicitly state 'clabe must be an 18-digit string', the description implies it sufficiently.

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 uses a specific verb ('Valida') and resource ('CLABE'), and enumerates exactly what is checked: 18 digits, control digit, and bank by prefix. It also explicitly states what it does NOT do (confirm account existence), which differentiates it from verification tools among the siblings.

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: it is a paid service (consumes saldo) and indicates where to check the fee (consultar_precios). It also states a limitation ('No confirma que la cuenta exista'), implying that if existence verification is needed, another tool should be used, though it does not name a specific 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds outcome semantics: it confirms existence, timestamp, and result, plus public/no-key/no-cost access. No contradictions; it extends the annotation profile with response content and access constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and identifier, followed by access details. No filler; every clause adds information.

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

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

For a single-parameter read-only validation tool, the description covers purpose, identifier, result semantics, and access requirements. It does not detail error behavior or output structure, but with no output schema and rich annotations, it is sufficient for an agent to call correctly.

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 provides only name and type ('folio', string) with 0% description coverage. The description ties the parameter to the certificate ('por su folio') and indicates it is the lookup key, but does not specify format, length, or examples. Some meaning added, but not full compensation.

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 'Valida' with resource 'constancia' and identifier 'folio', and describes the outcome: 'confirma que la verificacion existio, cuando y con que resultado.' This clearly distinguishes it from sibling validators like validar_curp (different resource) and emitir_constancia (opposite operation).

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 clear context for when to use: public validation, no key required, no cost. It implicitly scopes to constancias by folio, but does not explicitly name sibling alternatives or state when not to use. The usage context is clear, though exclusions are implied rather than stated.

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

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

Annotations are sparse (readOnlyHint false, destructiveHint false, etc.). The description adds meaningful behavioral context: it confirms the tool performs local validation and decoding, and explicitly denies RENAPO registration confirmation, which is a side-effect disclosure. It also notes the package billing context ('Incluido con saldo de paquete'), which is a usage condition. 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 three concise sentences. The primary purpose is front-loaded in the first sentence, the package inclusion is a short secondary note, and the limitation is stated last. Every sentence earns its place with zero 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?

The tool has one parameter and an output schema (not shown). The description covers what it does, what it returns (decoded info implied), and the crucial limitation about RENAPO. It also mentions the package billing condition. For a simple validation tool, this is adequately complete; missing explicit error handling is acceptable given the output schema.

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

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

Schema description coverage is 0%, so the description must carry the parameter meaning. It clearly identifies the parameter as a CURP to validate, and the description of validation (formato, digito verificador, decodificacion) adds semantics beyond the schema's bare 'string' type. It does not explicitly state the expected format, but the purpose is evident.

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 uses a specific verb 'Valida' and a specific resource 'CURP', and clearly enumerates the scope: formato, digito verificador, and decodificacion. It also explicitly states what it does not do ('No confirma registro ante RENAPO'), which further differentiates it from any sibling that might check official registry. This is unambiguous and distinct.

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 naming the tool's purpose and scope. It does not explicitly name alternatives, but the limitation 'No confirma registro ante RENAPO' informs when not to use it (if official registration confirmation is needed). This is a clear contextual signal, though it stops short of naming a specific sibling 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 only mark non-read-only and non-destructive; the description adds that the call is covered by package balance, implying a balance-consuming operation, and clarifies the scope with the affiliation disclaimer. The balance wording is slightly ambiguous but there is 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?

Two short sentences, front-loaded with the core action and validation type, followed by billing and exclusion notes. Every sentence earns its place 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?

For a one-parameter validation tool with output schema present and annotations covering safety, the description covers purpose, scope, and billing context. It lacks an explicit alternative for affiliation confirmation, but that gap is minor given the tool's simplicity.

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

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

With 0% schema coverage for the single 'nss' parameter, the description compensates by defining NSS as a social security number and indicating that format and Luhn digit are validated, giving the agent enough semantic grounding to populate the parameter with a user-provided NSS.

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 ('Valida'), a specific resource (NSS), and the exact validation criteria (formato y digito Luhn). The explicit disclaimer that it does not confirm IMSS affiliation prevents confusion with larger verification tools among the siblings.

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

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

Gives a clear exclusion: this tool does not confirm affiliation with IMSS, so agents know not to use it for that purpose. It also notes the package-balance inclusion. However, it stops short of naming an alternative sibling (e.g., verificacion_completa) for affiliation checks.

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 signal basic traits (readOnlyHint=false, openWorldHint=true, etc.), so the description's job is to add context. It adds the critical caveat that the tool does not confirm SAT registration, and mentions package balance inclusion, which hints at billing behavior. This goes beyond annotation data and helps set expectations.

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, all informative and front-loaded with the core purpose. The SAT registration caveat and package balance note are placed after the main function, maintaining a clean structure with no redundant 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?

For a simple one-parameter tool with an output schema present, the description covers the essential purpose, validation scope, and a key limitation. The mention of package balance adds cost context. Missing details about RFC format expectations are minor given the single obvious parameter and validation-focused nature.

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 there is only one parameter (rfc), whose meaning is obvious from the tool name and description. The description implies that 'rfc' is the RFC string to validate and describes what validation checks, but does not specify input format constraints (length, case, pattern) beyond what validation implies. It adds some value but not enough to fully compensate for missing schema documentation.

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

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

Description clearly identifies the resource (RFC), the action (validate structure), and specific aspects checked (formato, tipo de persona, fecha, dígito verificador). It also distinguishes itself from other validation tools by explicitly stating it does not confirm SAT registration, which is a unique qualifier among the sibling validar_* tools.

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

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

The description states what the tool does and explicitly excludes a common use case (confirming SAT registration), which helps agents avoid misuse. However, it does not name any alternative tools or provide explicit when-to-use versus sibling validar_* or verificar_* tools, leaving some inference required.

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 discloses meaningful behavioral traits: it does not retain the full card number ('No se conserva el numero completo'), it is included with package balance ('Incluido con saldo de paquete'), and it does not confirm account/funds. These go beyond the sparse annotations, which only indicate no destructive action. There is 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 three sentences, front-loaded with the primary function and then adding behavioral notes. It is concise and free of fluff, but the behavioral notes are somewhat mixed in, and the structure could be improved by separating the core purpose from caveats. Still, it is efficient.

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 validation tool with an output schema present, the description covers the purpose, input, and key limitations. It does not mention error conditions or expected output, but those may be in the output schema. The inclusion of package balance and non-retention adds useful context, making it reasonably complete.

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

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

Schema coverage is 0%, so the description must compensate. It mentions the input 'pan' (card number) but does not elaborate on format, length, or examples. The description adds the fact that the PAN is sent, which gives some meaning, but it could be more explicit about the expected format. For a single standard parameter, this is acceptable but not outstanding.

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 ('Valida') and resource ('una tarjeta'), and specifies the method ('Luhn + BIN + marca'). It clearly distinguishes from sibling validation tools like validar_curp or validar_clabe, as each targets a different identifier type. The purpose 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 implies usage for card validation and explicitly states what it does NOT do ('No confirma cuenta ni fondos'), which helps an agent avoid using it for account or fund checks. However, it does not explicitly name alternatives or provide a when-to-use vs. when-not-to-use condition beyond the negative limitation.

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 discloses that the operation consumes saldo and is a paid COMBO service, with current rates found in consultar_precios. This adds meaningful behavioral context beyond the annotations, which only indicate readOnly=false, idempotent=false, and destructive=false, and it is consistent with those flags.

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 carry all essential information: the bundled scope, the three input components, the combined pricing, and the balance consumption. The text is front-loaded with the primary purpose and contains 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?

The description is largely complete for invoking the tool: it explains what the tool does, which inputs are needed and their format, that it consumes saldo, and where to find pricing. It does not describe the return value or the behavior of the optional refs parameter, but no output schema exists and these gaps are relatively minor.

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 compensates by mapping rfc to 'empresa', cfdi_xml to 'factura (XML CFDI)', and cep_xml to 'pago (XML CEP)'. However, the optional `refs` parameter is not explained, leaving a small gap.

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

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

The description clearly identifies the operation as a combined 'COMBO' transaction: company verification by RFC plus invoice (CFDI XML) plus payment (CEP XML) in one call. This distinguishes it from sibling tools like verificar_empresa, verificar_factura, and verificar_pago by making the bundled scope explicit.

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: this is the all-in-one bundled operation 'a precio combinado' and it consumes account balance. It implies the agent should use this when all three verifications are needed, though it does not explicitly state the alternative of calling the three sibling tools separately or specify 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 indicate readOnlyHint=false and destructiveHint=false, which is somewhat ambiguous (not read-only but not destructive). The description adds that it consumes saldo (affects balance) and that results reproduce official sources Horizons, which gives some transparency. However, it does not bias the openWorldHint or explain what actions are performed (e.g., data retrieval vs. report generation). The description does not contradict annotations, but adds minimal extra value beyond the saldo note.

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 concise, three sentences with no fluff. It front-loads the primary function, then the coverage scope, then the cost implication. It is well-organized and each sentence adds value, though the second sentence starts with 'Consume saldo' which is a bit unexpected but still relevant.

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 has an output schema (not provided in input but mentioned), and has 2 parameters with one required. The description covers the core purpose and financial consequence (saldo), but does not specify what the output looks like (though output schema exists) or any prerequisites (e.g., valid RFC format). It lacks mention of error scenarios or authorization needs. Given the complexity is moderate, the description is adequate but not complete—it does not mention how to handle invalid RFCs or what causes failure.

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%, meaning the schema provides no descriptions for 'rfc' or 'sancionados'. The description mentions the tool verifies by RFC and covers sancionados, but does not explain the 'sancionados' boolean parameter—its meaning is implied (whether to include sanctioned entities) but not explicitly stated. The description partially compensates for the 0% coverage by explaining the company verification context, but could be clearer about the parameters.

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 verifies a persona moral o fisica by RFC, listing specific sources (SAT 69-B, articulo 69, contratacion publica, sancionados). It distinguishes from siblings by mentioning 'sancionados' and '69-B', but does not explicitly name a sibling or differentiate from 'verificacion_completa' which might be a broader 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?

The description gives context that it consumes saldo and mentions a service (COMPANY) and tariff, but does not explicitly state when to use this tool versus alternatives. It does not say when not to use it or mention alternatives. The purpose is clear but usage guidance is implicit—the agent must infer it is for checking company status.

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 annotations (readOnlyHint=false), the description discloses that this call consumes balance and points to consultar_precios for the rate, which is essential behavioral information for an agent to obtain user consent. It also reveals that validation happens against live SAT status, implying a real-time external dependency.

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 carry the entire payload: purpose, detailed scope, parameter mapping, and cost indicator. The most important information is front-loaded, with no filler or repetition of schema fields.

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 tool with one required parameter and an output schema, the description covers invocation, validation logic, and financial implication. The only marginal gap is the exact XML representation, but the presence of an output schema means the agent can infer the expected response format.

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% and the parameter name 'xml' alone is ambiguous; the description fills the gap by explicitly stating 'Envia el XML del CFDI en ''xml'''. It still does not specify representation details like raw XML string vs base64, but it supplies the core semantic that the schema lacks.

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

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

The description opens with a specific verb and object ('Valida un CFDI') and immediately specifies what validation entails: XSD against Anexo 20, live SAT status, and 69-B cross-check. This distinguishes it from sibling validators like validar_rfc or validar_constancia without needing to name 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?

It gives clear operational context: the agent should send the CFDI XML in the 'xml' parameter, and it warns that this is a paid service whose current rate is listed in consultar_precios. It does not explicitly contrast against overlapping siblings like verificacion_completa or verificar_pago, but the use case is unmistakable.

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 note readOnlyHint=false; the description adds the crucial side effect that the call consumes saldo and references consultar_precios for the fee. It also notes reconciliation against registered obligations, implying the tool may alter or match records, though it stops short of saying exactly what changes.

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: purpose, parameter instructions, and cost warning. No waste, and the load-bearing information 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 2-parameter tool with an output schema, the description covers required input, optional input, and a cost side effect. It does not spell out return handling in prose, but that is covered by the output schema; the only minor gap is exact format requirements for xml/refs.

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

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

With 0% schema coverage, the description is the only source of meaning for the two parameters. It explains that 'xml' is the CEP XML and 'refs' is optional references to reconcile, but it does not specify the expected format (e.g., XML encoding or how refs are delimited).

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

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

The description names the exact action: process a CEP (SPEI voucher) and reconcile it against registered obligations. This clearly separates it from invoice/company validation siblings and makes the tool's domain evident.

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 context: use when you have a CEP XML and want to reconcile it against obligations. It also warns that this is a paid SPEI service and points to consultar_precios for current pricing, though it does not explicitly state when-not-to-use or name an alternative reconciliation tool.

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