InvoiceVerify

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the metering model (one metered call per valid company, unreadable numbers free) and the authentication prerequisite (InvoiceVerify account via OAuth). It also enumerates the possible per-company outcomes, which is the behavioral detail an agent needs before spending calls.

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?

Four sentences, front-loaded with the core action and scope, then outcomes, then cost and auth. Every sentence carries information an agent would otherwise have to guess, with no filler.

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

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

There is no output schema, yet the description still enumerates the return categories (both, only 0208, only 9925, neither, unknown) and what accompanies them. Combined with the billing and auth disclosures, an agent has everything needed to call this correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining what the id values actually represent (checked under both 0208 and 9925) and that lang controls the language of the explanations, adding interpretive meaning to the enum rather than restating it.

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 (check), a specific resource (Belgian companies' Peppol receivability), the batch cap (up to 25), and the exact ID schemes examined (0208 and 9925). The 'Belgian' scope and batch framing clearly separate it from the generic sibling check_peppol_receivability, so an agent can pick it without opening either schema.

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

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

Gives clear use context: Belgian client lists, either enterprise or VAT numbers, with the instruction to split longer lists into several calls. It does not explicitly name an alternative such as check_peppol_receivability or lookup_peppol_participant and say when to prefer those, so it falls short of full when/when-not guidance.

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

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

Annotations cover safety (readOnly, idempotent, openWorld), and the description goes well beyond them: no authentication required, a concrete rate limit of 20 checks/hour per connection, and the full result taxonomy (receivable under both, only 0208, only 9925, neither, unknown) plus access point, risk and fix per ID. This is exactly the operational context an agent needs before calling.

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?

Front-loaded with the most decision-relevant facts ('Free, no sign-in needed') followed by outcome taxonomy and the rate limit/alternative. The single long sentence packing the return categories is dense but every clause earns its place; only slight tightening would improve scannability.

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?

There is no output schema, so the description carries the return-value burden and does so fully — enumerating every possible status, the recommended ID, the access point, and the localized risk/fix. Combined with auth and rate-limit disclosure, nothing an agent needs to call or interpret results is missing.

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

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

Schema coverage is 100% with an enum and worked examples, so the schema does the heavy lifting. The description still adds meaning beyond it: that the id resolves against two distinct Belgian ID schemes (0208 enterprise and 9925 VAT) and that lang localizes the returned risk/fix text, which clarifies the parameter's downstream effect rather than just its type.

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

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

Specific verb and resource: checks whether one Belgian company can receive Peppol e-invoices, and uniquely qualifies the scope as two Belgian Peppol IDs (0208 KBO/BCE and 9925 VAT). An agent can distinguish this from check_belgian_peppol_list and lookup_peppol_participant without opening any 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?

Explicitly states the access conditions ('free, no sign-in needed'), the volume constraint (20 checks/hour per connection), and routes the alternative case: 'for client lists use check_belgian_peppol_list (sign-in)'. Both when-to-use and when-to-use-something-else are named with the selecting condition.

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?

Adds context beyond the annotations: one metered call (cost awareness) and an account/OAuth requirement. The readOnlyHint/idempotentHint annotations are consistent with a pure transformation. It omits what the result looks like on validation failure, but the safety and cost profile is well 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?

Two dense sentences, front-loaded with the conversion capability and followed by cost/account constraints. No filler and nothing repeated from the schema.

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

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

With no output schema, the description should say what the tool returns, yet 'validate the result' only hints at a validation outcome and never says whether the converted XML is returned inline, as a link, or alongside a report. Everything else an agent needs to call it is 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?

Schema coverage is 100%, so the baseline is 3, but the description earns more by naming the accepted source dialects, which the 'xml' schema entry does not ('The source invoice XML'). The target format names are already enumerated in the schema, so the description adds only marginal detail there.

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 (convert) with the exact source dialects (UBL, CII/Factur-X) and the four target formats, plus the extra validation step. This is clearly distinguishable from parse_invoice, validate_invoice, and generate_invoice without opening any 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?

Establishes the usage context (you already have an invoice XML and need a different profile) and states the prerequisite of an InvoiceVerify account with OAuth sign-in. It stops short of explicit exclusions, e.g. telling the agent to use validate_invoice when no conversion is wanted.

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 cover the safety profile (readOnly, idempotent, closed-world), and the description adds genuinely non-obvious context: it is a free call but requires an InvoiceVerify account via OAuth sign-in, and it discloses the response content (causes and fix steps). No rate limits or fallback behavior for unknown rule IDs are mentioned.

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 tight sentences, front-loaded with the capability and the outcome, then the auth/cost constraint. Minor redundancy in restating the three languages that the enum already enumerates.

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

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

For a two-parameter, read-only lookup with no output schema, everything an agent needs is present: what the tool returns, which rule vocabularies are supported, the auth prerequisite, and the cost. No meaningful gap remains.

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 both parameters are already documented, including the language enum and the default. The description adds little beyond restating the language options and supplying example rule IDs; useful, but baseline 3 applies.

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

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

States a specific verb (explain) and resource (EN 16931 / Peppol / XRechnung business rule) plus the shape of the answer: plain-language explanation with typical causes and fix steps. It is inherently distinct from the validate/parse/convert siblings, but the description never names them or draws the boundary 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?

The usage context is only implied: the schema notes the rule_id comes 'as reported by validate_invoice', which hints this is a follow-up to a failed validation, but the description itself gives no when-to-use, when-not, or alternative routing.

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

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

Annotations already declare readOnly/idempotent/no-open-world, so the bar is lower, but the description still adds real operational context: totals and VAT are auto-computed, output is validated, it consumes exactly one metered call, and OAuth sign-in with an InvoiceVerify account is required. It does not say what happens when validation fails (error vs. returned report), which keeps it short of a 5.

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

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

Two sentences, no filler: the capability and supported formats come first, then cost/auth constraints. Every clause carries information an agent needs before calling.

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 nested-object tool with no output schema, the definition covers input shape, derivation behavior (totals/VAT), validation, cost and auth. The only gap is return shape — whether the agent gets the XML string, a link, or a validation report — which matters because no output schema exists.

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

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

Schema coverage is 100% and the InvoiceData shape is documented inline plus a pointer to /openapi.json, so the schema does the heavy lifting. The description does add a little meaning the enum lacks — mapping 'cii' to Factur-X/ZUGFeRD and noting VAT/totals are derived rather than supplied — but it adds no detail on the format parameter's selection trade-offs.

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 (create/generate) and a precise resource (Peppol BIS 3 UBL, XRechnung UBL/CII, Factur-X/ZUGFeRD CII XML invoice) from structured invoice data. The enumeration of supported formats plus 'totals and VAT computed and the result validated' clearly separates it from siblings like convert_invoice, validate_invoice and parse_invoice.

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?

Implied usage is clear — you have structured invoice data and want standards-compliant XML — and the note about one metered call plus an account requirement gives cost/access context. However, it never explicitly states when to choose convert_invoice (format-to-format) or validate_invoice (validate only) instead, so the agent must infer the boundary.

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, idempotentHint and openWorldHint=false, so safety is covered. The description adds real value beyond them: it is free (no credits consumed), requires an InvoiceVerify OAuth account, and discloses the specific returned data including the reset date.

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 with zero waste: the returned data is front-loaded, followed by the cost and auth prerequisite. Every clause 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?

With no output schema, the description carries the burden of describing return values and does so concretely (calls, allowance, credits, reset date). Auth and cost are stated; only return format/units are left unspecified, a minor gap.

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

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

The tool takes zero parameters and the schema is closed (additionalProperties: false), so there is no parameter semantics to explain. Baseline 4 applies; nothing is missing or contradicted.

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 (show) and resource (this month's metered calls, allowance, call-pack credits, reset date) scoped to the signed-in account. The invoice/Peppol siblings are clearly unrelated, so differentiation is implicit rather than needed, keeping it just short of a 5.

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

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

Gives clear context for when to call it (checking quota/remaining credits for the current month) and notes it is 'Free', which is a useful selection hint. It stops short of naming explicit alternatives or when-not-to-use conditions, but no sibling overlaps meaningfully.

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

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

Annotations only say readOnly/openWorld/idempotent, so the description carries the interesting burden and does it well: it discloses the metered call cost, the OAuth account prerequisite, that the lookup is live rather than cached, and what the result contains. It stops short of covering failure cases (ID not found, no Peppol capability) or latency, so not a 5.

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

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

One dense sentence opens with the core question, then layers accepted inputs, lookup behavior, and output, followed by two short sentences on cost and auth. Front-loaded and waste-free, though the first sentence is long enough to be harder to scan than it needs to be.

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?

There is no output schema, yet the description says what comes back (supported document types and which ID to send to), and it covers the two invocation blockers an agent cannot infer: the metered cost and the OAuth account requirement. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and already documents both parameters, so the baseline is 3. The description adds value by listing identifier families the schema does not mention (GLN, KvK, SIREN/SIRET) and by explaining that ambiguous numbers are resolved by testing every relevant scheme, which motivates the optional country hint.

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 (check whether a company can receive Peppol e-invoices) and describes the mechanism (querying live Peppol SML/SMP across every relevant scheme). However, it never distinguishes itself from the near-identical sibling 'check_peppol_receivability' or from 'check_belgian_peppol_list', leaving an agent to guess which of the three to call.

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 enumeration of accepted identifier types (VAT, KBO/BCE, KvK, SIREN/SIRET, GLN, Peppol ID) and the note that it checks all relevant schemes imply this is the general-purpose lookup, while the sibling names suggest narrower alternatives. But there is no explicit when-to-use or when-not-to-use statement, and no naming of an alternative tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: a metered-call cost implication and a required InvoiceVerify account with OAuth sign-in, which an agent needs before invoking. It stops short of describing error behavior or input validation failures, keeping it below a 5.

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

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

Three tightly packed sentences, front-loaded with the core action and formats before cost and auth requirements. Zero filler.

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

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

For a read-only, single-parameter tool with no output schema, the description covers input formats, the output structure (parties, lines, VAT, totals, payment), cost model, and auth prerequisite. An agent has everything needed to call it 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?

With a single parameter at 100% schema coverage, the baseline is 3, but the description adds real meaning beyond the schema's 'The invoice XML.' by specifying which XML syntaxes are accepted (UBL, CII, Factur-X). It doesn't cover the 5MB size limit or encoding expectations, which the schema only partially implies.

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 (Read) and resource (UBL/CII/Factur-X invoice XML) plus the conversion target (structured JSON with named sections). The naming of supported formats and output shape clearly distinguishes it from siblings like convert_invoice and validate_invoice.

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

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

Gives clear usage context ('for booking or reconciliation') and a cost signal ('Uses one metered call'), which helps an agent weigh it against alternatives. However, it never explicitly names when to prefer validate_invoice or convert_invoice instead, so the routing guidance is implicit 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?

Goes well beyond the readOnly/idempotent/closed-world annotations by disclosing two operationally critical facts: it consumes one metered call (quota cost) and requires an InvoiceVerify account with OAuth sign-in (auth prerequisite). It also describes the response shape (pass/fail, rule IDs, line numbers, fixes), which matters since there is no output schema.

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

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

A single dense sentence front-loads the supported formats and rule sets, then the return value, then the cost and auth constraints. Every clause carries information an agent needs; nothing is redundant with the title or schema.

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

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

For a two-parameter, non-destructive validation tool, the description covers the gaps that structured data leaves: quota cost, authentication requirement, and return contents. With 100% schema coverage and annotations carrying the safety profile, no material question is left open before invocation.

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

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

Schema description coverage is 100%, so both xml and profile are already fully documented, including the 'auto' detection behavior via CustomizationID. The description names the supported formats, which loosely relates to the profile enum, but adds no syntax or size guidance beyond the schema. 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?

Specific verb (validate) plus the exact resource and supported syntaxes (UBL 2.1, Peppol BIS Billing 3.0, XRechnung, CII/Factur-X) and the rule sets checked (EN 16931, Peppol). This clearly separates it from siblings like convert_invoice and parse_invoice, which transform or extract rather than check compliance.

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 for invocation: you have an invoice XML and want a pass/fail compliance verdict with rule IDs. It stops short of explicitly routing the agent away from parse_invoice or convert_invoice when those are the better first step, and states no exclusions.

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