RESET Verifica

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

With no annotations provided, the description carries the full burden and does a good job: it discloses the validation against Banxico, the conditional nature of the credit, the instant result on success, and that there is no cost. It does not detail failure modes, but the core behavioral profile is clearly communicated.

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 and front-loaded: it states the action, the input method, the validation step, the success condition, and cost in three short sentences. Every sentence contributes useful information with no redundancy.

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

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

For a tool with only two string parameters and no output schema, the description covers the essentials needed to invoke it correctly: what to send, what happens, and the success condition. It leaves error-case behavior and explicit sibling differentiation unaddressed, but those are minor gaps for such a simple operation.

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 both required parameters to their real-world objects ('referencia del fondeo' and 'XML del CEP'), which adds some semantic context, but it stops short of explaining formats, constraints, or how to obtain the reference.

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 ('Acredita') and a specific resource ('fondeo'), and explains the mechanism: uploading a CEP XML that is validated against Banxico. The conditional outcome ('si liquido, se acredita tu saldo al instante') provides enough specificity to distinguish it from related sibling tools.

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

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

The description implies when to use the tool: when you have a fondeo reference and a CEP XML, and want the balance credited after Banxico validation. However, it does not explicitly state when to prefer this over siblings like crear_fondeo or crear_fondeo_x402, nor does it name any alternatives or exclusions.

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?

With no annotations provided, the description carries the full transparency burden. It discloses cost behavior ('Cuesta LEGAL cuando hay resultados; una busqueda sin coincidencias no cobra'), the presence of a disclaimer, and the return shape. It omits details like authentication, rate limits, and pagination, but gives meaningful behavioral context.

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

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

Three short sentences front-load the purpose, then the return shape, filters, cost, and disclaimer. Every sentence adds necessary information with 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?

Given no output schema and no annotations, the description covers purpose, result contents, filter dimensions, cost, and no-result behavior. It is largely complete, but missing semantics for limite and the documento vs documento_id naming mismatch keep it from being fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning by mapping the filter parameters materia, ambito, entidad, and documento/documento_id, and implies q is the full-text search term. However, it does not explain limite, and it refers to 'documento_id' while the schema parameter is named 'documento', 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 a full-text search operation over Mexican legislation and states what is returned: articles with excerpt, citation, and source. It is recognizable against sibling tools like catalogo_leyes and consultar_ley, though it does not explicitly name those 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 conveys a clear use context: full-text search of legislation, with optional filters and a cost only when results are returned. It does not state explicit when-to-use vs when-not-to-use exclusions relative to sibling tools, but the context is strong enough to guide invocation.

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?

With no annotations provided, the description must carry the behavioral burden. It discloses that the result includes work-risk only conditionally, that the tool declares version and disclaimer, and that it refuses or does not calculate outside the loaded validity period. This is meaningful behavioral context, though rate limits, authentication, and exact response shape are not 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 short and front-loads the main purpose. Each sentence adds information about scope, cost, conditionality, or limitations, but the fragment 'Cuesta NOMINA' is ambiguous and slightly reduces clarity.

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 output schema, no annotations, and four parameters, the description is adequate but not complete. It provides the essential calculation purpose and limitations, but an agent cannot determine what happens when fecha_calculo falls outside the loaded validity period, what the response structure looks like, or what error behavior to expect.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the key parameter sbc_diario and explicitly ties prima_riesgo to the work-risk calculation. However, dias and fecha_calculo are not described beyond the indirect reference to vigencia cargada, leaving their exact meaning and formatting to inference.

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 calculates IMSS and Infonavit contributions based on the daily SBC. It is distinct from nearby siblings like calcular_isr and calcular_laboral by naming the exact contribution types and the core input.

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

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

The description gives clear context: this tool is for IMSS/Infonavit quotas over SBC, with work-risk contributions only when prima_riesgo is provided. It also states a hard limitation, 'no calcula fuera de la vigencia cargada', which helps the agent decide when this tool is applicable, though it does not explicitly name alternatives.

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?

With no annotations, the description carries the behavioral burden and does so well: it discloses the NOMINA cost, the edge case of dates outside the loaded table, and the caveat that the result is mathematical, not an official resolution. It does not explain authentication or rate limits, but for a calculation tool this is mostly sufficient.

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 concise sentences communicate purpose, cost, edge-case behavior, and result caveat. Every sentence carries distinct information and the most relevant facts are 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?

The description covers inputs, date-dependent behavior, billing, and output nature. Since there is no output schema, the exact return shape remains slightly unclear, but the tool is low-complexity and the core invocation details are present.

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

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

The description maps both parameters conceptually: 'base gravable' and 'para una fecha'. However, schema description coverage is 0%, and the description does not compensate fully by explaining the expected date format or what an empty fecha_calculo default means.

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 exact calculation: monthly payroll ISR under LISR article 96 on a taxable base for a date. This clearly distinguishes it from siblings like calcular_imss and calcular_laboral. It lacks an explicit verb, relying on the tool name and noun phrases, so it is not a perfect 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?

The description establishes a clear usage context: payroll ISR calculation on a taxable base for a date, and notes the cost in NOMINA credits. It does not explicitly mention alternatives or exclusion rules, but the domain-specific framing is enough to route an agent appropriately.

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?

No hay anotaciones, por lo que la descripción carga toda la responsabilidad. Revela que la operación tiene un costo ('Cuesta LABORAL'), que el resultado es matemático y no una resolución oficial, y que cada respuesta declara la tabla/versión usada. Son datos conductuales importantes para que el agente gestione expectativas y no presente el resultado como oficial.

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?

La descripción es una sola oración densa que pone al inicio el propósito y los conceptos válidos, luego agrega costo, deslinde y transparencia de versión. Es compacta y cada segmento aporta información, pero el encadenamiento con punto y coma la hace ligeramente difícil de parsear. Podría estructurarse mejor en frases separadas.

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

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

No hay esquema de salida, y la descripción menciona que la respuesta incluye desglose, fundamento y deslinde, lo cual ayuda. Pero con 9 parámetros y 0% de cobertura, no se explica qué parámetros aplican a cada concepto ni la estructura exacta del resultado. El agente puede no saber cuándo completar opciones como incluir_indemnizacion o dias_pendientes_salario, lo que deja brechas claras para una herramienta de cálculo con costo.

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?

La cobertura del esquema es 0% y la descripción solo aclara el parámetro 'concepto' enumerando sus tres valores válidos. Los otros 8 parámetros (fecha_ingreso, salario_diario, dias_pendientes_salario, etc.) quedan sin explicación, forzando al agente a depender de los títulos y valores por defecto. Esto no compensa suficientemente la falta de descripciones en el esquema.

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 usa un verbo específico ('Calculo') e identifica el recurso exacto: cálculo laboral mexicano bajo LFT, con los conceptos 'aguinaldo', 'prima_vacacional' y 'finiquito'. Esto la distingue claramente de herramientas hermanas como calcular_imss o calcular_isr, que apuntan a otros ámbitos.

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?

El texto delimita el uso a tres conceptos laborales concretos, lo que le dice a un agente cuándo invocarla. Sin embargo, no menciona explícitamente alternativas ni exclusions (por ejemplo, 'para IMSS use calcular_imss'), dejando esa diferenciación a la inferencia. El contexto es claro pero sin exclusiones explícitas.

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?

With no annotations, the description carries the full burden and does well: it discloses cost ('Es GRATIS'), scope limitation ('es el catalogo, no el contenido') so an agent won't expect full legal text, and the primary return value (document_id). It omits result limits, pagination, or empty-result behavior, but the most important expectation-setting traits are 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?

Three sentences, each earning its place: what the index contains, how to filter it, and what it returns plus cost. Front-loaded with the core purpose and logically ordered. Slightly denser than the tightest possible version due to parenthetical enumerations, but those enumerations add concrete value for an agent.

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

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

Despite no output schema and no annotations, the description tells the agent what to expect (document_id), how to invoke filters, and how to chain into consultar_ley, which is the critical integration. Remaining gaps are minor: exact return shape beyond document_id, result caps, and filter-combination semantics. For a catalog-lookup tool this is largely 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 there are no enums, yet the description compensates by mapping all four parameters: materia (Civil/Penal/Fiscal/Laboral/...), ambito (Federal/Estatal/Nacional), entidad, and q ('texto en el nombre'), including example values. It does not specify exact value formatting or how filters combine, but it covers the meaning of every 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?

States a specific verb and resource: 'Indice de legislacion mexicana disponible' covering Constitution, codes, federal/national laws and all 32 states. It distinguishes itself from sibling consultar_ley by explicitly stating it returns the document_id needed for that tool, and its domain (leyes) separates it from catalogo_servicios and consultar_catalogo.

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: the tool is the discovery step that yields 'el document_id que necesitas para consultar_ley', establishing a workflow. The 'Es GRATIS: es el catalogo, no el contenido' clause signals it is the cheap/preliminary lookup versus content retrieval. It does not name explicit exclusions or alternatives like buscar_ley, but the context is sufficient.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly says the catalog is public, requires no key, and is meant to be consulted before authentication or payment, which strongly implies a read-only, side-effect-free operation. It does not literally say 'read-only' or describe the response shape, but the framing is clear enough.

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 dense sentences, front-loading the core purpose ('Catalogo publico de servicios') before adding the no-key constraint and the payment models. Every sentence contributes distinct useful information with no fluff 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 tool with no annotations and no output schema, the description is remarkably complete: it explains what the catalog contains, that it requires no key, when to use it, and outlines the two payment models. The described contents double as the expected return information, so no critical context 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 zero parameters and 100% schema description coverage, so the baseline is 4. No parameter documentation is needed; the description appropriately focuses on the tool's content and access requirements instead.

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 a public catalog of RESET Verifica services and specifies exactly what it contains: what each service does, price, inputs, determinism, and payment method. It does not explicitly differentiate it from sibling tools like consultar_catalogo or consultar_precios, so it misses the top score.

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 an explicit intended use case: consult this catalog before authenticating or paying to decide whether RESET solves the user's problem, and it notes that no key is required. It does not name alternatives or state when not to use it, so it stops short of full usage 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?

With no annotations, the description carries the behavioral disclosure burden. It correctly surfaces that the operation costs DATO and points to consultar_precios, but it does not detail read-only implications, authentication needs, rate limits, or behavior on invalid keys. The cost disclosure is useful, yet other behavioral aspects remain undisclosed.

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: the first sentence immediately states the action and resource, followed by an efficient cost note. Every word contributes, with no redundancy or 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 4-parameter tool with no output schema and no annotations, the description gives a useful orientation but not a complete invocation guide. It lacks an explicit enumeration of valid 'tipo' values, the role of 'subtipo' is only implied, and the return format is not addressed. These are meaningful gaps for an agent selecting and calling the tool.

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

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

Schema coverage is 0%, so the description is the only source of parameter meaning. It adds value by linking 'clave' to SPEI banks, 'numero' to phone/LADA, and 'subtipo' possibilities via SAT catalog examples (regimen/uso_cfdi/forma_pago). However, it never explicitly maps 'tipo' to allowed values, leaving some inference required.

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

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

The description clearly states the verb 'Consulta' with a specific resource: 'un catalogo o dato oficial mexicano', and enumerates concrete use cases (SPEI bank via clave, SAT catalogs for regimen/uso_cfdi/forma_pago, and phone/LADA). This specificity differentiates it from sibling tools like validar_curp or validar_clabe, which target single verification purposes.

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

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

The description provides clear context for when to use the tool: any lookup of a Mexican official catalog or data point. It also routes to consultar_precios for cost details, but does not explicitly state when not to use it or mention alternative tools for overlapping cases, stopping short of a full usage-exclusion 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?

Sin anotaciones, la descripción asume la carga y lo hace bien: revela que cuesta LEGAL, remite a consultar_precios, advierte que no es asesoría jurídica ni copia certificada y que se debe verificar vigencia. No menciona detalles como autenticación o límites de tasa, pero para una consulta de lectura sencilla la transparencia es suficiente.

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?

Cada frase aporta información nueva y necesaria: contenido devuelto, cómo invocar, costo, y limitación legal. La información clave está al frente y no hay redundancia ni relleno.

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?

La herramienta es simple (2 parámetros, sin esquema de salida ni anotaciones) y la descripción cubre todos los aspectos necesarios para invocarla correctamente: parámetros, ejemplos, costo, deslinde y fuente de datos. No falta información crítica para el agente.

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 compensa por completo: explica el origen de documento_id (catálogo de leyes), da un ejemplo válido y aclara el formato del artículo, incluyendo casos como '49 Bis'. El agente puede construir la llamada correctamente sin abrir el esquema.

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 establece claramente que la herramienta devuelve el texto exacto de un artículo de ley mexicana con cita, ubicación, fuente oficial, fecha de reforma y deslinde. Esto la distingue de hermanas como buscar_ley, que implica búsqueda, y fija el recurso exacto: el número de artículo dentro de un documento.

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?

Incluye instrucciones precisas de uso: pasar documento_id proveniente de catalogo_leyes con un ejemplo concreto y el número de artículo con ejemplos ('1793' o '49 Bis'). No declara explícitamente cuándo NO usarla o cómo diferenciarla de buscar_ley, pero el contexto es claro por la naturaleza de 'texto exacto'.

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?

Since no annotations are present, the description carries the full transparency burden. It discloses that no key is required and that prices are in MXN with IVA included, but it does not describe the return shape, freshness, or error behavior. This is adequate but not rich.

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 compact sentence with no filler. The core scope (current prices, MXN, IVA included) is front-loaded, and the auth note follows without unnecessary detail.

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

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

For a zero-parameter tool the description is close to sufficient, but there is no output schema to compensate for the missing return-value details. An agent knows it will receive price data but not the format or scope of the table, so the description is adequate with a clear 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 has zero parameters, so parameter documentation is trivially complete in the schema. The baseline of 4 applies because there is nothing for the description to add about 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 identifies a specific resource: a current price table in MXN with IVA included. It lacks an explicit verb and does not distinguish itself from sibling tools such as consultar_ley or catalogo_servicios, so it misses the top score.

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 'No requiere llave' gives useful context that no authentication is needed, which helps an agent decide it can call the tool without secrets. It does not explicitly state when to prefer this over sibling catalog/consult tools, so usage guidance is only implied.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the operation has no cost and describes the returned data, and the name 'consultar_saldo' strongly implies a read-only query. However, it does not explicitly say that no data is modified or mention any access limitations or freshness of the latest movements.

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: the first sentence names the main result areas (balance, uses, expiration, movements), and the second sentence adds a key condition (no cost). Both sentences earn their place with no redundant filler.

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

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

For a simple, zero-parameter consulta tool, the description is nearly complete: it states what data is returned and that there is no cost. Since there is no output schema, it would benefit from a bit more detail on the response shape or the time range of 'últimos movimientos', but the current level is adequate.

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

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

The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to clarify about arguments. The description instead focuses on the result contents, which is appropriate for a parameterless tool.

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

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

The description clearly identifies the resource as 'saldo de paquete' and enumerates the returned content: individual uses per product, expiration dates, and latest movements. It is clear that this is a balance-query tool, though it does not explicitly distinguish itself from the sibling consultar_uso, which may overlap in scope.

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

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

No guidance is given on when to prefer this tool over alternatives such as consultar_uso or consultar_precios. The 'No tiene costo' note is useful but does not explain the intended use case or provide exclusions.

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?

With no annotations provided, the description carries the full burden. It adds useful behavioral context by stating the result is grouped by service and detail and that the call is free ('No tiene costo'). It does not explicitly state read-only behavior or describe limitations like missing data handling, but for a simple consumption query the disclosure is adequate.

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, front-loaded with the tool's core purpose, and adds only the essential parameter format and cost note. Every sentence contributes value with no 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 single-parameter query tool, the description covers purpose, result granularity, parameter format, and cost. It does not specify what happens when 'mes' is omitted, whether the month is required, or how current-period consumption is determined, leaving some ambiguity for an agent choosing whether to supply the parameter.

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 provides only the parameter name 'mes' with a default and no description. The description adds meaningful semantic value by specifying the required format AAAA-MM, which is essential for correct invocation. This compensates for the 0% schema description coverage.

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 the user's consumption for the period, broken down by service and detail. This identifies the specific resource and query nature of the tool, though it does not explicitly differentiate it from sibling tools like consultar_saldo or consultar_precios.

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: provide a month to see consumption for that period. The month format is given, and 'no tiene costo' indicates there is no cost barrier. However, there is no explicit guidance on when to choose this over related tools or any exclusions.

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?

No annotations are provided, so the description carries the full disclosure burden. It discloses that the tool returns specific payment details, that it has no cost, that the only charge is the SPEI deposit, and that amounts must follow minimum/multiple rules. It does not cover persistence, reversibility, or permissions, but the core behavior is transparently described.

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. Key output information is front-loaded, and conditional parameter usage is packed into the second sentence efficiently. Every clause adds useful information.

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

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

Given there is no output schema and no annotations, the description provides the key return values, cost expectations, and conditional parameter requirements. The main gap is that the conditional requirement of `servicio` and `cantidad` for `tipo='individual'` is not reflected in the schema, and `cantidad` semantics are not fully explained, but the description is still mostly complete for a caller.

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

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

Schema description coverage is 0%, but the description compensates well by explaining the meaning of `tipo`, the valid service values (COMPANY/CFDI/SPEI/COMBO/UTIL), and the constraints for `monto` (MXN, minimum 500, multiples of 100). It leaves `cantidad` somewhat implicit and does not fully define the relationship between `cantidad` and `servicio`, but it adds substantial meaning beyond the raw schema.

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

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

The description states a specific verb and resource: 'crea una orden de fondeo por SPEI' and names the exact return values (referencia, CLABE, beneficiario, monto exacto). It also distinguishes this SPEI-based funding order from the sibling tool crear_fondeo_x402, making it clear which tool is being described.

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 by defining the two `tipo` modes, 'paquete' and 'individual', and their required parameters and constraints. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5, but the guidance is practical and sufficient for 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?

With no annotations, the description carries the full burden and does well: it discloses that the tool creates an order, returns payment requirements, and requires a separate settlement step with a specific endpoint and X-PAYMENT header. This gives an agent a clear picture of the tool's role and side-effect-free immediate behavior, though it does not discuss expiration, idempotency, or authentication.

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 and front-loaded: the main function appears in the first sentence, followed by useful workflow guidance and parameter constraints. Every sentence adds value, and there is no repetitive or filler content.

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

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

For a one-parameter tool with no output schema, the description is remarkably complete: it explains what the tool returns (exact USDC amount, address, reference), what to do with those values (pay with wallet, settle with endpoint/header), and the input requirements. An agent has enough context to call and continue the workflow 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 description coverage is 0%, so the description must compensate. It adds critical constraints: 'monto_mxn: multiplo de 100, minimo 100', which the schema alone does not convey. It does not explicitly state the currency, but the parameter name and larger context make that reasonably clear.

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 specific action: 'Crea una orden de fondeo pagadera con x402 (USDC en la red Base)'. It identifies the resource (fondeo order), the payment method (x402/USDC), and the network (Base), which distinguishes it from sibling tools like crear_fondeo without additional ambiguity.

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 context by describing the full workflow: create an order, pay, then settle with the given endpoint and header. However, it does not explicitly state when to prefer this tool over alternatives like crear_fondeo or provide exclusions, so the guidance is mostly implied rather than explicit.

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?

With no annotations, the description carries the transparency burden. It discloses that the tool returns a folio, that the folio is freely verifiable via validar_constancia, and that there is no extra cost, which goes beyond the bare schema. It does not mention idempotency or failure cases, but for a one-parameter issuance tool the core behavior is reasonably transparent.

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, information-dense sentences. The action comes first, followed by the precondition, the return value, the validation path, and the cost implication, with no repetition of the tool name or schema details.

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 no output schema, the description covers purpose, precondition, parameter meaning, return value, and cost. It is slightly incomplete around where verification_id comes from and whether multiple receipts can be issued for the same verification, but these are minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that verification_id refers to a verification the user already completed, which adds context beyond the raw property name. However, it does not explain where to obtain the ID or any expected format, leaving some inference required.

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 and resource ('Emite una constancia') and clearly scopes the operation to a verification the agent already performed, identified by verification_id. It also distinguishes itself from the sibling validar_constancia by framing the returned folio as what that sibling validates.

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 states the precondition clearly: only emit for a verification that has already been done ('de una verificacion que ya hiciste'). It also names validar_constancia as the validation route, giving useful workflow context, though it does not explicitly list which sibling tools are not appropriate.

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?

There are no annotations, so the description carries the burden. It discloses that no key is needed and describes the scope of information provided. It does not mention response format, freshness guarantees, or side effects, but this is a low-risk status lookup tool.

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

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

The description is a single, compact sentence that leads with the main purpose and adds the key invocation detail at the end. It contains no filler or redundant wording.

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 parameterless status tool, the description adequately explains what the tool reports and the authentication requirement. It does not describe the output format, but the complexity is low and there is no output schema to complement.

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 parameter explanation is unnecessary. The description still adds useful invocation context by explicitly stating that no key is required.

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 reporting service status and official SAT tables/updates, with concrete examples like list updates, table validity, and catalog versions. It is distinguishable from sibling lookup/service-catalog tools because it is about status rather than searching or validating.

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 relevant context for when to use the tool ('service status' and official table timing) and states the key requirement 'No requiere llave'. However, it does not explicitly mention alternatives or when not to use this tool versus sibling 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?

No annotations are provided, so the description must carry the behavioral burden. It only says the tool 'registers' an obligation and has no cost; it does not disclose persistence effects, reversibility, permissions, idempotency, or what the response will be. This is a notable gap for a mutation tool.

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

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

The description is short, front-loaded, and every sentence adds information: what is registered, the conciliation purpose, and the cost implication. There is no redundancy or 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 simple 2-parameter tool with no output schema and no annotations, the description still lacks parameter-level guidance and expected result behavior. An agent might know the intent but not how to supply valid inputs or interpret success.

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 must compensate. It does not explain what 'monto' or 'referencia' mean, their formats, or their roles beyond the schema names. The conciliation context weakly implies their purpose, but no real parameter semantics are added.

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 verb 'Registra' plus the resource 'obligacion (cuenta por cobrar)' clearly states what the tool does, and the phrase 'para conciliarla despues contra un pago' adds a specific purpose. It is reasonably distinguishable from siblings like verificar_pago or validar_clabe, though it does not explicitly contrast 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?

The description implies usage: it is for recording an account receivable that will later be reconciled against a payment. The 'No tiene costo' note adds practical context. However, it does not state when to prefer this tool over alternatives or when not to use it.

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

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

With no annotations to carry behavioral information, the description fully discloses what the tool returns (matches scored 0-100, one record per list), the consumption cost (SCREEN), the base64 PDF certificate behavior, and a legal caveat about due diligence. This goes far beyond a minimal 'screen lists' statement.

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 every phrase adds meaning: purpose, parameter usage, output shape, cost, and legal caveat are all stated with no repetition. It is front-loaded with the action and scope.

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?

Without an output schema, it still describes the result format enough for an agent to anticipate what it will receive. It also covers all input parameters, the list sources, country scope, cost, and the tool's limitation as evidence, so the definition is complete 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 0%, so the description is the only source of parameter meaning. It explains name, optional country with ISO format example, tax_id for national matching, and certificate=true for a PDF base64 output, covering all four declared 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 opens with a specific action and object: screening a name or entity against sanctions, PEP, and national lists. It enumerates the exact lists and countries, making the tool's purpose unmistakable and clearly distinguishing it from one-off verification or monitoring 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?

It clearly communicates the screening use case, the optional cross-checks, and the certificate option, and adds the caveat that it is evidence rather than compliance certification. It does not explicitly name alternatives or say when not to use it, though the purpose statement implies when it applies.

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?

With no annotations, the description carries the full behavioral burden. It does disclose the key asynchronous behavior: results are delivered via a signed webhook only when a NEW match appears, not synchronously. It also notes that webhook registration is separate and that enrollment is free. It does not detail the immediate API response or webhook payload structure, but core behavioral expectations are set.

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. The first sentence states the core behavior; the following sentences cover required inputs, webhook registration, and cost. Every sentence contributes necessary information without redundant filler.

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

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

Given no annotations and no output schema, the description leaves important gaps: it does not explain what the API call returns (e.g., immediate ack status, webhook ID), how to register the webhook endpoint, the shape of the signed webhook payload, or whether matches are one-time events or repeated. The tool's async nature is clear, but the operational workflow is under-specified.

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 names the parameters ('name', optional 'country' and 'tax_id') but only restates their optionality, which is already visible in the schema defaults. It does not explain what 'tax_id' or 'country' do to the monitoring logic, nor what formats are expected.

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 ('Vigila') and resource ('un nombre'), and clearly states the tool's core function: sending a signed webhook when a new match appears in sanctions, PEP, or national lists. This implicitly distinguishes it from sibling screening_listas, which likely performs one-time lookups.

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

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

Clear context is provided: this tool is for ongoing monitoring rather than one-off screening, with webhook delivery of new matches. Prerequisites like registering the webhook endpoint are mentioned. It does not explicitly rule out when to use a sibling tool like screening_listas, but the monitoring posture 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?

There are no annotations, so the description carries the full behavioral burden. It discloses a cost side effect ('Cuesta DATO') and the output shape ('Devuelve la fecha del dato y la serie oficial'). However, it does not clarify default behavior when no date is supplied, whether the converted amount is returned when monto is provided, or possible error cases.

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 purpose, then adds optional parameters, cost, and return value. Every phrase earns its place, with no redundant exposition.

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 tool with two optional parameters, no output schema, and no annotations, the description covers the essential aspects: what the rate is, the optional inputs, the cost, and the returned data. Remaining gaps like date format and default behavior are 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It does add value by tying 'fecha' to date filtering and 'monto' to amount conversion, and by marking both as optional. It does not specify the expected date format or the semantics of an empty/default date, which leaves some 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 resource: the official Banxico FIX exchange rate for USD/MXN, with optional date filtering and amount conversion. It also states the return value ('Devuelve la fecha del dato y la serie oficial'). It lacks an explicit verb like 'obtener' or 'consultar', but the intent is unmistakable and distinct from the sibling tools.

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

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

The description explicitly marks both parameters as optional ('por fecha (opcional) y con conversion de un monto (opcional)'), giving clear context for when to use the tool and how to vary the call. It does not name alternatives or exclusions, but none of the siblings appear to provide the same exchange-rate functionality.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It is transparent about the tool's scope, mentions the cost 'Cuesta UTIL', and explicitly warns that it does not confirm account existence. This goes well beyond a bare functional statement, though it could also disclose return behavior or errors.

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 deliver the core purpose, a cost caveat, and a key limitation with no filler. The most important information is front-loaded 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?

The tool is simple with one parameter and no output schema, and the description covers its scope, cost, and limitation. The only notable gap is that it does not describe the result format or how an agent should interpret the validation outcome.

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 gives no description for 'clabe', so the description must compensate. It does so by explaining the validation criteria and implicitly clarifying that the parameter is the CLABE number to be validated. It adds meaning beyond the schema, though it could explicitly specify the required string format.

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

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

The description clearly states the verb 'Valida' and the specific resource 'estructura de una CLABE' with concrete validation criteria: 18 digits, check digit, and bank by prefix. This distinguishes it from sibling validators like validar_curp or validar_rfc without needing to inspect the 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?

No guidance is provided about when to choose this tool over alternatives or when not to use it. The caveat 'No confirma que la cuenta exista' is useful but does not name any alternative validation or verification tool for checking account existence.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the operation is public, requires no authentication key, has no cost, and confirms whether a verification existed along with the time and result. This adds meaningful behavioral and outcome context beyond the bare tool name.

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

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

Two concise sentences front-load the core action and scope, then add the result semantics and access conditions. Every clause earns its place with no redundant or filler content.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers purpose, access requirements, cost, and the nature of the outcome. It does not specify exact return fields or error behavior, but the tool is simple enough that the description is largely 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?

Schema description coverage is 0%, and the description only refers to the folio parameter as 'por su folio', which largely restates the property name. It does not explain what a folio is, its format, where to find it, or any examples. The description fails to compensate for the missing schema-level parameter 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?

The description clearly states the verb (Valida), the resource (una constancia), and the method (por su folio), and distinguishes this from other validation tools by specifying the certificate type and the public nature. It also explains what the validation confirms: the existence, time, and result of the verification.

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 by noting that no key is required and there is no cost, which helps an agent decide when this public validation tool is appropriate. However, it does not explicitly name alternatives or state when not to use this tool, such as when needing to emit a constancia instead.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states what the tool checks and explicitly declares that it does not confirm the RENAPO registry, which is valuable context. It does not mention invalid-input or error behavior, so some behavioral ambiguity remains.

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

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

Two compact sentences, front-loaded with the core action and scope, followed by billing and limitation context. Every sentence earns its place and there is no repetition or 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 covers purpose, billing context, and the key RENAPO limitation, which is sufficient to begin invoking the tool. However, with no output schema and no annotations, it does not describe what the tool returns or how invalid CURPs are reported, leaving a meaningful gap in the agent's understanding of the result contract.

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 a single 'curp' parameter with no description, and the tool description does not provide a format, example, or constraints. However, 'Valida una CURP' plus the enumerated validation steps makes the expected input reasonably clear. A format example or length requirement would add meaningful value.

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 a specific resource ('CURP') and enumerates the exact validation aspects: formato, dígito verificador, and decodificación. The closing exclusion about RENAPO clearly distinguishes it from broader 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?

Provides clear context ('Incluido con saldo de paquete') and an explicit when-not ('No confirma registro ante RENAPO'), telling an agent not to use it when registry confirmation is required. It stops short of naming a specific alternative sibling, so it does not fully meet the 5-level bar.

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?

With no annotations, the description takes on the full burden. It discloses the core behavior (format and Luhn digit validation) and a key limitation (no IMSS affiliation check), but does not mention output response, error behavior, or any side effects. For a read-only validation this is adequate but not thorough.

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 the main purpose front-loaded. The second sentence, 'Incluido con saldo de paquete', adds a billing context that is not directly relevant to invocation, but overall the description is tight.

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 no annotations and no output schema, the description covers purpose and limitation but omits the expected input format and return value. It is minimally viable but leaves the agent uncertain about output and exact input syntax.

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 expands the abbreviation 'NSS' to 'numero de seguro social', but does not specify the expected format, length, or examples beyond mentioning a Luhn digit. The agent must guess the input shape.

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), resource (NSS), and exact checks (formato y digito Luhn). The tool is clearly distinguishable from sibling validators like validar_curp or validar_rfc because it names NSS and its specific algorithm.

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 includes one explicit exclusion: 'No confirma afiliacion ante el IMSS', which tells the agent when not to use it. However, it does not name alternative tools for affiliation confirmation nor describe positive scenarios for selecting this tool over 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?

No annotations are provided, so the description carries the full burden. It discloses the tool's scope positively (what structural validations are performed) and negatively (no SAT registration check), and notes it is included with package balance. This is appropriate for a read-only validation tool, though it does not describe the 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?

Two sentences, front-loaded with the core purpose and followed by limitation and billing context. 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 one-parameter validation tool with no annotations and no output schema, the description covers the essential context: what is validated, what is not validated, and cost implication. It lacks a description of the return value, but this is a minor gap for a validator.

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 single parameter 'rfc' has no schema description (0% coverage), so the description must compensate. It does so by defining the parameter's role—the RFC whose structure is validated—and by listing the validation dimensions. It does not specify the expected string format, but that is secondary.

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 ('la estructura de un RFC'), enumerating exactly what is checked: formato, tipo de persona, fecha y digito verificador. It also sets a clear scope boundary by explicitly saying it does not confirm SAT registration, distinguishing it from verification-focused 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 implies when to use the tool (for RFC structural validation) and provides an explicit when-not: 'No confirma que este registrado ante el SAT.' However, it does not name an alternative tool for SAT registration checks, so the guidance is clear but incomplete on substitution.

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?

With no annotations provided, the description carries the full transparency burden. It discloses that the full PAN is not stored, that only Luhn/BIN/brand are checked, and that account/funds are not confirmed. It omits response behavior and side effects, but the key privacy and scope caveats are present.

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, front-loaded with the core action, and each sentence adds useful information. The 'saldo de paquete' sentence is somewhat peripheral to actually invoking the tool, and the phrasing is a bit staccato, so it is not a perfect 5.

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

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

For a one-parameter validator, the description covers the input and the tool's boundaries well. However, since there is no output schema, the lack of any hint about the result shape (boolean vs validation details) is a real gap, and the package-balance requirement is ambiguous.

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

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

The schema has one required string parameter with 0% description coverage, so the description must compensate. It clarifies that the pan property is the card number to send and notes that the full number is not retained. It does not provide format, length, or accepted input examples, leaving some 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 names the exact resource ('tarjeta') and the validation method (Luhn + BIN + marca). This is enough to clearly distinguish it from sibling validators like validar_clabe, validar_curp, validar_nss, and validar_rfc, even without naming them explicitly.

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

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

It provides a clear boundary: the tool validates only Luhn/BIN/brand and explicitly does not confirm account or funds, so an agent can tell when not to use it. It does not name an alternative tool or give a direct when-to-use rule, so it stops short of a 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?

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose that this is a combined transactional operation with a bundled/combo price, which is useful. However, it does not explain side effects, output behavior, failure modes, or any prerequisites beyond the parameters.

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 short, front-loaded, and mostly efficient. The main redundancy is that 'a precio combinado' and 'Cuesta COMBO' both communicate cost information, but the overall length is still appropriate.

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

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

This is a combined 4-parameter tool with no output schema, no annotations, and no parameter descriptions in the schema. The description gives the inputs and the bundling concept but omits what the agent should expect in the result, how XML contents are used, and any additional context needed to invoke the tool 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 description coverage is 0%, so the description must compensate. It usefully maps rfc to 'empresa', cfdi_xml to 'factura (XML CFDI)', and cep_xml to 'pago (XML CEP)', which covers the required parameters. However, the optional 'refs' parameter is not explained at all.

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 combined operation: company verification by RFC plus invoice (CFDI XML) plus payment (CEP XML) in a single call. It also distinguishes itself from the individual sibling tools like verificar_empresa, verificar_factura, and verificar_pago by explicitly labeling itself a COMBO.

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 conveys that this tool should be used when all three verifications are needed together, and that it is priced as a bundle. It does not explicitly name the individual alternatives, but the sibling list and the 'en una sola operacion' wording make the intended use case 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?

With no annotations provided, the description carries the behavioral burden. It discloses that the tool costs COMPANY and that results reproduce official sources, which is useful. However, it does not mention whether the operation is read-only, expected output format, or any side effects, leaving a gap for a no-annotation tool.

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

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

The description is compact and well-structured: the first sentence front-loads the core scope and data sources, the second states cost and result fidelity. Every clause adds meaningful information, with no fluff 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?

The description gives a solid high-level overview, but is incomplete for correct invocation: no explanation of the 'sancionados' parameter, no RFC format guidance, and no output schema or return value description. Given no annotations and no output schema, more detail is warranted.

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 clearly references the 'rfc' parameter, but does not explain the 'sancionados' boolean at all, leaving its meaning and effect ambiguous. This is a significant gap for the agent trying to set parameters correctly.

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 ('Verifica') and a clear resource ('persona moral o fisica por RFC'), followed by a detailed list of what is checked (SAT 69-B, articulo 69, contratacion publica, sancionados). This distinguishes it well from siblings like validar_rfc (simple validation) and screening_listas (focused list screening).

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

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

The description provides clear context for when to use the tool: to verify a legal or physical person by RFC across multiple official data sources. It does not explicitly name alternative tools or when-not-to-use conditions, but the coverage of distinct data categories gives the agent strong situational grounding.

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?

There are no annotations, so the description carries the behavioral burden. It discloses that this is a live SAT validation, includes a 69-B check, and that the operation costs 'CFDI' credits, which is useful behavioral context beyond the basic action. It does not detail return values or failure modes, but the 'valida' framing makes the non-mutating nature reasonably clear.

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 concise sentences with no filler: the purpose comes first, followed by the single input instruction and the cost warning. It repeats nothing from the schema or annotations and earns every word.

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 no output schema, the description is largely complete: it names the validation checks, tells the agent what to send, and flags that the call is not free. The main omission is a clear statement of what the response will look like, but the validation nature makes that outcome fairly predictable.

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 zero schema description coverage for the only parameter, the description compensates by stating that the 'xml' field should receive the CFDI's XML. This gives real semantic meaning to the parameter, though it does not specify encoding, size limits, or whether the raw XML string is expected.

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 'Valida un CFDI' and specifies the exact validation checks: official XSD Anexo 20, live SAT status, and the issuer's 69-B cross-reference. This clearly identifies the resource and scope, distinguishing it from sibling tools like validar_rfc or verificar_empresa.

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 input instructions ('Envía el XML del CFDI en xml') and implies the use case, but it never explicitly states when to prefer this tool over alternatives or when not to use it. The agent must infer the choice from the resource type rather than being told.

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?

No annotations are provided, so the description must carry the behavioral burden. It does reveal that the tool processes and reconciles and that it has a SPEI cost, but it leaves unclear side effects, reversibility, required permissions, and the response shape. That is a meaningful gap for a financial operation, but the description is not silent about 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?

The description is short and front-loaded, with no redundant filler. The final 'Cuesta SPEI.' is compact but cryptic, and the overall structure is efficient without being overly sparse.

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

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

For a simple two-parameter tool with no output schema, the description gives enough to invoke it correctly with the required xml parameter. However, with no annotations and no output schema, it should say more about the result, side effects, and cost implications than it currently does.

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 compensates by mapping 'xml' to the CEP XML and 'refs' to optional references to reconcile. This adds real meaning beyond the bare schema, though the exact format of 'refs' remains vague.

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

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

The description names a specific operation: 'Procesa un CEP (comprobante SPEI)' and 'lo concilia contra tus obligaciones registradas'. This clearly distinguishes it from sibling verification/validation tools, which target different document types or entities.

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 implies the tool is for processing a SPEI CEP and reconciling it with registered obligations, and it gives concrete instructions to pass the XML and optionally refs. It does not name alternatives or say when not to use it, but the intended context is easy to infer.

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