Server Quality Checklist

Tool Scores

• es__generate_b2b_einvoice_esC
  2.9/5.0
  Behavior2/5

  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 adds regulatory context and notes that the ministerial order is pending, which is a useful caveat, but it does not disclose what side effects generation has, whether validation occurs, what permissions are needed, or what the output looks like.

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

  Conciseness4/5

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

  The first sentence is concise and front-loaded with the essential purpose and formats. The subsequent legal/regulatory sentences add relevant context but are somewhat tangential to invoking the tool correctly; still, they do not make the description bloated.

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

  Completeness3/5

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

  The tool is moderately simple: two parameters, one required nested object, and an output schema exists. However, the description does not explain the expected invoice structure or how to select the format in practice, and it leaves the pending legal status unresolved without clarifying impact on usage.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds useful mapping between the format parameter values and UBL 2.1/Facturae 3.2.2, but it still leaves the 'invoice' object opaque and does not explain what fields are expected despite additionalProperties allowing anything.

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

  Purpose4/5

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

  The description states a specific verb ('Genera'), a clear resource ('factura B2B conforme a EN 16931'), and the two supported output formats ('UBL 2.1 o Facturae 3.2.2'). This clearly differentiates it from unrelated sibling tools like SII or Verifactu, though it does not explicitly contrast with overlapping tools like generate_facturae_xml.

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

  Usage Guidelines2/5

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

  The description references the Spanish 'Crea y Crece' law and the published RD 238/2026, implying this is for Spanish B2B e-invoicing, but it never explicitly states when to prefer this tool over alternatives such as generate_facturae_xml or validate_facturae_schema. It also gives no guidance on choosing between 'ubl' and 'facturae'.

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

• es__get_compliance_statusB
  3/5.0
  Behavior3/5

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

  With no annotations, the description itself must carry behavioral disclosure; 'Devuelve' signals a read-only query and the caveat about RD-ley 15/2025 warns that output is subject to future legal changes. It does not address side effects, authentication, or data freshness, but for a status lookup this is a reasonable minimum.

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

  Conciseness5/5

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

  Two short sentences with no filler; the core return value is front-loaded and the legal caveat adds relevant context without redundancy.

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

  Completeness3/5

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

  The description is complete enough for a basic read-only lookup thanks to full schema coverage and an output schema, but the ambiguous 'sistema operativo' and lack of usage context leave meaningful gaps for an agent deciding whether and how to call the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents entity_type, province_code, enrolled_in_sii, and annual_turnover_eur. The description adds no parameter-specific meaning beyond 'perfil de empresa', so it stays at the baseline.

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

  Purpose3/5

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

  The description states a concrete verb ('Devuelve') and a resource (compliance deadlines and 'sistema operativo') for a company profile, which broadly separates it from the invoicing/SII/Verifactu siblings. However, 'sistema operativo' is ambiguous in a tax-compliance context and could be read literally as 'operating system', so the exact purpose is not fully clear.

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

  Usage Guidelines2/5

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

  There is no guidance on when to call this tool instead of the many sibling tools, nor any exclusions or prerequisites. The only context is 'para un perfil de empresa' and the RD-ley 15/2025 reference, which implies a regulatory-compliance use case but does not help an agent select among alternatives.

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

• es__generate_sii_correctionB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It usefully indicates that the tool generates a record rather than submitting it, and adds the linking behavior via IDFactura. However, it does not disclose whether the record is validated, persisted, or expected to be submitted later, which leaves some ambiguity.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. The main purpose is front-loaded, and the second sentence adds a key referencing detail. Every sentence earns its place.

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

  Completeness3/5

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

  Given a complete input schema and output schema, the description is structurally adequate for invocation. But it misses workflow context: it does not tell the agent whether the generated correction record must subsequently be submitted via submit_sii_batch, nor does it clarify when to choose this over sibling tools. These are meaningful gaps for an agent operating among many related SII tools.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that the original invoice should be referenced via IDFactura, which clarifies how to populate the original_invoice object. It also reinforces that a cancellation (A4) omits corrected_invoice, matching the schema's own guidance.

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

  Purpose4/5

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

  The description clearly states the action ('generates an SII modification record A1 or cancellation A4') and identifies the resource ('references the original invoice via IDFactura'). It differentiates the tool from ordinary SII generation by emphasizing correction and cancellation, though it does not explicitly name a sibling alternative.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. With 19 sibling tools, the description does not say 'use this for corrections, use build_sii_invoice_record for originals, or submit via submit_sii_batch.' The intended usage is only implied by the name and brief description.

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

• es__check_b2b_mandate_applicabilityA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It does disclose a meaningful behavioral trait — 'Aplica la lógica de exclusión mutua del Real Decreto 254/2025' — which tells the agent the tool returns a single mutually-exclusive regime. It does not state whether the computation is local, synchronous, or side-effect free, which for a determination tool is a moderate but not critical gap.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: the first surfaces the purpose, the second enumerates the regimes and inputs, the third states the governing legal logic. The purpose is front-loaded and there is no filler or redundant restatement of the tool name.

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

  Completeness4/5

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

  Together, the description, input schema, and output schema cover the decision scope, decision inputs, mutual-exclusion rule, and return structure. The main omissions are the absence of any guidance on how this tool relates to the overlapping sibling es__detect_regional_regime, and the entity_type input not being woven into the narrative — though the schema adequately documents it.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all four parameters already carry types, defaults, and constraints, meeting the baseline. The description adds modest conceptual value by tying turnover, province code, and SII enrollment to the regime-decision logic, but it provides no additional format or constraint details beyond what the schema already contains.

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

  Purpose4/5

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

  The description states a specific verb and resource — 'Determina el régimen de facturación electrónica aplicable' — and enumerates the exact regimes covered (VERI*FACTU, SII, TicketBAI, NaTicket) along with the decision inputs. This is clear, but it does not explicitly differentiate from the closely named sibling es__detect_regional_regime, which appears to overlap on regional-regime detection.

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

  Usage Guidelines3/5

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

  The usage context is implied by listing the decision drivers ('a partir del volumen de operaciones, código de provincia y enrolamiento en SII'), which suggests an agent should call this when those data are available and a regime determination is needed. However, there is no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as es__detect_regional_regime, leaving selection among the siblings to inference.

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

• es__query_sii_statusA
  3.6/5.0
  Behavior3/5

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

  No annotations are present, so the description must carry the safety/behavior burden. It does convey that this is a read-only query ('Consulta') and that it invokes a SOAP envelope, which adds useful context. However, it does not mention authentication requirements, external AEAT communication, error behavior, or side effects.

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

  Conciseness3/5

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

  The first sentence is a strong front-loaded purpose, but the 'ES-LC-2: reemplaza el REST GET...' line is an internal/legacy note that does not help an agent select or invoke the tool. The filtering sentence is useful, but the ticket reference keeps this from being fully concise.

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

  Completeness4/5

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

  With a complete input schema and an output schema present, the description does not need to spell out return values or parameter formats. It names the SOAP service and the filter dimensions. It is adequate for a read-only query tool, though it would benefit from a note about the record_type/emisor_nif relationship.

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

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description's filter line restates a subset of parameters (ejercicio, periodo, NIF emisor, numero factura) but adds no comparison to the schema. It also omits the schema's nuance that emisor_nif is only for received.

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

  Purpose5/5

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

  The description opens with a concrete verb ('Consulta') and a specific resource ('estado de facturas en el SII'), and names the exact SOAP operation. This is enough to distinguish it from sibling tools like es__query_verifactu_status and es__get_face_invoice_status.

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

  Usage Guidelines3/5

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

  The description implies the tool is for querying SII invoice status but does not state when to prefer it over the sibling query/status tools, nor mention any exclusions. The 'ES-LC-2' note is a developer ticket reference, not usage guidance for an agent.

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

• es__build_sii_invoice_recordA
  3.7/5.0
  Behavior3/5

  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 clearly states what the tool constructs and the specification it follows, but does not mention whether it validates input, whether it submits anything to AEAT, or whether it requires authentication/signing before use. For a builder tool, the lack of an explicit 'does not submit' statement leaves some ambiguity.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the primary purpose in the first sentence. The second part adds only high-value context about the SII version and supported communication types. No filler, no repetition of schema details beyond what is useful for orientation.

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

  Completeness3/5

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

  The description is adequate for a builder tool with a rich output schema, but it omits the crucial relationship to sibling submission tools. An agent could not tell from this description alone that this tool only builds the XML record and does not submit it to AEAT, nor that the resulting record should be used with submit_sii_batch. Given the large sibling family, that contextual link is important.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description somewhat redundantly restates record_type ('FacturaExpedida/FacturaRecibida') and communication_type (A0/A1/A4) which the schema already explains, but it does not add any meaningful detail about the invoice object structure or the exact XML fields. It neither improves nor harms parameter clarity.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Construye un registro XML AEAT SII en formato SOAP' (builds an AEAT SII XML record in SOAP format). It immediately distinguishes this from siblings like generate_facturae_xml or generate_verifactu_record by naming the SII domain and the SOAP format, and adds scope details (issued/received, A0/A1/A4).

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

  Usage Guidelines3/5

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

  Usage context is implied through the supported record types and communication modes, which tells an agent that this tool is for building SII invoices rather than for submission or status queries. However, it never explicitly explains when to use this tool instead of siblings such as submit_sii_batch, generate_facturae_xml, or generate_verifactu_record, nor does it name alternatives for exclusion.

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

• es__cancel_verifactu_recordA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that the tool generates a cancellation record and that it is chained to the existing hash sequence, which is useful. However, it does not clarify whether this is a local generation, whether it mutates stored state, or whether any submission side effect occurs.

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

  Conciseness5/5

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

  The description is extremely concise: two short sentences, both informative. It front-loads the core purpose and then adds the chaining constraint without any filler.

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

  Completeness3/5

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

  The description is adequate for a tool with a rich input schema and an output schema, but it lacks explicit guidance on when to use it versus siblings and does not describe behavioral side effects. For a complex VERI*FACTU cancellation workflow, slightly more context would be beneficial.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents all parameters clearly. The description adds no extra parameter-level meaning, but it does not need to because the schema is self-sufficient.

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

  Purpose5/5

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

  The description clearly states a specific action: generating a VERI*FACTU cancellation record with TipoHuella=01. It distinguishes itself from the sibling generate_verifactu_record by identifying this as an annulment record rather than a normal record.

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

  Usage Guidelines3/5

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

  The description implies usage context by noting the record is chained to the current hash sequence, which tells the agent that previous_hash must be from the latest record. However, it does not explicitly state when to prefer this tool over alternatives such as generate_verifactu_record or validate_verifactu_record.

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

• es__get_face_invoice_statusA
  3.8/5.0
  Behavior3/5

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

  Sin anotaciones, la descripción comunica que es una consulta ('Consulta') y aporta los códigos de estado posibles, lo cual ayuda a interpretar el resultado. No detalla comportamientos ante identificadores inválidos, requisitos de autenticación ni efectos secundarios, pero el esquema de salida disponible cubre parcialmente la forma del retorno.

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

  Conciseness5/5

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

  Dos frases breves y al grano; la acción y el objeto están al inicio y los códigos se presentan sin redundancia. No hay contenido sobrante.

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

  Completeness4/5

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

  Para una consulta de un solo parámetro con esquema de salida disponible, la definición cubre el propósito y la interpretación de los códigos de estado. Carece de una guía explícita sobre cuándo usarla frente a otras herramientas de estado, pero eso no bloquea la invocación correcta.

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

  Parameters3/5

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

  El esquema ya documenta el único parámetro con 100% de cobertura ('Número de registro FACe'), así que la descripción no necesita añadir semántica. El valor añadido son los códigos de estado, que no son parámetros.

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

  Purpose5/5

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

  La descripción comienza con un verbo específico ('Consulta') y un recurso claro ('el estado de tramitación de una factura en FACe'), lo que permite distinguirla de herramientas hermanas como query_sii_status o query_verifactu_status. Incluye códigos de estado, reforzando el propósito.

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

  Usage Guidelines3/5

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

  El uso se infiere claramente del contexto FACe, pero no se indica explícitamente cuándo preferir esta herramienta frente a otras consultas de estado ni se mencionan exclusiones o alternativas.

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

• es__generate_facturae_xmlA
  4/5.0
  Behavior3/5

  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 discloses that the generated document is unsigned and intended for FACe, but it does not mention side effects, validation behavior, or whether any network/auth involvement occurs.

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

  Conciseness5/5

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

  The description is two short, front-loaded sentences. The first states purpose and scope; the second adds the essential signing caveat. No wasted words.

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

  Completeness4/5

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

  Given the complex input schema and presence of an output schema, the description covers the key missing context: the generated XML is unsigned and should be signed next. It does not explicitly mention submission to FACe or schema validation, but those are represented as sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the rich parameter descriptions already carry the semantic load. The tool description itself adds no parameter-level detail, which is acceptable under the baseline for full schema coverage.

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

  Purpose5/5

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

  The description states a specific verb ('Genera'), a concrete resource ('factura XML conforme a Facturae 3.2.2'), and a clear scope ('para envío B2G al portal FACe'). It also differentiates from the signing sibling by explicitly noting the document is unsigned.

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

  Usage Guidelines4/5

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

  The description gives clear context: use this tool to generate an unsigned Facturae XML for B2G/FACe, then use es__sign_facturae_xades. It does not explicitly mention when not to use it versus validate/submit tools, but the core alternative is named.

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

• es__generate_qr_verifactuA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and it does well: it states the output format (PNG base64), the legal basis, and the exact URL pattern being encoded. It does not go into error cases or whether the tool performs any network call, but 'encodes' strongly implies a local generation, which is adequate for this simple generator.

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

  Conciseness5/5

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

  Two short sentences front-load the core action and output format, then provide the exact encoded URL. There is no filler or repetition of schema content.

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

  Completeness4/5

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

  For a simple QR generator, the description covers purpose, output type, and legal context. An output schema is present, so return-value details are not required. It is slightly incomplete only in not addressing when the QR should be used relative to the broader VeriFactu workflow.

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

  Parameters3/5

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

  The input schema already provides 100% parameter coverage, so the baseline is 3. The description adds context that the parameters feed the AEAT verification URL, but it does not map individual parameters or add details beyond the schema.

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

  Purpose5/5

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

  The description names a specific action, resource, and output: it generates the mandatory VERI*FACTU QR code (HAC/1177/2024 Art. 10) as a base64 PNG. It also states exactly what the QR encodes (the AEAT verification URL), which differentiates it from the sibling tools that generate XML records, sign documents, or submit batches.

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

  Usage Guidelines3/5

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

  The usage is implied by the purpose: an agent can infer this tool is for producing the QR image to include with a VeriFactu invoice. However, there is no explicit when-to-use or when-not-to-use guidance, and no comparison with related siblings such as generate_verifactu_record.

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

• es__query_verifactu_statusA
  4/5.0
  Behavior4/5

  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 required environment variables/certificates, the prerequisite that the record was already submitted, the 'deferred' polling pattern, and the possible final states. It does not explicitly state read-only behavior or rate limits, but 'Consulta' and the polling context imply a safe status-check operation.

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

  Conciseness5/5

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

  The description is four short sentences with no filler. It leads with the core purpose, then explains when and how to use it, and finally lists required credentials. Every sentence earns its place and front-loads the most important information.

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

  Completeness4/5

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

  For a tool with an output schema and fully documented parameters, the description provides the necessary operational context: the trigger event, wait behavior, expected final states, and credential requirements. It is complete enough for an agent to invoke correctly, though it could optionally mention error or edge-case behavior.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters and the description does not need to compensate. The description adds no new parameter-level detail, though it does helpfully reference retry_after_seconds from the submit tool, which is external context rather than parameter semantics.

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

  Purpose4/5

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

  The description states a specific action ('Consulta el EstadoRegistro') and resource ('un registro VERI*FACTU ya enviado'), making the tool's function clear. It does not explicitly contrast with other status-query siblings like es__get_face_invoice_status or es__query_sii_status, so it is clear but lacks direct sibling differentiation.

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

  Usage Guidelines4/5

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

  The description gives explicit usage context: use after a 'deferred' result from es__submit_verifactu_to_aeat, wait retry_after_seconds, and confirm the final state before continuing. This is strong guidance, though it does not provide exclusion criteria or explicitly mention when to prefer alternative tools.

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

• es__validate_facturae_schemaA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It honestly discloses a conditional behavior: structural validation always occurs, but full schema validation only happens if the XSD is available in specs/facturae/. This adds meaningful context beyond the schema and helps set expectations.

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

  Conciseness5/5

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

  Two terse sentences with no wasted words. The main purpose is front-loaded, and the conditional validation behavior is explained efficiently.

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

  Completeness4/5

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

  The tool is simple, has a full input schema, and an output schema exists, so return values need not be described. The description covers the core behavior and the key environmental limitation, making it sufficiently complete for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description reinforces that 'xml' is Facturae XML and that 'schema_version' refers to the official XSD version 3.2.2, but it does not add substantial new meaning beyond the schema definitions.

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

  Purpose5/5

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

  The description clearly states a specific verb and resource: validating a Facturae XML against the official 3.2.2 XSD. It distinguishes this from sibling generation, submission, and other validation tools by naming the exact schema and document type.

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

  Usage Guidelines3/5

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

  The usage context is implied: use this when you need to validate a Facturae XML against the official schema. However, there is no explicit when-to-use versus alternatives, no exclusions, and no mention of when a different validation tool might be more appropriate.

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

• es__generate_verifactu_recordA
  4.2/5.0
  Behavior4/5

  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 well by explaining that the tool generates a chained record, returns XML and a fingerprint for linking to the next record, and requires a preceding regime check. It could mention whether the tool persists anything or whether it only returns generated data, but the phrasing strongly implies a pure generation step.

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

  Conciseness5/5

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

  The description is concise: three short sentences, each with a distinct purpose — what it generates, what it returns, and what to do before calling. It is front-loaded with the core action and avoids filler.

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

  Completeness4/5

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

  For a tool with 11 parameters and nested objects, the description covers the essential workflow: check regime, generate chained record, use returned hash for next record. The output schema exists to document return structure, so the description does not need to list every field. It could be slightly richer by explicitly noting this tool does not submit to AEAT, but it is otherwise complete enough.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 11 parameters. The description only paraphrases the invoice object content already in the schema and does not add meaningful parameter-level detail beyond what is structured. Baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states a specific action ('Genera un registro de factura VERI*FACTU') with a concrete resource type and regulation reference. It also distinguishes the tool's output purpose (XML plus SHA-256 hash chain) from sibling generation tools like facturae or SII, so the agent can identify it by name and scope.

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

  Usage Guidelines4/5

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

  The description gives an explicit prerequisite: call es__detect_regional_regime first to confirm the regime is VERIFACTU. This provides clear context for when the tool should be used, though it does not explicitly mention alternatives or when not to use it beyond that condition.

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

• es__parse_aeat_responseA
  4.2/5.0
  Behavior4/5

  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 discloses the input transformation, the output format, and the specific data elements extracted (EstadoEnvio, CSV, error details), which gives the agent a solid understanding of behavior. It does not detail malformed-input handling or whether it performs validation, but these are minor for a parser tool.

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

  Conciseness5/5

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

  The description is two short paragraphs: the first states the core purpose, the second enumerates what is extracted. It is front-loaded, free of fluff, and every sentence adds value.

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

  Completeness4/5

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

  Given the tool's low complexity (2 parameters, output schema present) and absence of annotations, the description is reasonably complete. It explains the input scenario, the normalization action, and the key output elements. It could mention behavior on invalid or unexpected XML, but the presence of an output schema reduces the need to describe the return structure.

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

  Parameters3/5

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

  Schema description coverage is 100%: both 'xml' and 'response_type' have descriptive parameter text. The tool description adds context that the response can be Verifactu or SII, but it does not materially go beyond the schema's parameter descriptions, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Analiza y normaliza') and resource ('una respuesta XML de la AEAT') with a clear output ('JSON estructurado'). It also names the two supported formats (VERI*FACTU o SII) and the key extracted fields, making the tool's function unmistakable and distinct from sibling submit/query/generate tools.

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

  Usage Guidelines4/5

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

  The description clearly establishes the context for use: when you have an AEAT XML response and want structured JSON, this is the tool. It implicitly covers both Verifactu and SII scenarios and mentions extraction of status and error details, but it does not explicitly name alternatives or exclusion criteria compared to sibling tools.

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

• es__validate_verifactu_recordA
  4.2/5.0
  Behavior4/5

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

  With no annotations available, the description carries the burden of behavioral disclosure. It does disclose a key behavior: structural validation always occurs, while XSD schema validation only happens if the v1.0 XSD is available in specs/verifactu/. This conditional dependency is meaningful, though it does not cover error response behavior.

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

  Conciseness5/5

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

  The description is two short, front-loaded sentences: the main operation first, then the conditional validation detail. There is no redundant restatement of parameter names or schema fields.

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

  Completeness4/5

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

  For a two-parameter validation tool with an output schema, the description covers the core operation and the main runtime condition (XSD availability). It could be more complete by stating expected error behavior or recommending it before submission to AEAT, but nothing essential is missing.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds value by connecting schema_version to XSD v1.0 (HAC/1177/2024) and the specs/verifactu/ path. This gives the agent more concrete context for the schema_version parameter than the input schema alone provides.

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

  Purpose5/5

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

  The description opens with 'Valida un registro VERI*FACTU XML', naming a specific verb and resource, and then clarifies the two validation levels: structural and schema. This clearly distinguishes it from sibling tools that generate, submit, query, or cancel Veri*Factu records, and from validate_facturae_schema.

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

  Usage Guidelines3/5

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

  The description makes the tool's context clear—use it to validate a VERI*FACTU XML record—but it never explicitly says when to prefer this tool over alternatives or mentions exclusions. Usage is implied rather than directly stated.

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

• es__sign_facturae_xadesA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does it well: it reveals the two-step human-in-the-loop behavior, the PKCS#12 certificate source, SHA-256+RSA algorithm, and default policy. It omits minor details like whether the operation is local/remote or what exactly gets returned, but the explicit confirmation flow is a significant disclosure beyond the schema.

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

  Conciseness5/5

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

  Three short paragraphs are front-loaded with purpose, then technical specifics, then the crucial human-in-the-loop workflow. No repetitive or filler sentences; the all-caps HITL line is easy to spot and highly actionable.

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

  Completeness4/5

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

  For a 5-parameter signing tool with an output schema, the description is nearly complete: it covers the workflow, algorithm, and default policy. It doesn't explicitly state prerequisites like the AEAT_CERTIFICATE_PASSWORD environment variable or behavior when cert_path is null, but those are documented in the input schema, so the gap is minor.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3; the description adds value by explaining the confirmation_token lifecycle and by connecting cert_path to the password-from-environment constraint. It reinforces the default signature policy and ties it to the algorithm, which complements the schema rather than repeating it.

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

  Purpose5/5

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

  The description states a specific action ('Aplica una firma digital XAdES-EPES') on a clear resource ('documento Facturae XML'), and distinguishes it from sibling generation/validation/submission tools by its signing focus. It also names the exact standard and algorithm, leaving no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description gives clear procedural context: call without confirmation_token to get a summary/token, then call with it to apply the real signature. It doesn't explicitly name alternatives or say 'use after generate_facturae_xml', but the signing purpose is evident from the first sentence and the sibling set.

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

• es__submit_sii_batchA
  4.4/5.0
  Behavior4/5

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

  No hay anotaciones, por lo que la descripción asume toda la carga. Revela comportamientos importantes: requiere variables de entorno y certificado MTLS, tiene límite de 10.000 registros, y ejecuta un flujo humano-en-el-bucle con confirmación previa. No detalla idempotencia ni manejo de errores, pero cubre lo esencial para evitar una invocación accidental.

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

  Conciseness5/5

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

  La descripción es breve, está bien estructurada en tres bloques funcionales: acción principal, prerrequisitos y flujo de confirmación. Cada frase aporta información necesaria y no hay repetición ni relleno.

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

  Completeness4/5

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

  Para una herramienta de envío con riesgo de efectos colaterales, cubre límites, credenciales y el protocolo de confirmación. La existencia de un output schema compensa la falta de descripción del valor de retorno. Podría añadir referencias a estados posteriores o reintentos, pero en general es completa.

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

  Parameters4/5

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

  El esquema ya documenta el 100% de los parámetros, por lo que la línea base es 3. La descripción añade significado útil al explicar el comportamiento de confirmation_token en el flujo de confirmación y al contextualizar los records como envelopes generados por otra herramienta, aunque no profundiza en record_type ni fiscal_year.

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

  Purpose5/5

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

  La descripción comienza con un verbo de acción específico ('Enviar'), especifica el recurso ('lote de facturas'), el límite operativo ('máximo 10.000 registros') y el endpoint concreto ('SOAP SII de la AEAT'). Este detalle permite distinguirlo inmediatamente de otras herramientas hermanas como las de Verifactu o FACE.

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

  Usage Guidelines4/5

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

  La descripción indica claramente cuándo y cómo usarla: para envíos por lote al SII, requiriendo credenciales MTLS y explicando el flujo de dos pasos con confirmation_token. No nombra alternativas o exclusiones explícitas, pero el contexto de uso queda suficientemente claro.

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

• es__submit_to_faceA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, and the description compensates by disclosing authentication requirements (JWS RS256+x5c, required env vars) and the two-phase side-effect behavior (summary vs. real submission). It does not discuss error handling or retries, but the critical human-in-the-loop side effect is explicitly flagged.

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

  Conciseness5/5

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

  Three short paragraphs front-load the action, then add only high-value context: what FACe is, auth prerequisites, and the human-in-the-loop protocol. There is no filler or redundant restatement of schema fields.

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

  Completeness4/5

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

  For a mutating submission tool with no annotations, it covers prerequisite auth, destination, and the required two-call confirmation workflow. The existence of an output schema covers return-value details; minor omissions like idempotency or retry behavior keep it from a 5.

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

  Parameters4/5

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

  Schema coverage is 100%, so the description does not need to restate parameters. It adds value by explaining the confirmation_token lifecycle (omit to receive a token, include it to execute) and by tying authentication to external env vars, which is not visible in the schema.

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

  Purpose5/5

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

  The description names a specific verb ('Envía'), a specific object ('XML Facturae firmado con XAdES'), and a specific target ('FACe ... API REST B2B de FACe v2'). This clearly distinguishes it from sibling generation/validation/status tools; there is no ambiguity about what the tool executes.

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

  Usage Guidelines4/5

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

  It clearly specifies the two-step invocation flow: call without confirmation_token to receive a summary/token, then call with it to execute the real submission. It does not explicitly name sibling alternatives or state when not to use it, but the workflow gives an agent enough context to follow the required sequence.

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

• es__detect_regional_regimeA
  4.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It conveys that this is a read-only detection operation ('Detecta', 'Devuelve') and discloses the possible result values. It does not discuss invalid-province handling or explicitly state side-effect-free behavior, but for this simple routing tool the behavior is sufficiently transparent.

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

  Conciseness5/5

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

  The description is compact and front-loaded: it states the purpose first, then the input basis, possible outputs, and the universal usage precondition. Every sentence earns its place and no information is redundant.

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

  Completeness5/5

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

  For a two-parameter routing tool with a full input schema, an output schema, and an explicit usage mandate, the description is complete. It gives the agent everything needed to call it correctly and know what it will return.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by linking the province code to regional regime selection and by hinting at the role of SII through the 'VERIFACTU+SII' output value, which is not fully explained in the schema alone.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Detecta el régimen de facturación electrónica aplicable.' It then names the exact output values (VERIFACTU, TICKETBAI, NATICKET, VERIFACTU+SII) and the input basis, which clearly separates this detection/routing tool from the generation, submission, and validation siblings.

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

  Usage Guidelines5/5

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

  The description gives an explicit, unambiguous usage rule: 'Usar siempre antes de llamar a cualquier otra herramienta de este servidor.' This tells the agent exactly when to invoke it and assigns it a mandatory prerequisite role relative to all sibling tools.

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

• es__submit_verifactu_to_aeatA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden, and it covers substantial behavior: MTLS authentication, required certificate variables, deferred response handling, deferred status confirmation before chaining records, and the human-in-the-loop confirmation token flow. This goes well beyond the schema.

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

  Conciseness5/5

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

  The description is dense but well-structured: main action first, then prerequisites, then deferred-response handling, then the human-in-the-loop note. Every sentence carries distinct operational value; the formatting also makes the critical confirmation workflow easy to spot.

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

  Completeness5/5

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

  For a submission tool with no annotations, the description is remarkably complete: prerequisites, authentication method, environment variables, deferred-response behavior, next-step querying, and confirmation flow are all covered. The presence of an output schema means return-value details do not need to be in the description.

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

  Parameters4/5

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

  The schema already provides 100% coverage for the three parameters, so the baseline is 3. The description adds meaningful semantics for confirmation_token by explaining the two-call confirmation pattern, which enriches the schema's brief description. NIF and XML are not expanded, but their schema descriptions are adequate.

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

  Purpose5/5

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

  The description uses a specific verb ('Envía'), names the exact resource ('registro VERI*FACTU firmado'), and identifies the endpoint ('tiempo real de la AEAT mediante MTLS'). This clearly distinguishes it from sibling tools like es__submit_to_face or es__submit_sii_batch.

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

  Usage Guidelines4/5

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

  The description gives clear operational context: required environment variables, the deferred-response workflow with retry_after_seconds, and explicit routing to es__query_verifactu_status. It does not broadly state when to choose this tool over siblings, but the conditional alternative is explicit enough for most cases.

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