E-Invoice Checker

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

With no annotations, the description carries the full burden. The "cheap first step" phrasing usefully signals low cost and implies a non-mutating inspection, but it does not state read-only behavior explicitly, permission requirements, or what the response contains.

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: the purpose first, then the actionable sequencing hint. No filler, and the highest-value guidance (use this first) is placed after the purpose but still front-loaded.

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

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

There is no output schema, so the description profitably enumerates the return fields (format, syntax, profile/customization, country standard). It stops short of describing the response shape or behavior on unrecognized input, which leaves a small gap for a detection tool.

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

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

Schema description coverage is 100% and both parameters (content, content_base64) are fully documented in the schema, including which formats each accepts. The description adds no syntax or format guidance beyond that, so the 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 precise verb (Identify) and the exact attributes returned (format, syntax, profile/customization, country standard) for a named resource (e-invoice file). This makes it clearly distinguishable from siblings like validate_invoice, parse_invoice, or render_invoice_pdf.

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?

"Cheap first step before validating" gives explicit sequencing guidance, implicitly routing agents to run this before validate_invoice. It lacks an explicit when-not statement or a named alternative tool, but the context is clear.

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

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

With no annotations the description carries the full load and does well: it discloses the deterministic fixing scope, the values-vs-needs_input fallback behavior for data absent from the file, the returned artifacts (change list, remaining errors, corrected XML), and a cost signal ('Counts as 2 requests'). It omits auth/permission requirements and failure behavior.

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

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

Three dense but well-ordered sentences: scope and fixable error classes first, opt-in totals second, data-fallback and outputs last. The parenthetical format list is long but load-bearing for format selection; nothing is purely redundant.

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

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

No output schema exists, and the description compensates by naming the three return payloads and needs_input. For a 5-param tool with a nested values object and no annotations, this is nearly sufficient; only error/failure semantics and any permission prerequisites are left unstated.

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 adds relational meaning the schema cannot: values is only consumed for data missing from the file, and anything still unresolved surfaces in needs_input. totals=true is also framed as the condition that triggers total/VAT recalculation.

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 (fix) plus resource (EN 16931 invoice) and enumerates exactly which error classes are corrected (empty elements, decimals, date/code formats, specification ids), while distinguishing itself from validate_invoice/parse_invoice by being the corrective step.

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

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

Usage context is clear: it is the tool for repairing validation errors, with dry_run for previewing and totals=true as an opt-in escalation. It never explicitly names validate_invoice as the prerequisite for obtaining errors, so the routing is implied rather than spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the payload contents (formats, profiles, rule sets, pricing per tool), which is real information beyond the name. However it does not say whether the list is static or account-specific, nor whether it is paginated, so key traits remain undisclosed.

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

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

A single compact sentence that front-loads the resource and then the secondary cost information. Nothing is wasted, though the fragmentary phrasing lacks a leading verb, which slightly hurts scanability.

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

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

For a parameterless discovery tool with no output schema and no annotations, the description does enumerate what the response contains, which is the main thing an agent needs. It falls short only on whether the answer is global or account-scoped.

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, so the baseline of 4 applies; there are no parameter semantics to clarify and the description does not need to compensate.

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

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

The description names the specific resource this tool returns (formats, profiles, rule sets, plus per-tool costs), which lets an agent distinguish it from mutation/parsing siblings like parse_invoice or validate_invoice. It is phrased as a noun fragment rather than an explicit verb+resource, but the intent is unambiguous.

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

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

There is no statement of when to call this versus the other seven tools, and no mention of prerequisites or ordering (e.g. call this before parse_invoice to learn accepted formats). Usage is only inferable from the 'list' prefix.

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

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

No annotations are provided, so the description carries the full burden. It usefully signals that the call is 'Free' (no quota cost), which is genuine behavioral value, but it says nothing about authentication requirements, rate limits, or freshness of the reported usage figures. For a no-annotation tool this is partial disclosure.

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 compact sentence with no padding; the returned data fields are front-loaded. The trailing one-word fragment 'Free.' is slightly abrupt but still earns its place as a cost signal.

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 no-parameter read with no output schema, the description lists the four data points the caller will receive (plan, quota, monthly usage, subscription state), which is enough to decide whether to call it. Only the format/staleness of those values is left unspecified, a minor gap for such a simple tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline for a parameterless schema applies. The description appropriately focuses on what is returned instead of inventing parameter detail.

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 enumerates exactly what is returned: plan, monthly quota, usage this month, and subscription state scoped to the API key of the connection. The verb is implicit (a read/retrieval) rather than stated, but the resource and scope are unambiguous, and no sibling (all invoice tools) is similar enough to require differentiation.

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?

There is no explicit when-to-use statement, but the tool's purpose (check your own plan/quota/subscription) makes the usage context self-evident, and there are no competing siblings that would need routing guidance. This is implied usage at minimum-viable level rather than explicit 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?

No annotations, so the description carries the full behavioral burden. It usefully discloses the extracted field set and format coverage (UBL/CII/XRechnung/Peppol/ZUGFeRD/KSeF per schema), but says nothing about error behavior on unsupported or malformed invoices, whether it silently repairs, or cost/rate limits.

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, output shape front-loaded with no filler; the second sentence about format coverage is short and earns its place as a scope statement. No wasted clauses.

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 compensates by enumerating the returned JSON fields, which is exactly what an agent needs to consume the result. Remaining gap is the absence of any error/failure behavior for invalid or unsupported input.

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 parameters (content, content_base64) and their format variants are already documented in the schema. The description adds no parameter-level detail, so the 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 ('Extract') plus resource ('the invoice') and an explicit output form ('normalised JSON'), with an enumerated field list (number, dates, seller, buyer, lines, VAT breakdown, totals, payment details). The JSON framing implicitly separates it from render_invoice_html/render_invoice_pdf, though no sibling is named.

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?

'Works for every supported format' hints at applicability but never states when to choose this over validate_invoice, detect_invoice, or the render tools, nor any prerequisite such as detecting the format first. Usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the output is a human-readable HTML A4 document and that language is selectable, but says nothing about whether the operation is side-effect-free, deterministic, or how large/multi-page invoices are handled. Adequate but incomplete for an unannotated tool.

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

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

A single front-loaded sentence with no filler; the output format and language qualifier are the most decision-relevant facts and come first. Nothing is wasted.

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

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

No output schema exists, and the description does cover the return type (HTML document), which is the main thing. However, required parameters is 0 while the tool needs either content or content_base64 to function; the description never states this mutual dependency, leaving a real gap for correct 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 the schema already documents lang, content, and content_base64 fully; the baseline is 3. The phrase 'in the requested language' only echoes the lang parameter and adds no format or default detail beyond the schema's 'default en'.

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

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

The description states the resource (human-readable invoice document) and the output format (HTML, A4 print layout) produced from XML, which clearly separates it from the sibling render_invoice_pdf. The verb is implicit rather than stated ('Render' only appears in the name/title), so it falls just short of a fully self-contained verb+resource statement.

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

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

Usage is only implied: an agent can infer 'use this when you want an HTML/A4 rendering of an invoice'. No explicit when-to-use, when-not-to-use, or named alternative (e.g. render_invoice_pdf) is given, so the routing decision is left to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses two non-obvious traits: the call costs 2 requests (a quota/rate signal) and the result is returned as a base64 resource rather than a URL or inline text. It does not say which input parameter must be supplied, how errors surface, or what happens when neither content nor content_base64 is given.

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

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

Two short sentences, zero filler, with the output format and the cost caveat front-loaded. Every clause carries information an agent needs.

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

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

The description covers the return channel (base64 resource) and the cost, which is what matters most with no output schema and no annotations. However, it omits input selection (content vs content_base64, mutual exclusivity) and the meaning of lang, leaving gaps for a 3-parameter conversion tool.

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

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

Schema coverage is 67%, with content and content_base64 well documented in the schema but lang carrying only an enum and no explanation. The description adds nothing about parameter usage, so it neither compensates for the lang gap nor improves on what the schema already provides.

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

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

The description names the output artifact precisely (a human-readable PDF of the invoice) and the sibling set makes the implied verb (render) obvious. It implicitly distinguishes itself from render_invoice_html by producing PDF rather than HTML, though it never names that sibling 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?

There is no explicit when-to-use guidance or routing between this tool and render_invoice_html. The agent must infer that this is the choice when a PDF is wanted rather than an HTML view; no conditions, prerequisites, or exclusions are stated.

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

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

With no annotations, the description carries the behavioral burden and does disclose the return shape ('valid/invalid with every failed rule: id, severity, message, XPath') and that it delegates to external official rule sets per format. It does not state permission/auth needs, network or runtime characteristics, or that it is strictly non-mutating, so it stops short of full disclosure.

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 the core action and return contract front-loaded. The parenthetical format/rule-set mapping is long but information-dense and non-redundant, so it earns its space; only minor tightening is possible.

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?

Covers the rule-set matrix and the failure-report shape well for a tool with no output schema and no annotations. It is incomplete on the practical contract, though: required=0 while one of content/content_base64 must actually be supplied, and the detect_invoice prerequisite is only implied rather than stated.

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 all three parameters (kosit, content, content_base64) are already documented in the schema, which sets the baseline at 3. The description adds no syntax or format detail beyond the schema for kosit, content, or content_base64, and notably omits that one of the two content inputs is effectively required despite required=0.

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 ('Run the official rule set for the detected format') and enumerates exactly which rule set applies per format (KoSIT, OpenPeppol, FA(3), HR-CIUS, Facturae, LHDN). This clearly separates it from sibling tools like detect_invoice, parse_invoice, and fix_invoice without needing to open 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?

The phrase 'for the detected format' implies a detect_invoice step must precede this call, which is useful implied sequencing. However, it never explicitly says when to choose this over fix_invoice or parse_invoice, and names no exclusions or prerequisites for the content inputs.

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