Jithox E-Invoice Readiness

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

Annotations already indicate read-only and non-destructive. The description adds useful context: never sends a Peppol invoice, no compliance guarantee, and that it is purely diagnostic. This goes beyond annotations without contradiction.

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

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

Three sentences, each adding value: purpose, clarification of scope, and explicit constraints. No redundant or empty phrasing.

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

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

Given the output schema exists and annotations provide safety info, the description covers all essential aspects: scope (canary workspace), output type (diagnostics), and limitations (no compliance or sending). It is sufficient for an agent to understand and invoke 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?

The only parameter (verifyWithProvider) has a description in the input schema (100% coverage). The tool description does not add any additional meaning beyond that, so baseline 3 applies.

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

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

The description clearly states the tool provides a readiness snapshot with specific outputs (what is ready/missing, next step). It distinguishes from compliance certificates and explicitly says it never sends invoices, differentiating it from sibling tools like validate_invoice or lookup_peppol_participant.

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 tells when to use (for diagnostics, not compliance) and what not to expect (no sending, no legal guarantee). However, it does not explicitly mention when to use vs. siblings or provide exclusion scenarios.

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

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

The description adds behavioral details beyond annotations: explains SML/SMP discovery route with fallback to honest mock, clarifies response semantics (status types and interpretation), and reaffirms read-only nature. No contradictions with annotations.

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

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

Two dense sentences that front-load the core action and purpose. Every phrase adds value; no fluff. Efficient and well-structured.

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 parameter count (4), required fields (1), and presence of output schema, the description fully covers purpose, usage, behavior, and parameter semantics. Agent has sufficient context to select and invoke 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 coverage is 100% and description adds critical usage context: requires at least one of vatId/endpointId plus countryCode, explains endpointScheme derivation. This adds meaning beyond raw schema.

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

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

The description clearly states the tool checks Peppol registration and BIS Billing 3.0 acceptance, with specific scope (validation only, never sends). It distinguishes from siblings by clarifying it is a lookup-only tool with no send action.

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

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

The description specifies when to use (to check registration/readiness) and what results mean (definitive vs. truthful non-definitive statuses). It also states limitations (no send, no legal guarantee), though it does not explicitly name alternative sibling tools for comparison.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds key behavioral context: 'Full report, never fails fast' and clarifies that validation does not imply legal/fiscal/compliance guarantees. This goes beyond annotations and aligns with them.

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, no redundancy. The first sentence immediately states purpose and scope, the second clarifies limitations. Every word adds value.

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

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

Given the tool has 1 required parameter, nested object, and output schema exists, the description is complete. It explains what is validated, what is not, and the nature of the output (machine-readable issues, never fails fast). No 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 coverage is 100% with a single parameter 'invoice' described as 'The invoice payload to check.' The description adds meaning by enumerating what is validated (schema problems, VAT-id format, date sanity, BIS 3.0 completeness, computed totals), which helps the agent understand the tool's scope beyond the schema.

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

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

The description clearly states the tool validates EU invoice structure and reports machine-readable issues, with specific examples (schema, VAT format, date sanity, BIS 3.0 completeness, computed totals). It distinguishes from siblings by explicitly stating what it is not (legal approval, sending Peppol).

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 states when to use (structural validation) and when not (not for legal/compliance, never sends). It also provides exclusion conditions ('never sends a Peppol invoice, gives no legal guarantee'), which helps the agent decide against 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?

Annotations already indicate read-only and non-destructive, but the description adds that it is deterministic, performs checksum validation including Belgian modulo-97, returns normalized identifier and stable issue code, and gives no legal guarantee. No contradictions with annotations.

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

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

Two concise sentences that front-load the core purpose and immediately clarify limitations. Every word contributes meaning; 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?

Given the tool's purpose (format validation) and the presence of an output schema, the description covers scope, limitations, and behavioral guarantees. It explicitly states what the tool does not do, which is critical for correct usage.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context about the validation process and output (normalized identifier, issue code), which enhances understanding beyond the schema descriptions. However, it does not directly elaborate on parameter usage beyond what is in the schema.

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

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

The description clearly states it performs deterministic structure/checksum validation of EU VAT numbers, distinguishing it from live VIES checks. It specifies it is format plausibility only, not a live result, which differentiates it from sibling tool verify_vat_vies.

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

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

Explicitly states when to use (format validation) and when not to use (not a live VIES result, no legal/fiscal guarantee). Mentions it never sends a Peppol invoice, providing clear boundaries. Sibling tools imply alternatives for live checks.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: return values (valid/invalid/invalid_input/unavailable), provenance (source, checkedAt), and behavior when VIES is unavailable. No contradiction.

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

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

The description is three sentences with no wasted words. Front-loaded with the main purpose, then concise behavioral notes.

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

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

Given the tool's simplicity (2 params, output schema exists), the description covers key behaviors and return format. It does not repeat output schema fields, which is acceptable. A minor gap: it doesn't mention the optional countryCode in the description text, but the schema covers it.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds an example for vatNumber but no extra semantic meaning beyond the schema.

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

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

The description clearly states the verb 'Check', the resource 'VAT number', and the target 'official EU VIES source'. It distinguishes from siblings by specifying it is live verification and not sending invoices or providing legal guarantees.

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 (check active status against VIES) and explicitly states what it does not do (no Peppol invoice, no legal/compliance guarantee). However, it does not provide explicit when-not-to-use or alternative comparisons.

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