8 invoice/payment tools; 5 free, no login. IBAN, bank changes, Peppol. Paid VAT and invoice review.
Scored across 8 tools
Most tools have clearly distinct purposes, and descriptions explicitly cross-reference alternatives such as kbo_company_search (one number) versus check_vat_list (up to 20 rows), and review_invoice versus check_peppol_ready. Minor overlap remains between check_payment_change and preflight_payment, and between Peppol readiness checks, but an agent can generally distinguish them from the documented boundaries.
All names use snake_case and are mostly action-oriented (check_*, lookup_*, review_*, verify_*). Two names deviate slightly from a strict verb_noun pattern (kbo_company_search and preflight_payment), but the overall convention is predictable and readable.
Eight tools is well-scoped for a payment and invoice compliance server, covering bank-change checks, VAT validation, Peppol readiness, participant lookup, invoice review, IBAN verification, and payment preflight. Each tool appears to earn its place without redundancy or triviality.
The surface covers the core compliance workflow: invoice review, VAT list and single-company checks, Peppol readiness and participant lookup, IBAN structure verification, supplier bank-change checks, and payment preflight. Some gaps remain, such as full official Peppol validation or bank-account ownership verification, but these limitations are explicitly documented and the main paths are supported.
Check a supplier's bank-detail change before the vendor record is touched: returns no_change, verify_first, stop or invalid_new_account with call-back steps. It never says an account is safe. Free, no token.
| Name | Required | Description | Default |
|---|---|---|---|
| newIban | Yes | The account number in the change request, as written — spaces and dashes are fine, e.g. "DE89 3704 0044 0532 0130 00". | |
| ibanOnFile | No | The account currently on the vendor record. | |
| supplierCountry | No | ISO 3166-1 alpha-2 country where the supplier is established, e.g. BE. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| evidence | No | Signed decision evidence, present when a signing key is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuine context beyond that: the critical caveat that it 'never says an account is safe', plus cost/auth facts ('Free, no token') and the call-back-steps behavior. This is exactly the extra context the annotations cannot convey.
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-loaded with the action and scope, then the outputs, then the reassurance that it never certifies safety. No wasted words.
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?
An output schema exists, so return values need not be spelled out — yet the description still names the four verdicts, which helps the agent interpret results. Combined with the safety caveat and cost note, an agent has everything needed to call this read-only check correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (newIban, ibanOnFile, supplierCountry) fully documented including a format example, so the schema already carries the semantics. The description adds no parameter-level meaning beyond that, making the baseline 3 appropriate.
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 a supplier's bank-detail change — and scopes it with 'before the vendor record is touched', clearly separating it from sibling account-validation tools like verify_iban. It even enumerates the possible verdicts, so an agent knows exactly what the tool produces.
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 a clear usage window ('before the vendor record is touched') and the verdict vocabulary tells the agent what each outcome means. However, it never names an alternative sibling (e.g. verify_iban or preflight_payment) or states when NOT to use it, so the routing guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your own invoice against 21 published Peppol BIS Billing 3.0 rules, and whether the customer's Peppol address is registered; each finding names the rule and the fix. A listed subset, not the official validator. Free, no token.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | ||
| currency | No | Three-letter currency code (BT-5), e.g. EUR. | |
| customer | No | The customer, the receiver. | |
| supplier | No | You, the sender. | |
| totalVat | No | Total VAT (BT-110). | |
| issueDate | No | The issue date (BT-2). | |
| totalWithVat | No | Invoice total including VAT (BT-112). | |
| invoiceNumber | No | The invoice number (BT-1). | |
| buyerReference | No | The reference the customer asked you to put on the invoice (BT-10). Peppol requires this OR an order reference. | |
| orderReference | No | The purchase order number (BT-13). | |
| documentCharges | No | Charges on the WHOLE invoice, e.g. freight (BG-21). | |
| totalWithoutVat | No | Invoice total excluding VAT (BT-109). | |
| documentAllowances | No | Discounts on the WHOLE invoice, not on one line (BG-20). |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint true), so credit goes to what the text adds: the check covers only a listed subset ('not the official validator'), each finding names rule and fix, and it is 'Free, no token' — a cost/latency signal not derivable from annotations or schema. It does not disclose rate limits or partial-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?
Two compact sentences, front-loaded with what is checked and immediately qualified by its validation limit. Every clause earns its place; nothing is repeated from the schema or annotations.
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 13-parameter, nested-object tool with an output schema, the description supplies purpose, coverage bounds, and cost, and the output schema handles return format. The remaining gap is workflow context — that a Peppol address should be resolved via lookup_peppol_participant before calling this — which is only hinted at inside the schema.
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 92%, so the schema already carries per-field meaning (BT references, EAS codes, endpointId usage rules). The description contributes nothing field-specific, which is acceptable at this coverage level but not additive.
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) against a named, bounded standard (21 published Peppol BIS Billing 3.0 rules) plus a second concrete action (customer's Peppol address registration). This is clearly distinguishable from sibling lookup_peppol_participant, which only resolves a participant, and from review_invoice/check_vat_list.
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 implied rather than stated: an agent infers this is a pre-send readiness check on 'your own invoice'. There is no explicit when-to-use/when-not framing versus siblings such as review_invoice, and no stated prerequisite (e.g. run lookup_peppol_participant first) in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check up to 20 rows of EU VAT numbers in EU VIES, row for row; a malformed or non-EU row is judged locally (not_covered, never invalid). UNKNOWN COSTS NOTHING, and the balance must cover the whole call (20 credits for 20 rows) before it runs. Optional requesterVatId adds a consultation number registered to you; a requester VIES refuses costs nothing. 1 credit (EUR 0.01) per answered row; needs a bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | The list: 1 to 20 rows per call. | |
| requesterVatId | No | Your OWN EU VAT number with country prefix (e.g. BE0403170701). Never stored. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| billing | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations: UNKNOWN results cost nothing, the balance must cover the whole call upfront (20 credits for 20 rows), a refused requester VIES costs nothing, billing is 1 credit per answered row, and a bearer token is required. This is exactly the cost/auth/failure-mode 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-loads the operation, then cost and auth constraints, with no filler sentences. The prose is very dense and crams pricing, auth, and requester behavior into a few long clauses, which costs a little readability but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation; the description still covers cost model, batch limits, auth, and the not_covered verdict rule. Nothing material is missing for an agent to call this 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%, so the baseline is 3, but the description adds real meaning: requesterVatId attaches a consultation number registered to the requester, and a requester the VIES refuses is free. The row-level `counted-per-answered-row` semantics also clarify how the array size maps to cost.
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 up to 20 rows of EU VAT numbers in EU VIES, row for row') with the batch scope and the upstream registry named. An agent can immediately distinguish this from siblings like verify_iban 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?
Explains the key behavioral rule for use — malformed or non-EU rows are judged locally as `not_covered` and never `invalid` — and when to pass requesterVatId (to get a consultation number registered to you). It does not explicitly route the agent away from or toward sibling tools, so it stops 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.
VAT status / does this company exist: look up one EU VAT or enterprise number in EU VIES (Belgian KBO/BCE included). Returns registered name, VAT id, address and status; not proof of every company without VAT registration. 2 credits (EUR 0.02) per successful call; needs a bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| vatNumber | Yes | EU VAT number, with or without its country prefix — e.g. "BE0123456789", "NL855876323B01", "DE811569869" or the bare Belgian enterprise number "0123456789". | |
| countryCode | No | ISO 3166-1 alpha-2 country code of the issuing EU member state (uppercase), e.g. BE, NL, DE, FR. | BE |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| billing | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful operational context beyond that: a bearer token is required and each successful call costs 2 credits (EUR 0.02), plus the important limitation that absence from VIES is not proof of non-existence.
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 core question the tool answers, then scope, then cost/auth constraints, with no filler sentences. It is dense but each clause carries distinct information; only the semicolon-packed cost/auth sentence is slightly compressed.
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?
An output schema exists, so return values need only a summary and the description provides one (name, VAT id, address, status). Combined with the auth, cost, and coverage-limit disclosures, an agent has enough to invoke the tool correctly; only the sibling-routing gap keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema with examples and a default. The description reinforces that a bare Belgian enterprise number is acceptable but adds no format, prefix-handling, or country-interaction detail beyond what the schema already provides, 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 specific verb and resource ('look up one EU VAT or enterprise number in EU VIES') and names the concrete source including the Belgian KBO/BCE variant, so an agent knows exactly what is queried. It does not explicitly contrast itself with the closest sibling, check_vat_list, leaving the single-vs-list distinction to be inferred from 'one'.
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 framing 'VAT status / does this company exist' implies the use case, and the caveat 'not proof of every company without VAT registration' bounds it. However, no alternative tool is named and no explicit when-not-to-use condition is given, so guidance remains implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask live Peppol registers about e-invoice reception, document types and failure contacts; never guarantees delivery. Not a VAT or company-register check; use kbo_company_search (one company) or check_vat_list (a list). Free, no token.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | No | The four-digit Peppol scheme the number is registered under, when you know it: "0208" for a Belgian enterprise number (the mandatory primary scheme for Belgian businesses), "9925" for a Belgian VAT number, "0192" for a Norwegian organisation number. | |
| identifier | Yes | Enterprise/VAT number ("BE 0403.170.701" or "0403170701"), <scheme>:<id>, or iso6523-actorid-upis::<scheme>:<id>. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false. The description adds meaningful non-structured context: it queries LIVE registers, it 'never guarantees delivery' (an important expectation-setting caveat), and it is free with no token/auth needed. Missing only depth on failure modes, but the coverage is strong.
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 purpose followed by the routing caveat. Every clause earns its place: reception/docs/contacts, the delivery caveat, and the sibling redirection.
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?
Output schema exists (so return format needn't be described), annotations cover the safety profile, and the description supplies the remaining essentials: what it queries, the reliability caveat, cost/auth, and how it differs from the two sibling checks. 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 description coverage is 100%, so the schema already documents scheme codes and the accepted identifier formats in detail. The description adds no parameter-level syntax or format information beyond what the schema provides, making the baseline 3 appropriate.
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?
Names a specific verb+resource (ask live Peppol registers about a receiver), states exactly what it returns (e-invoice reception, document types, failure contacts), and explicitly distinguishes itself from register-check siblings. An agent can identify it immediately without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says what it is NOT (a VAT or company-register check) and names the alternatives with their conditions: kbo_company_search for one company, check_vat_list for a list. The when-not/alternative guidance is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a structured invoice, call review_invoice first. Before paying, compare the supplied human approval with the payment and run rail checks (invoice: IBAN, account change). Without approved: review_required or stop, never no_blockers_found. Returns checks and signed evidence. Never pays; unrun checks never pass. Free, no token.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | Yes | Payment fields are always required, approved fields only when approved is supplied: approved.amount and payment.amount/currency (not x402); invoice_bank also approved.payee.name, payment.iban/payeeName; card_or_giftcard approved.payee.merchant, payment.merchant/instrument; crypto_bridge approved.payee.merchant, payment.provider/merchant; x402 approved.amountAtomic/asset/network/payee.payTo, payment.challenge/resourceUrl. | |
| checks | No | Opt-in registers, run only on a connected door. | |
| invoice | No | The invoice as review_invoice takes it. | |
| mandate | No | ||
| payment | Yes | ||
| approved | No | Only supply what a human explicitly approved in this conversation or a supplied approval record; NEVER construct it from the payment request itself; omit it when there is no approval. | |
| ibanOnFile | No | The account on the vendor record. | |
| instructionSource | No | Only supply what a human explicitly approved in this conversation or a supplied approval record; NEVER construct it from the payment request itself; omit it when there is no approval. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| evidence | No | Signed decision evidence, present when a signing key is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, destructiveHint=false), yet the description adds substantial behavior: it never pays, unrun checks never pass, it returns signed evidence, it is free with no token, and it defines a forbidden success state when no approval is supplied. That is exactly the kind of context annotations cannot carry.
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?
Very compact and front-loaded with the prerequisite, and the cost note ('Free, no token') earns its place. The telegraphic style ('Without approved: review_required or stop') is dense enough to risk ambiguity for an unfamiliar reader.
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?
An output schema exists, so return values need not be explained, and the description still notes checks plus signed evidence. For a complex 8-parameter tool with nested objects, it covers prerequisites, failure states, and side-effect freedom well, though rail-specific input requirements are left entirely to the schema.
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 75% and the schema already documents rail-specific required fields and the approved/instructionSource rules. The description still adds the core relationship semantics: approval must be compared against the payment, and the invoice rail specifically checks IBAN and account change. This meaningfully supplements the schema without repeating 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 action (compare supplied approval with the payment and run rail checks) and a clear precondition (review_invoice first for structured invoices). It distinguishes itself from review_invoice by sequencing, but does not explicitly separate itself from the sibling check_payment_change, which overlaps with the 'account change' check it mentions.
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 explicit ordering (call review_invoice first for a structured invoice), the condition for use (before paying), and the required outcome state without an approval (review_required or stop, never no_blockers_found). An agent knows both when to call it and what result to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a structured invoice: Peppol fields, totals, EU VIES VAT, fixes and UBL XML. Never sends; unanswered VAT is unknown. No receiver lookup here. If the receiver has a Peppol address, next call check_peppol_ready with this invoice. 8 credits (EUR 0.08) per review the VAT register answered; needs a bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| lines | Yes | ||
| dueDate | No | ||
| payment | No | Payment instruction carried by the invoice, when it names an IBAN. | |
| currency | No | ISO 4217 currency code (uppercase). | |
| customer | Yes | Buyer / accounting customer party, including an optional draft e-mail recipient. | |
| supplier | Yes | Seller / accounting supplier party, including an optional IBAN for the payment check. | |
| totalVat | No | Caller-stated total VAT (BT-110), used by the arithmetic rule checks. | |
| issueDate | Yes | ||
| totalWithVat | No | Caller-stated invoice total including VAT (BT-112), used by the arithmetic rule checks. | |
| invoiceNumber | Yes | Human-readable invoice number, e.g. "INV-2026-0001". | |
| buyerReference | No | Buyer reference (BT-10), e.g. a PO or cost-centre code. | |
| orderReference | No | Purchase order reference (BT-13). Peppol requires this OR a buyer reference. | |
| totalWithoutVat | No | Caller-stated invoice total excluding VAT (BT-109), used by the arithmetic rule checks. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes | |
| billing | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true. The description adds value beyond them: 'Never sends', that unanswered VAT is reported as unknown, a rate limit/cost ('8 credits (EUR 0.08) per review the VAT register answered') and an auth requirement ('needs a bearer token'). This is meaningful behavioral context, though it stays terse about what a result contains beyond 'fixes and UBL XML'.
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?
Dense and front-loaded: purpose first, then constraints, then routing, then cost/auth. Every clause carries information, though the telegraphic style makes 'fixes' ambiguous and the cost clause is slightly awkwardly worded.
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 complex nested-schema tool with an output schema present, the description covers the essentials an agent needs: side-effect profile, cost model, auth prerequisite, and next-step routing. Only the exact meaning of 'fixes' and the shape of the review verdict are left implicit, which the output schema presumably carries.
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 71% with 14 parameters and rich field-level descriptions (BT codes, EAS schemes, unit codes), so the schema carries most of the semantic load. The description only groups them loosely ('Peppol fields, totals, EU VIES VAT'), adding no syntax or mapping detail, which is the expected baseline when the schema does the heavy lifting.
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/review) on a specific resource (structured invoice) and enumerates the checks performed: Peppol fields, totals, EU VIES VAT, fixes and UBL XML. It also carves out the boundary against siblings by noting 'No receiver lookup here', so an agent can distinguish it from lookup_peppol_participant and check_peppol_ready without reading schemas.
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 explicit when-to-use routing: 'If the receiver has a Peppol address, next call check_peppol_ready with this invoice.' It also states what not to expect ('No receiver lookup here') and the safety posture ('Never sends'), leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an IBAN's structure and check digits for 70+ countries, offline. It never claims the account exists or who owns it. Free, no token.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | The account number to check, as written — spaces and dashes are fine, e.g. "BE68 5390 0754 7034". | |
| expectedCountry | No | Optional ISO 3166-1 alpha-2 country of the party being paid. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds substantial context beyond them: the check is performed offline, requires no token, is free, and explicitly does not assert account existence or ownership. That tells the agent exactly what kind of answer to expect and what it cannot rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and scope, followed by the limitation and the cost/auth note. No filler, no repetition of the title.
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 annotations covering safety and an output schema covering return values, the description only needs to add scope, environment (offline/no token), and result limits — all of which it does. Nothing an agent needs to call this 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 description coverage is 100%, so both parameters (iban format tolerance, optional expectedCountry) are already documented in the schema. The description adds no parameter-level detail beyond that, so the baseline of 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 and resource (check an IBAN) plus the exact scope of the check: structure and check digits, 70+ countries, offline. This is unambiguous next to siblings like check_vat_list or lookup_peppol_participant, which operate on different identifiers.
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 draws a clear boundary on what the result means ('never claims the account exists or who owns it'), which tells the agent when this tool's answer is sufficient and when it is not. It does not, however, name an alternative tool to use for ownership/account existence checks, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_peppol_ready2 fields changedInput schema / properties / customer / properties / endpointId / descriptionPrevious value: -"The party's Peppol address — the identifier the network delivers to, e.g. a Belgian enterprise number."New value: +"The customer's literal UBL EndpointID value, e.g. \"0403170701\": from lookup_peppol_participant copy data.endpointId here, NEVER its whole participantId when endpointScheme is set. Checked as written, NEVER rewritten: another spelling is another address."Input schema / properties / customer / properties / endpointScheme / descriptionPrevious value: -"The four-digit EAS code the address is stated under, e.g. \"0208\" for a Belgian enterprise number."New value: +"The four-digit EAS code the address is stated under, e.g. \"0208\" for a Belgian enterprise number: from lookup_peppol_participant copy data.endpointScheme here."lookup_peppol_participant1 field changedInput schema / properties / identifier / descriptionPrevious value: -"The customer's enterprise or VAT number, as written on the invoice — \"BE 0403.170.701\", \"0403170701\" and \"BE0403170701\" are all accepted."New value: +"Enterprise/VAT number (\"BE 0403.170.701\" or \"0403170701\"), <scheme>:<id>, or iso6523-actorid-upis::<scheme>:<id>."preflight_payment4 fields changedInput schema / properties / approved / descriptionAdded value: +"Only supply what a human explicitly approved in this conversation or a supplied approval record; NEVER construct it from the payment request itself; omit it when there is no approval."Input schema / properties / instructionSource / descriptionAdded value: +"Only supply what a human explicitly approved in this conversation or a supplied approval record; NEVER construct it from the payment request itself; omit it when there is no approval."Input schema / properties / rail / descriptionPrevious value: -"Required: approved.amount and payment.amount/currency (not x402); invoice_bank also approved.payee.name, payment.iban/payeeName; card_or_giftcard approved.payee.merchant, payment.merchant/instrument; crypto_bridge approved.payee.merchant, payment.provider/merchant; x402 approved.amountAtomic/asset/network/payee.payTo, payment.challenge/resourceUrl."New value: +"Payment fields are always required, approved fields only when approved is supplied: approved.amount and payment.amount/currency (not x402); invoice_bank also approved.payee.name, payment.iban/payeeName; card_or_giftcard approved.payee.merchant, payment.merchant/instrument; crypto_bridge approved.payee.merchant, payment.provider/merchant; x402 approved.amountAtomic/asset/network/payee.payTo, payment.challenge/resourceUrl."Input schema / requiredPrevious value: -[
- "rail",
- "approved",
- "payment"
-]New value: +[
+ "rail",
+ "payment"
+]check_vat_list1 field changedInput schema / properties / rows / maxItemsPrevious value: -200New value: +20check_peppol_ready2 fields changedInput schema / properties / documentAllowancesAdded value: +{
+ "description": "Discounts on the WHOLE invoice, not on one line (BG-20).",
+ "items": {
+ "properties": {
+ "amount": {
+ "description": "The amount, excluding VAT (BT-92 for an allowance, BT-99 for a charge).",
+ "type": "number"
+ },
+ "reason": {
+ "description": "Why, e.g. \"Discount\" or \"Freight\".",
+ "type": "string"
+ },
+ "vatPercent": {
+ "description": "The VAT rate it is taxed at, e.g. 21 (BT-96 / BT-103).",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 100,
+ "type": "array"
+}Input schema / properties / documentChargesAdded value: +{
+ "description": "Charges on the WHOLE invoice, e.g. freight (BG-21).",
+ "items": {
+ "properties": {
+ "amount": {
+ "description": "The amount, excluding VAT (BT-92 for an allowance, BT-99 for a charge).",
+ "type": "number"
+ },
+ "reason": {
+ "description": "Why, e.g. \"Discount\" or \"Freight\".",
+ "type": "string"
+ },
+ "vatPercent": {
+ "description": "The VAT rate it is taxed at, e.g. 21 (BT-96 / BT-103).",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 100,
+ "type": "array"
+}analyze_kbo_financialscheck_vat_list_formatcore_conditiondraft_social_contentfetch_web_markdownfile_to_data_inspectfile_to_data_transformformat_peppol_invoicegenerate_pdf_invoicemonitor_sourcesparse_receipt_visiontranscribe_and_slice_audioreview_invoice16 fields changedInput schema / properties / currency / defaultRemoved value: -"EUR"Input schema / properties / customer / descriptionPrevious value: -"Buyer / accounting customer party."New value: +"Buyer / accounting customer party, including an optional draft e-mail recipient."Input schema / properties / customer / properties / emailAdded value: +{
+ "type": "string"
+}Input schema / properties / customer / properties / endpointScheme / descriptionPrevious value: -"Endpoint scheme id (EAS code)."New value: +"Endpoint scheme id (EAS code), e.g. \"0208\" for a Belgian enterprise number or \"0088\" for a GLN."Input schema / properties / lines / items / properties / lineNetAmountAdded value: +{
+ "description": "Caller-stated line total excluding VAT (BT-131), used by the shared Peppol arithmetic rules.",
+ "type": "number"
+}Input schema / properties / lines / items / properties / lineTotalAdded value: +{
+ "description": "Caller-stated line total excluding VAT, compared with quantity × unit price by this review.",
+ "type": "number"
+}Input schema / properties / lines / items / properties / unitCode / defaultRemoved value: -"EA"Input schema / properties / lines / items / properties / unitCode / descriptionPrevious value: -"UN/ECE Rec 20 unit code."New value: +"UN/ECE Rec 20 unit code, e.g. \"HUR\"."Input schema / properties / lines / items / properties / vatPercent / defaultRemoved value: -0Input schema / properties / paymentAdded value: +{
+ "description": "Payment instruction carried by the invoice, when it names an IBAN.",
+ "properties": {
+ "iban": {
+ "description": "IBAN written on the invoice.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / supplier / descriptionPrevious value: -"Seller / accounting supplier party."New value: +"Seller / accounting supplier party, including an optional IBAN for the payment check."Input schema / properties / supplier / properties / endpointScheme / descriptionPrevious value: -"Endpoint scheme id (EAS code)."New value: +"Endpoint scheme id (EAS code), e.g. \"0208\" for a Belgian enterprise number or \"0088\" for a GLN."Input schema / properties / supplier / properties / ibanAdded value: +{
+ "description": "IBAN written on the invoice.",
+ "type": "string"
+}Input schema / properties / totalVatAdded value: +{
+ "description": "Caller-stated total VAT (BT-110), used by the arithmetic rule checks.",
+ "type": "number"
+}Input schema / properties / totalWithVatAdded value: +{
+ "description": "Caller-stated invoice total including VAT (BT-112), used by the arithmetic rule checks.",
+ "type": "number"
+}Input schema / properties / totalWithoutVatAdded value: +{
+ "description": "Caller-stated invoice total excluding VAT (BT-109), used by the arithmetic rule checks.",
+ "type": "number"
+}preflight_paymentanalyze_kbo_financials3 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / vatNumber / minLengthRemoved value: -1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}check_payment_change7 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / ibanOnFile / descriptionPrevious value: -"The account currently on the vendor record. Leave it out for a first registration; the answer then says nothing could be compared."New value: +"The account currently on the vendor record."Input schema / properties / ibanOnFile / maxLengthRemoved value: -64Input schema / properties / newIban / maxLengthRemoved value: -64Input schema / properties / newIban / minLengthRemoved value: -1Input schema / properties / supplierCountry / descriptionPrevious value: -"ISO 3166-1 alpha-2 country where the supplier is established, e.g. BE. When given, an account issued elsewhere is a red flag."New value: +"ISO 3166-1 alpha-2 country where the supplier is established, e.g. BE."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "evidence": {
+ "description": "Signed decision evidence, present when a signing key is configured.",
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}check_peppol_ready16 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / buyerReference / maxLengthRemoved value: -200Input schema / properties / customer / properties / endpointId / maxLengthRemoved value: -60Input schema / properties / customer / properties / name / descriptionRemoved value: -"The party's name as it appears on the invoice."Input schema / properties / customer / properties / name / maxLengthRemoved value: -200Input schema / properties / invoiceNumber / maxLengthRemoved value: -120Input schema / properties / issueDate / descriptionPrevious value: -"The issue date (BT-2). Peppol requires YYYY-MM-DD."New value: +"The issue date (BT-2)."Input schema / properties / lines / descriptionRemoved value: -"The invoice lines."Input schema / properties / lines / items / properties / description / maxLengthRemoved value: -400Input schema / properties / orderReference / descriptionPrevious value: -"The purchase order number (BT-13). The alternative to a buyer reference."New value: +"The purchase order number (BT-13)."Input schema / properties / orderReference / maxLengthRemoved value: -200Input schema / properties / supplier / properties / endpointId / maxLengthRemoved value: -60Input schema / properties / supplier / properties / name / descriptionRemoved value: -"The party's name as it appears on the invoice."Input schema / properties / supplier / properties / name / maxLengthRemoved value: -200Input schema / properties / totalWithoutVat / descriptionPrevious value: -"Invoice total excluding VAT (BT-109). Supply it and the arithmetic rules are checked."New value: +"Invoice total excluding VAT (BT-109)."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}check_vat_list8 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / requesterVatId / descriptionPrevious value: -"Your OWN EU VAT number with country prefix (e.g. BE0403170701). When given, the European Commission issues a consultation number per answered row, registered to you. Optional. Never stored."New value: +"Your OWN EU VAT number with country prefix (e.g. BE0403170701). Never stored."Input schema / properties / rows / descriptionPrevious value: -"The list: 1 to 20 rows per call. A longer list is refused with the limit named — send it in parts of 20."New value: +"The list: 1 to 20 rows per call."Input schema / properties / rows / items / properties / reference / descriptionPrevious value: -"Your own label for the row — a customer number, a name. Optional, at most 80 characters. It is echoed back, never interpreted."New value: +"Your own label for the row — a customer number, a name. It is echoed back, never interpreted."Input schema / properties / rows / items / properties / reference / maxLengthRemoved value: -200Input schema / properties / rows / items / properties / vatId / descriptionPrevious value: -"The VAT number as written, WITH its two-letter country prefix, e.g. \"BE0400378485\" or \"NL 8558.76.323.B01\". Spaces, dots and dashes are fine."New value: +"The VAT number as written, WITH its two-letter country prefix, e.g. \"BE0400378485\" or \"NL 8558.76.323.B01\"."Input schema / properties / rows / items / properties / vatId / maxLengthRemoved value: -200Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}check_vat_list_format7 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / rows / descriptionPrevious value: -"The list: 1 to 20 rows per call. A longer list is refused with the limit named — send it in parts of 20."New value: +"The list: 1 to 20 rows per call."Input schema / properties / rows / items / properties / reference / descriptionPrevious value: -"Your own label for the row — a customer number, a name. Optional, at most 80 characters. It is echoed back, never interpreted."New value: +"Your own label for the row — a customer number, a name. It is echoed back, never interpreted."Input schema / properties / rows / items / properties / reference / maxLengthRemoved value: -200Input schema / properties / rows / items / properties / vatId / descriptionPrevious value: -"The VAT number as written, WITH its two-letter country prefix, e.g. \"BE0400378485\" or \"NL 8558.76.323.B01\". Spaces, dots and dashes are fine."New value: +"The VAT number as written, WITH its two-letter country prefix, e.g. \"BE0400378485\" or \"NL 8558.76.323.B01\"."Input schema / properties / rows / items / properties / vatId / maxLengthRemoved value: -200Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}core_condition6 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / label / descriptionRemoved value: -"Optional human label, e.g. \"High-value invoice?\"."Input schema / properties / label / maxLengthRemoved value: -120Input schema / properties / left / anyOfPrevious value: -[
- {
- "maxLength": 2000,
- "type": "string"
- },
- {
- "type": "number"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+]Input schema / properties / right / anyOfPrevious value: -[
- {
- "maxLength": 2000,
- "type": "string"
- },
- {
- "type": "number"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}draft_social_content21 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / avoidSignaturesRemoved value: -{
- "description": "Compact signatures of this agent's recent posts — the deterministic anti-repetition gate drops any draft too similar to one of these.",
- "items": {
- "properties": {
- "at": {
- "maxLength": 40,
- "type": "string"
- },
- "excerpt": {
- "maxLength": 200,
- "type": "string"
- },
- "sig": {
- "items": {
- "maxLength": 12,
- "type": "string"
- },
- "maxItems": 40,
- "type": "array"
- }
- },
- "required": [
- "sig",
- "excerpt",
- "at"
- ],
- "type": "object"
- },
- "maxItems": 24,
- "type": "array"
-}Input schema / properties / bannedClaims / items / maxLengthRemoved value: -200Input schema / properties / bannedClaims / items / minLengthRemoved value: -1Input schema / properties / campaignRemoved value: -{
- "description": "Active campaign goal + CTA policy, when one is running.",
- "maxLength": 200,
- "type": "string"
-}Input schema / properties / context / maxLengthRemoved value: -12000Input schema / properties / contractRemoved value: -{
- "description": "The agent's JOB CONTRACT (purpose/audience/outcome/done).",
- "maxLength": 700,
- "type": "string"
-}Input schema / properties / facts / maxLengthRemoved value: -600Input schema / properties / feedbackNoteRemoved value: -{
- "description": "Real recorded owner behaviour on this agent's recent work.",
- "maxLength": 600,
- "type": "string"
-}Input schema / properties / formatRemoved value: -{
- "description": "The post shape to write in (e.g. how-to, story, question).",
- "maxLength": 24,
- "type": "string"
-}Input schema / properties / learningsRemoved value: -{
- "description": "Real recorded outcomes (never invented) to improve on.",
- "maxLength": 800,
- "type": "string"
-}Input schema / properties / minAnchorsRemoved value: -{
- "description": "Concrete-detail floor per post (escalates on owner feedback).",
- "maximum": 2,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / ownerUpdateRemoved value: -{
- "description": "The owner's own news ('we shipped X') — the post's core material when present.",
- "maxLength": 600,
- "type": "string"
-}Input schema / properties / pillarRemoved value: -{
- "description": "Today's editorial pillar for these drafts.",
- "maxLength": 60,
- "type": "string"
-}Input schema / properties / recentNoteRemoved value: -{
- "description": "Prompt note listing recent posts the model must not repeat.",
- "maxLength": 1200,
- "type": "string"
-}Input schema / properties / requireFreshBasisRemoved value: -{
- "description": "Currency-dependent agents: refuse (honestly, before any model spend) when no fresh signals exist to work from.",
- "type": "boolean"
-}Input schema / properties / signalsRemoved value: -{
- "description": "Recent signals from the tenant's APPROVED sources, with trust tiers. Posts that use one must cite its ref in their sources array.",
- "items": {
- "properties": {
- "date": {
- "maxLength": 12,
- "type": "string"
- },
- "label": {
- "maxLength": 60,
- "type": "string"
- },
- "ref": {
- "maxLength": 8,
- "minLength": 1,
- "type": "string"
- },
- "summary": {
- "maxLength": 240,
- "type": "string"
- },
- "tier": {
- "enum": [
- "approved_fact",
- "user_material",
- "observed_external"
- ],
- "type": "string"
- },
- "title": {
- "maxLength": 120,
- "type": "string"
- }
- },
- "required": [
- "ref",
- "label",
- "tier",
- "date",
- "title",
- "summary"
- ],
- "type": "object"
- },
- "maxItems": 6,
- "type": "array"
-}Input schema / properties / tone / maxLengthRemoved value: -80Input schema / properties / topic / descriptionRemoved value: -"What the posts should be about, in one or two sentences."Input schema / properties / topic / maxLengthRemoved value: -500Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}fetch_web_markdown3 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / url / maxLengthRemoved value: -2000Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}file_to_data_inspect14 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / content / descriptionPrevious value: -"The file's TEXT, for CSV / delimited text / JSON / NDJSON. Give this OR contentBase64. At most 3 MiB."New value: +"The file's TEXT, for CSV / delimited text / JSON / NDJSON. Give this OR contentBase64."Input schema / properties / content / maxLengthRemoved value: -3145728Input schema / properties / contentBase64 / descriptionPrevious value: -"The file's BYTES, base64-encoded — required for .xlsx, fine for any format. Give this OR content. At most 3 MiB of file."New value: +"The file's BYTES, base64-encoded — required for .xlsx, fine for any format. Give this OR content."Input schema / properties / contentBase64 / maxLengthRemoved value: -4259840Input schema / properties / fileName / descriptionPrevious value: -"The file's name, e.g. \"prices.csv\". Only its extension is used (.csv .tsv .txt .xlsx .xlsm .json .ndjson); it is never stored or logged."New value: +"The file's name, e.g. \"prices.csv\"."Input schema / properties / fileName / maxLengthRemoved value: -255Input schema / properties / headerRow / descriptionPrevious value: -"The row number of the header row, counted from 1. Default: the first row that holds anything."New value: +"The row number of the header row, counted from 1."Input schema / properties / sheet / anyOfPrevious value: -[
- {
- "maxLength": 255,
- "type": "string"
- },
- {
- "maximum": 999,
- "minimum": 0,
- "type": "integer"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "maximum": 999,
+ "minimum": 0,
+ "type": "integer"
+ }
+]Input schema / properties / sheet / descriptionPrevious value: -"XLSX only: the sheet's name exactly as written, or its position starting at 0. Default: the first sheet."New value: +"XLSX only: the sheet's name exactly as written, or its position starting at 0."Input schema / properties / targetSchema / additionalPropertiesRemoved value: -{}Input schema / properties / targetSchema / propertiesRemoved value: -{}Input schema / properties / targetSchemaId / maxLengthRemoved value: -64Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}file_to_data_transform19 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / content / descriptionPrevious value: -"The file's TEXT, for CSV / delimited text / JSON / NDJSON. Give this OR contentBase64. At most 3 MiB."New value: +"The file's TEXT, for CSV / delimited text / JSON / NDJSON. Give this OR contentBase64."Input schema / properties / content / maxLengthRemoved value: -3145728Input schema / properties / contentBase64 / descriptionPrevious value: -"The file's BYTES, base64-encoded — required for .xlsx, fine for any format. Give this OR content. At most 3 MiB of file."New value: +"The file's BYTES, base64-encoded — required for .xlsx, fine for any format. Give this OR content."Input schema / properties / contentBase64 / maxLengthRemoved value: -4259840Input schema / properties / fileName / descriptionPrevious value: -"The file's name, e.g. \"prices.csv\". Only its extension is used (.csv .tsv .txt .xlsx .xlsm .json .ndjson); it is never stored or logged."New value: +"The file's name, e.g. \"prices.csv\"."Input schema / properties / fileName / maxLengthRemoved value: -255Input schema / properties / headerRow / descriptionPrevious value: -"The row number of the header row, counted from 1. Default: the first row that holds anything."New value: +"The row number of the header row, counted from 1."Input schema / properties / limit / descriptionPrevious value: -"Rows in this page. Default 100; an answer never carries more than about 400 kB of rows, so a page may be shorter than asked."New value: +"Rows in this page."Input schema / properties / mapping / additionalPropertiesRemoved value: -{}Input schema / properties / mapping / propertiesRemoved value: -{}Input schema / properties / offset / descriptionPrevious value: -"First row of the page, starting at 0. Use page.nextOffset of the previous answer."New value: +"First row of the page, starting at 0."Input schema / properties / offset / maximumRemoved value: -9007199254740991Input schema / properties / sheet / anyOfPrevious value: -[
- {
- "maxLength": 255,
- "type": "string"
- },
- {
- "maximum": 999,
- "minimum": 0,
- "type": "integer"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "maximum": 999,
+ "minimum": 0,
+ "type": "integer"
+ }
+]Input schema / properties / sheet / descriptionPrevious value: -"XLSX only: the sheet's name exactly as written, or its position starting at 0. Default: the first sheet."New value: +"XLSX only: the sheet's name exactly as written, or its position starting at 0."Input schema / properties / targetSchema / additionalPropertiesRemoved value: -{}Input schema / properties / targetSchema / propertiesRemoved value: -{}Input schema / properties / targetSchemaId / maxLengthRemoved value: -64Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}format_peppol_invoice72 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / buyerReference / maxLengthRemoved value: -120Input schema / properties / buyerReference / minLengthRemoved value: -1Input schema / properties / currency / descriptionPrevious value: -"ISO 4217 currency code (uppercase). Defaults to EUR."New value: +"ISO 4217 currency code (uppercase)."Input schema / properties / currency / enumRemoved value: -[
- "EUR",
- "USD",
- "GBP",
- "CHF",
- "DKK",
- "SEK",
- "NOK",
- "PLN",
- "CZK",
- "HUF",
- "RON",
- "BGN",
- "ISK",
- "JPY",
- "CNY",
- "INR",
- "CAD",
- "AUD",
- "NZD",
- "BRL",
- "MXN",
- "ZAR",
- "AED",
- "SAR",
- "SGD",
- "HKD",
- "KRW",
- "TRY",
- "ILS",
- "KWD",
- "BHD",
- "OMR"
-]Input schema / properties / customer / properties / city / descriptionRemoved value: -"City / town name."Input schema / properties / customer / properties / city / maxLengthRemoved value: -100Input schema / properties / customer / properties / city / minLengthRemoved value: -1Input schema / properties / customer / properties / countryCode / enumRemoved value: -[
- "AT",
- "BE",
- "BG",
- "HR",
- "CY",
- "CZ",
- "DK",
- "EE",
- "FI",
- "FR",
- "DE",
- "GR",
- "HU",
- "IE",
- "IT",
- "LV",
- "LT",
- "LU",
- "MT",
- "NL",
- "PL",
- "PT",
- "RO",
- "SK",
- "SI",
- "ES",
- "SE",
- "IS",
- "LI",
- "NO",
- "GB",
- "CH",
- "US",
- "CA",
- "MX",
- "BR",
- "AU",
- "NZ",
- "JP",
- "CN",
- "IN",
- "KR",
- "SG",
- "HK",
- "AE",
- "SA",
- "ZA",
- "TR",
- "IL",
- "UA",
- "RS"
-]Input schema / properties / customer / properties / endpointId / maxLengthRemoved value: -60Input schema / properties / customer / properties / endpointId / minLengthRemoved value: -1Input schema / properties / customer / properties / endpointScheme / descriptionPrevious value: -"Endpoint scheme id (EAS code). Defaults to \"0088\" (GLN)."New value: +"Endpoint scheme id (EAS code)."Input schema / properties / customer / properties / endpointScheme / minLengthRemoved value: -1Input schema / properties / customer / properties / name / descriptionRemoved value: -"Trading / display name of the party."Input schema / properties / customer / properties / name / maxLengthRemoved value: -200Input schema / properties / customer / properties / name / minLengthRemoved value: -1Input schema / properties / customer / properties / postalZone / descriptionRemoved value: -"Postal / ZIP code."Input schema / properties / customer / properties / postalZone / minLengthRemoved value: -1Input schema / properties / customer / properties / registrationName / descriptionRemoved value: -"Legal registration name. Defaults to the trading name."Input schema / properties / customer / properties / registrationName / maxLengthRemoved value: -200Input schema / properties / customer / properties / registrationName / minLengthRemoved value: -1Input schema / properties / customer / properties / street / descriptionRemoved value: -"Street name and number."Input schema / properties / customer / properties / street / maxLengthRemoved value: -200Input schema / properties / customer / properties / street / minLengthRemoved value: -1Input schema / properties / customer / properties / vatId / maxLengthRemoved value: -60Input schema / properties / customer / properties / vatId / minLengthRemoved value: -1Input schema / properties / dueDate / descriptionRemoved value: -"Optional payment due date (YYYY-MM-DD)."Input schema / properties / dueDate / formatAdded value: +"date"Input schema / properties / dueDate / patternRemoved value: -"^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01])$"Input schema / properties / invoiceNumber / maxLengthRemoved value: -80Input schema / properties / invoiceNumber / minLengthRemoved value: -1Input schema / properties / issueDate / descriptionRemoved value: -"Issue date (YYYY-MM-DD)."Input schema / properties / issueDate / formatAdded value: +"date"Input schema / properties / issueDate / patternRemoved value: -"^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01])$"Input schema / properties / lines / descriptionRemoved value: -"Invoice lines. Totals are computed from these."Input schema / properties / lines / items / properties / description / descriptionRemoved value: -"Description of the goods or service for this line."Input schema / properties / lines / items / properties / description / maxLengthRemoved value: -500Input schema / properties / lines / items / properties / description / minLengthRemoved value: -1Input schema / properties / lines / items / properties / quantity / descriptionRemoved value: -"Quantity invoiced for this line."Input schema / properties / lines / items / properties / quantity / maximumRemoved value: -1000000Input schema / properties / lines / items / properties / taxCategory / descriptionPrevious value: -"Override the derived UNCL5305 VAT category. Omit to derive S (rated) or Z (zero-rated) automatically from vatPercent."New value: +"Override the derived UNCL5305 VAT category."Input schema / properties / lines / items / properties / unitCode / descriptionPrevious value: -"UN/ECE Rec 20 unit code. Defaults to \"EA\" (each)."New value: +"UN/ECE Rec 20 unit code."Input schema / properties / lines / items / properties / unitCode / minLengthRemoved value: -1Input schema / properties / lines / items / properties / unitPrice / maximumRemoved value: -100000000Input schema / properties / lines / items / properties / vatPercent / descriptionPrevious value: -"VAT rate as a percentage (0–100). Defaults to 0 (zero-rated)."New value: +"VAT rate as a percentage (0–100)."Input schema / properties / note / descriptionRemoved value: -"Free-text invoice note."Input schema / properties / note / maxLengthRemoved value: -1000Input schema / properties / note / minLengthRemoved value: -1Input schema / properties / orderReference / maxLengthRemoved value: -120Input schema / properties / orderReference / minLengthRemoved value: -1Input schema / properties / supplier / properties / city / descriptionRemoved value: -"City / town name."Input schema / properties / supplier / properties / city / maxLengthRemoved value: -100Input schema / properties / supplier / properties / city / minLengthRemoved value: -1Input schema / properties / supplier / properties / countryCode / enumRemoved value: -[
- "AT",
- "BE",
- "BG",
- "HR",
- "CY",
- "CZ",
- "DK",
- "EE",
- "FI",
- "FR",
- "DE",
- "GR",
- "HU",
- "IE",
- "IT",
- "LV",
- "LT",
- "LU",
- "MT",
- "NL",
- "PL",
- "PT",
- "RO",
- "SK",
- "SI",
- "ES",
- "SE",
- "IS",
- "LI",
- "NO",
- "GB",
- "CH",
- "US",
- "CA",
- "MX",
- "BR",
- "AU",
- "NZ",
- "JP",
- "CN",
- "IN",
- "KR",
- "SG",
- "HK",
- "AE",
- "SA",
- "ZA",
- "TR",
- "IL",
- "UA",
- "RS"
-]Input schema / properties / supplier / properties / endpointId / maxLengthRemoved value: -60Input schema / properties / supplier / properties / endpointId / minLengthRemoved value: -1Input schema / properties / supplier / properties / endpointScheme / descriptionPrevious value: -"Endpoint scheme id (EAS code). Defaults to \"0088\" (GLN)."New value: +"Endpoint scheme id (EAS code)."Input schema / properties / supplier / properties / endpointScheme / minLengthRemoved value: -1Input schema / properties / supplier / properties / name / descriptionRemoved value: -"Trading / display name of the party."Input schema / properties / supplier / properties / name / maxLengthRemoved value: -200Input schema / properties / supplier / properties / name / minLengthRemoved value: -1Input schema / properties / supplier / properties / postalZone / descriptionRemoved value: -"Postal / ZIP code."Input schema / properties / supplier / properties / postalZone / minLengthRemoved value: -1Input schema / properties / supplier / properties / registrationName / descriptionRemoved value: -"Legal registration name. Defaults to the trading name."Input schema / properties / supplier / properties / registrationName / maxLengthRemoved value: -200Input schema / properties / supplier / properties / registrationName / minLengthRemoved value: -1Input schema / properties / supplier / properties / street / descriptionRemoved value: -"Street name and number."Input schema / properties / supplier / properties / street / maxLengthRemoved value: -200Input schema / properties / supplier / properties / street / minLengthRemoved value: -1Input schema / properties / supplier / properties / vatId / maxLengthRemoved value: -60Input schema / properties / supplier / properties / vatId / minLengthRemoved value: -1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}generate_pdf_invoice35 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / currency / descriptionPrevious value: -"ISO 4217 currency code (uppercase). Defaults to EUR."New value: +"ISO 4217 currency code (uppercase)."Input schema / properties / currency / enumRemoved value: -[
- "EUR",
- "USD",
- "GBP",
- "CHF",
- "DKK",
- "SEK",
- "NOK",
- "PLN",
- "CZK",
- "HUF",
- "RON",
- "BGN",
- "ISK",
- "JPY",
- "CNY",
- "INR",
- "CAD",
- "AUD",
- "NZD",
- "BRL",
- "MXN",
- "ZAR",
- "AED",
- "SAR",
- "SGD",
- "HKD",
- "KRW",
- "TRY",
- "ILS",
- "KWD",
- "BHD",
- "OMR"
-]Input schema / properties / customer / properties / address / descriptionRemoved value: -"Postal address (free text; newlines allowed)."Input schema / properties / customer / properties / address / maxLengthRemoved value: -400Input schema / properties / customer / properties / email / descriptionRemoved value: -"Contact email."Input schema / properties / customer / properties / email / maxLengthRemoved value: -200Input schema / properties / customer / properties / name / descriptionRemoved value: -"Legal / display name."Input schema / properties / customer / properties / name / maxLengthRemoved value: -200Input schema / properties / customer / properties / name / minLengthRemoved value: -1Input schema / properties / customer / properties / phone / descriptionRemoved value: -"Contact phone."Input schema / properties / customer / properties / registrationNumber / maxLengthRemoved value: -60Input schema / properties / customer / properties / vatId / maxLengthRemoved value: -60Input schema / properties / dueDate / minLengthRemoved value: -1Input schema / properties / invoiceNumber / maxLengthRemoved value: -60Input schema / properties / invoiceNumber / minLengthRemoved value: -1Input schema / properties / issueDate / minLengthRemoved value: -1Input schema / properties / lines / descriptionRemoved value: -"One or more invoice line items."Input schema / properties / lines / items / properties / description / descriptionRemoved value: -"Line item description."Input schema / properties / lines / items / properties / description / maxLengthRemoved value: -300Input schema / properties / lines / items / properties / description / minLengthRemoved value: -1Input schema / properties / lines / items / properties / quantity / descriptionRemoved value: -"Quantity."Input schema / properties / notes / descriptionRemoved value: -"Optional footer notes / payment terms."Input schema / properties / notes / maxLengthRemoved value: -1000Input schema / properties / supplier / properties / address / descriptionRemoved value: -"Postal address (free text; newlines allowed)."Input schema / properties / supplier / properties / address / maxLengthRemoved value: -400Input schema / properties / supplier / properties / email / descriptionRemoved value: -"Contact email."Input schema / properties / supplier / properties / email / maxLengthRemoved value: -200Input schema / properties / supplier / properties / name / descriptionRemoved value: -"Legal / display name."Input schema / properties / supplier / properties / name / maxLengthRemoved value: -200Input schema / properties / supplier / properties / name / minLengthRemoved value: -1Input schema / properties / supplier / properties / phone / descriptionRemoved value: -"Contact phone."Input schema / properties / supplier / properties / registrationNumber / maxLengthRemoved value: -60Input schema / properties / supplier / properties / vatId / maxLengthRemoved value: -60Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}kbo_company_search5 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / countryCode / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code of the issuing EU member state (uppercase), e.g. BE, NL, DE, FR. Defaults to BE; inferred from the VAT prefix when present."New value: +"ISO 3166-1 alpha-2 country code of the issuing EU member state (uppercase), e.g. BE, NL, DE, FR."Input schema / properties / countryCode / enumRemoved value: -[
- "AT",
- "BE",
- "BG",
- "HR",
- "CY",
- "CZ",
- "DK",
- "EE",
- "FI",
- "FR",
- "DE",
- "GR",
- "HU",
- "IE",
- "IT",
- "LV",
- "LT",
- "LU",
- "MT",
- "NL",
- "PL",
- "PT",
- "RO",
- "SK",
- "SI",
- "ES",
- "SE",
- "IS",
- "LI",
- "NO",
- "GB",
- "CH",
- "US",
- "CA",
- "MX",
- "BR",
- "AU",
- "NZ",
- "JP",
- "CN",
- "IN",
- "KR",
- "SG",
- "HK",
- "AE",
- "SA",
- "ZA",
- "TR",
- "IL",
- "UA",
- "RS"
-]Input schema / properties / vatNumber / minLengthRemoved value: -1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}lookup_peppol_participant5 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / identifier / maxLengthRemoved value: -60Input schema / properties / identifier / minLengthRemoved value: -1Input schema / properties / scheme / descriptionPrevious value: -"The four-digit Peppol scheme the number is registered under, when you know it: \"0208\" for a Belgian enterprise number (the mandatory primary scheme for Belgian businesses), \"9925\" for a Belgian VAT number, \"0192\" for a Norwegian organisation number. Left out, a Belgian enterprise number is assumed."New value: +"The four-digit Peppol scheme the number is registered under, when you know it: \"0208\" for a Belgian enterprise number (the mandatory primary scheme for Belgian businesses), \"9925\" for a Belgian VAT number, \"0192\" for a Norwegian organisation number."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}monitor_sources2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}parse_receipt_vision4 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / imageBase64 / maxLengthRemoved value: -7000000Input schema / properties / imageUrl / maxLengthRemoved value: -2000Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}review_invoice72 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / buyerReference / maxLengthRemoved value: -120Input schema / properties / buyerReference / minLengthRemoved value: -1Input schema / properties / currency / descriptionPrevious value: -"ISO 4217 currency code (uppercase). Defaults to EUR."New value: +"ISO 4217 currency code (uppercase)."Input schema / properties / currency / enumRemoved value: -[
- "EUR",
- "USD",
- "GBP",
- "CHF",
- "DKK",
- "SEK",
- "NOK",
- "PLN",
- "CZK",
- "HUF",
- "RON",
- "BGN",
- "ISK",
- "JPY",
- "CNY",
- "INR",
- "CAD",
- "AUD",
- "NZD",
- "BRL",
- "MXN",
- "ZAR",
- "AED",
- "SAR",
- "SGD",
- "HKD",
- "KRW",
- "TRY",
- "ILS",
- "KWD",
- "BHD",
- "OMR"
-]Input schema / properties / customer / properties / city / descriptionRemoved value: -"City / town name."Input schema / properties / customer / properties / city / maxLengthRemoved value: -100Input schema / properties / customer / properties / city / minLengthRemoved value: -1Input schema / properties / customer / properties / countryCode / enumRemoved value: -[
- "AT",
- "BE",
- "BG",
- "HR",
- "CY",
- "CZ",
- "DK",
- "EE",
- "FI",
- "FR",
- "DE",
- "GR",
- "HU",
- "IE",
- "IT",
- "LV",
- "LT",
- "LU",
- "MT",
- "NL",
- "PL",
- "PT",
- "RO",
- "SK",
- "SI",
- "ES",
- "SE",
- "IS",
- "LI",
- "NO",
- "GB",
- "CH",
- "US",
- "CA",
- "MX",
- "BR",
- "AU",
- "NZ",
- "JP",
- "CN",
- "IN",
- "KR",
- "SG",
- "HK",
- "AE",
- "SA",
- "ZA",
- "TR",
- "IL",
- "UA",
- "RS"
-]Input schema / properties / customer / properties / endpointId / maxLengthRemoved value: -60Input schema / properties / customer / properties / endpointId / minLengthRemoved value: -1Input schema / properties / customer / properties / endpointScheme / descriptionPrevious value: -"Endpoint scheme id (EAS code). Defaults to \"0088\" (GLN)."New value: +"Endpoint scheme id (EAS code)."Input schema / properties / customer / properties / endpointScheme / minLengthRemoved value: -1Input schema / properties / customer / properties / name / descriptionRemoved value: -"Trading / display name of the party."Input schema / properties / customer / properties / name / maxLengthRemoved value: -200Input schema / properties / customer / properties / name / minLengthRemoved value: -1Input schema / properties / customer / properties / postalZone / descriptionRemoved value: -"Postal / ZIP code."Input schema / properties / customer / properties / postalZone / minLengthRemoved value: -1Input schema / properties / customer / properties / registrationName / descriptionRemoved value: -"Legal registration name. Defaults to the trading name."Input schema / properties / customer / properties / registrationName / maxLengthRemoved value: -200Input schema / properties / customer / properties / registrationName / minLengthRemoved value: -1Input schema / properties / customer / properties / street / descriptionRemoved value: -"Street name and number."Input schema / properties / customer / properties / street / maxLengthRemoved value: -200Input schema / properties / customer / properties / street / minLengthRemoved value: -1Input schema / properties / customer / properties / vatId / maxLengthRemoved value: -60Input schema / properties / customer / properties / vatId / minLengthRemoved value: -1Input schema / properties / dueDate / descriptionRemoved value: -"Optional payment due date (YYYY-MM-DD)."Input schema / properties / dueDate / formatAdded value: +"date"Input schema / properties / dueDate / patternRemoved value: -"^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01])$"Input schema / properties / invoiceNumber / maxLengthRemoved value: -80Input schema / properties / invoiceNumber / minLengthRemoved value: -1Input schema / properties / issueDate / descriptionRemoved value: -"Issue date (YYYY-MM-DD)."Input schema / properties / issueDate / formatAdded value: +"date"Input schema / properties / issueDate / patternRemoved value: -"^\\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01])$"Input schema / properties / lines / descriptionRemoved value: -"Invoice lines. Totals are computed from these."Input schema / properties / lines / items / properties / description / descriptionRemoved value: -"Description of the goods or service for this line."Input schema / properties / lines / items / properties / description / maxLengthRemoved value: -500Input schema / properties / lines / items / properties / description / minLengthRemoved value: -1Input schema / properties / lines / items / properties / quantity / descriptionRemoved value: -"Quantity invoiced for this line."Input schema / properties / lines / items / properties / quantity / maximumRemoved value: -1000000Input schema / properties / lines / items / properties / taxCategory / descriptionPrevious value: -"Override the derived UNCL5305 VAT category. Omit to derive S (rated) or Z (zero-rated) automatically from vatPercent."New value: +"Override the derived UNCL5305 VAT category."Input schema / properties / lines / items / properties / unitCode / descriptionPrevious value: -"UN/ECE Rec 20 unit code. Defaults to \"EA\" (each)."New value: +"UN/ECE Rec 20 unit code."Input schema / properties / lines / items / properties / unitCode / minLengthRemoved value: -1Input schema / properties / lines / items / properties / unitPrice / maximumRemoved value: -100000000Input schema / properties / lines / items / properties / vatPercent / descriptionPrevious value: -"VAT rate as a percentage (0–100). Defaults to 0 (zero-rated)."New value: +"VAT rate as a percentage (0–100)."Input schema / properties / note / descriptionRemoved value: -"Free-text invoice note."Input schema / properties / note / maxLengthRemoved value: -1000Input schema / properties / note / minLengthRemoved value: -1Input schema / properties / orderReference / maxLengthRemoved value: -120Input schema / properties / orderReference / minLengthRemoved value: -1Input schema / properties / supplier / properties / city / descriptionRemoved value: -"City / town name."Input schema / properties / supplier / properties / city / maxLengthRemoved value: -100Input schema / properties / supplier / properties / city / minLengthRemoved value: -1Input schema / properties / supplier / properties / countryCode / enumRemoved value: -[
- "AT",
- "BE",
- "BG",
- "HR",
- "CY",
- "CZ",
- "DK",
- "EE",
- "FI",
- "FR",
- "DE",
- "GR",
- "HU",
- "IE",
- "IT",
- "LV",
- "LT",
- "LU",
- "MT",
- "NL",
- "PL",
- "PT",
- "RO",
- "SK",
- "SI",
- "ES",
- "SE",
- "IS",
- "LI",
- "NO",
- "GB",
- "CH",
- "US",
- "CA",
- "MX",
- "BR",
- "AU",
- "NZ",
- "JP",
- "CN",
- "IN",
- "KR",
- "SG",
- "HK",
- "AE",
- "SA",
- "ZA",
- "TR",
- "IL",
- "UA",
- "RS"
-]Input schema / properties / supplier / properties / endpointId / maxLengthRemoved value: -60Input schema / properties / supplier / properties / endpointId / minLengthRemoved value: -1Input schema / properties / supplier / properties / endpointScheme / descriptionPrevious value: -"Endpoint scheme id (EAS code). Defaults to \"0088\" (GLN)."New value: +"Endpoint scheme id (EAS code)."Input schema / properties / supplier / properties / endpointScheme / minLengthRemoved value: -1Input schema / properties / supplier / properties / name / descriptionRemoved value: -"Trading / display name of the party."Input schema / properties / supplier / properties / name / maxLengthRemoved value: -200Input schema / properties / supplier / properties / name / minLengthRemoved value: -1Input schema / properties / supplier / properties / postalZone / descriptionRemoved value: -"Postal / ZIP code."Input schema / properties / supplier / properties / postalZone / minLengthRemoved value: -1Input schema / properties / supplier / properties / registrationName / descriptionRemoved value: -"Legal registration name. Defaults to the trading name."Input schema / properties / supplier / properties / registrationName / maxLengthRemoved value: -200Input schema / properties / supplier / properties / registrationName / minLengthRemoved value: -1Input schema / properties / supplier / properties / street / descriptionRemoved value: -"Street name and number."Input schema / properties / supplier / properties / street / maxLengthRemoved value: -200Input schema / properties / supplier / properties / street / minLengthRemoved value: -1Input schema / properties / supplier / properties / vatId / maxLengthRemoved value: -60Input schema / properties / supplier / properties / vatId / minLengthRemoved value: -1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}transcribe_and_slice_audio4 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / audioBase64 / maxLengthRemoved value: -34000000Input schema / properties / audioUrl / maxLengthRemoved value: -2000Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "billing": {
+ "type": "object"
+ },
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data",
+ "billing"
+ ],
+ "type": "object"
+}verify_iban5 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / properties / expectedCountry / descriptionPrevious value: -"Optional ISO 3166-1 alpha-2 country of the party being paid. When given, the answer reports whether the account is issued in that country — as an observation with both countries named, never as a fraud verdict."New value: +"Optional ISO 3166-1 alpha-2 country of the party being paid."Input schema / properties / iban / maxLengthRemoved value: -64Input schema / properties / iban / minLengthRemoved value: -1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "type": "object"
+ },
+ "kind": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "data"
+ ],
+ "type": "object"
+}check_payment_change1 field changedInput schema / properties / supplierCountry / patternAdded value: +"^[A-Za-z]{2}$"format_peppol_invoice1 field changedInput schema / properties / orderReferenceAdded value: +{
+ "description": "Purchase order reference (BT-13). Peppol requires this OR a buyer reference.",
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+}review_invoice1 field changedInput schema / properties / orderReferenceAdded value: +{
+ "description": "Purchase order reference (BT-13). Peppol requires this OR a buyer reference.",
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+}analyze_kbo_financialscheck_payment_changecheck_peppol_readycheck_vat_listcheck_vat_list_formatcore_conditiondraft_social_contentfetch_web_markdownfile_to_data_inspectfile_to_data_transformformat_peppol_invoicegenerate_pdf_invoicekbo_company_searchlookup_peppol_participantmonitor_sourcesparse_receipt_visionreview_invoicetranscribe_and_slice_audioverify_ibanFree no-auth tools for Spain: validate IBAN, EU VAT check (VIES), Modelo 303 sums, Veri*factu dates.
Free EU VAT, IBAN and bol.com commission tools for marketplace sellers
InvoiceOracle - 10 e-invoicing tools: XRechnung, ZUGFeRD, Peppol, validation, archive.
XRechnung and ZUGFeRD e-invoicing (EN 16931): create, validate, check Leitweg-IDs, German VAT.
Add one secure layer between your agents and this server.
