EU business checks: VAT/VIES, IBAN, Peppol, KBO lookup. 16 of 19 tools need no token.
Scored across 19 tools
The core compliance tools are individually well described, but several near-overlapping pairs exist: check_vat_list/check_vat_list_format share local format validation, check_peppol_ready/review_invoice both validate e-invoice compliance, verify_iban/check_payment_change both validate IBANs, and the two KBO tools both key off Belgian VAT numbers. Descriptions clarify scope, but an agent could still select the wrong tool in ambiguous cases.
Most tools follow an imperative verb_noun pattern in snake_case (check_, format_, generate_, review_, verify_), making the naming generally predictable. A few deviations stand out—core_condition, kbo_company_search, and file_to_data_inspect/transform—but they are minor and the overall style is uniform.
19 tools is in the borderline-heavy range for a server named 'EU business checks.' Several general-purpose utilities such as audio transcription, social drafting, web fetching, and workflow branching do not belong to that core scope and inflate the count. Individually reasonable, but as a set it feels broader than one focused server.
For the apparent core domain—EU VAT/KBO validation, IBAN checks, Peppol compliance, and invoice generation—there is good end-to-end coverage. Gaps are minor: no e-invoice sending/emailing tool despite references to one, no non-Belgian company financials, and no explicit approval or archive step.
From a Belgian VAT / KBO number, read a CONNECTED company-financials register and return what it holds: founding year, active status, balance-sheet health, a risk score, solvency and liquidity ratios. It answers only from that register — with none connected, or one that cannot be reached, it returns 503 and charges nothing rather than an estimate. It never derives a credit profile from the number itself, and it is not a credit decision.
| Name | Required | Description | Default |
|---|---|---|---|
| vatNumber | Yes | Belgian VAT or KBO/BCE enterprise number, e.g. BE0403170701 or 0403.170.701. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond those: the 503 failure mode when the register is disconnected, the billing behavior (charges nothing), and the boundary that it never estimates or derives a credit profile. These are exactly the kinds of behavioral disclosures that help an agent. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences of moderate length. It front-loads the core purpose and output list, then adds two behavioral qualifiers. Every sentence carries information: the first states what it does, the second explains the failure mode and billing, the third guards against misuse. No fluff, though it could be tightened without losing meaning.
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 explicitly lists the main returned fields (founding year, active status, balance-sheet health, risk score, solvency/liquidity ratios). It also covers the error case (503) and the billing implication. It does not mention whether additional fields are possible or pagination, but given the tool reads a single register and returns 'what it holds', the enumeration appears comprehensive enough. The annotations further fill the safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is described with examples (BE0403170701 or 0403.170.701). The description goes further by clarifying that the number is used as a lookup key into a connected register, not as input to a derivation algorithm—this is a semantic nuance not present in the schema. It also implies the tool requires a prior connection, which is a functional prerequisite an agent must know.
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 a specific verb ('read'), a precise resource (a CONNECTED company-financials register keyed by Belgian VAT/KBO number), and enumerates the exact outputs (founding year, active status, balance-sheet health, risk score, solvency and liquidity ratios). It explicitly distinguishes itself from a credit decision and from tools that derive profiles from the number alone, which differentiates it from siblings like kbo_company_search and 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?
The description gives clear conditions of use: it works only when a connected register exists, otherwise it returns 503 and charges nothing. It also sets an explicit exclusion ('never derives a credit profile', 'not a credit decision') which guides agents away for credit-decision tasks. It does not name alternative sibling tools for scenarios where no register is connected, so it stops short of full when/when-not guidance; that missing piece keeps it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A supplier says their bank details changed: check the request before the vendor record is touched. Validates the new IBAN (structure and check digits, 70+ countries), compares it with the account on file, and flags an account that moved to another country or sits outside the supplier's country. Returns no_change, verify_first, stop or invalid_new_account, with the call-back steps a person must still take. Offline and free. It never says an account is safe, and never claims who owns it.
| 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. Leave it out for a first registration; the answer then says nothing could be compared. | |
| supplierCountry | No | ISO 3166-1 alpha-2 country where the supplier is established, e.g. BE. When given, an account issued elsewhere is a red flag. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, open-world, and non-destructive. The description adds significant behavioral context beyond that: it is 'Offline and free', it returns specific states (no_change, verify_first, stop, invalid_new_account) plus call-back steps for a human, and crucially, it 'never says an account is safe, and never claims who owns it.' This clarifies limits on what the tool does not guarantee, which is essential for a financial validation tool and goes well beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written. It front-loads the scenario and purpose, follows with a summary of actions and outputs, then adds two short, high-value sentences on cost/availability and limitations. Every sentence contributes; there is no fluff or repetition of schema content. The structure guides the reader from context to behavior to constraints efficiently.
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 tool with three params and no output schema, the description is complete. It explains what the tool does, the exact return values, the call-back steps that remain human tasks, that it is offline/free, and its non-claims about safety and ownership. This is enough for an agent to decide when to call it and to interpret a result. The absence of an output schema is compensated by listing the possible return strings.
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 each parameter with examples (e.g., IBAN format, 'Leave it out for a first registration'). The tool description reiterates the comparison behavior ('compares it with the account on file') and how supplierCountry is used, but it adds no new syntactic or semantic detail beyond the schema. It does clarify the role of each param in the overall logic, but the schema descriptions already cover this. Baseline 3 is 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?
The description opens with a concrete scenario ('A supplier says their bank details changed') and a clear verb-resource pair ('check the request before the vendor record is touched'). It then details specific actions (validate IBAN, compare with account on file, flag country mismatches) and names the four possible return values. This distinguishes it from the sibling verify_iban, which would only validate structure, whereas this tool adds comparison and flagging logic.
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?
It clearly states when to use the tool: when a supplier reports a bank detail change and before any vendor record is modified. It also gives param-level guidance (e.g., 'Leave it out for a first registration') and notes the limitation that it never claims ownership or safety. However, it does not explicitly contrast with alternatives like verify_iban, so the 'when not to use' is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before you send an e-invoice: will the Peppol network accept it? Checks the invoice against 21 published Peppol BIS Billing 3.0 rules — the ones that actually fail in practice: a missing buyer or order reference, a missing electronic address for either party, an address stated under a scheme code that does not exist, totals that do not add up, a date in the wrong format. Every finding names the official rule (PEPPOL-EN16931-R003, BR-CO-15 …), quotes its text and says what to change. Offline and free. It checks a listed subset of a much larger rule set and is not the official validator: a clean result means nothing among these rules is wrong, never that the network will accept the document.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | The invoice lines. | |
| 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). Peppol requires YYYY-MM-DD. | |
| 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). The alternative to a buyer reference. | |
| totalWithoutVat | No | Invoice total excluding VAT (BT-109). Supply it and the arithmetic rules are checked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, but the description adds significant behavioral context beyond that: it is offline and free, it checks a subset of rules, and a clean result is not a guarantee of network acceptance. It also discloses what every finding contains (rule number, quote, suggested change), which is not in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 150 words but every sentence carries value: the front-loaded purpose, the concrete rule examples, the output format, the cost/connectivity note, and the crucial limitation. It is dense without being bloated and earns its length given the tool's 11 parameters and complex domain.
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 11 parameters, nested objects, and no output schema, the description still provides a complete picture: what it checks, what findings look like (rule name, quote, change suggestion), and what a clean result does and does not mean. An agent can correctly decide to call this tool and understand the result without additional documentation.
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 every parameter in detail, including codes like BT-5 and BT-2. The description adds no additional parameter-level semantics; it merely alludes to fields like buyer reference and electronic address that are already fully described in the schema. A baseline 3 is appropriate 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?
The description opens with a clear use-case ('Before you send an e-invoice') and a specific verb ('Checks') against a well-defined resource ('21 published Peppol BIS Billing 3.0 rules'). It lists concrete failure examples and explicitly distances itself from the official validator, making it easy to distinguish from sibling tools like format_peppol_invoice or lookup_peppol_participant without opening their 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?
The description gives explicit timing ('Before you send an e-invoice') and a clear purpose ('will the Peppol network accept it?'). It also provides an important exclusion ('not the official validator') and explains the limitation of a clean result. It does not name specific alternative tools, but the context is strong enough that an agent knows when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a whole LIST of EU VAT numbers against the EU VIES register in one call — up to 20 rows of { reference?, vatId }, answered row for row in the same order. Two tiers. FREE, always: each number is normalised and checked locally — empty, malformed for its member state, a duplicate of an earlier row, or not covered (GB, CH, NO and every non-EU prefix are not_covered, never invalid). METERED: each well-formed, unique row is looked up live in VIES and comes back valid (with the registered name when the member state shares it), invalid, or unknown. PRICE: 1 credits (EUR 0.01) PER ROW THE REGISTER ANSWERED (valid or invalid), charged once after the call. The most a call can cost is that price times its rows (20 credits for a full call), and the balance must cover that before it runs. UNKNOWN COSTS NOTHING: a member state that is down, a rate limit or a row the 40-second time budget did not reach is unknown with the reason — never invalid. To retry, send ONLY the rows listed in retry.indexes; rows that already have an answer do not need to be sent again. The same payload re-sent within ten minutes is charged once. Coverage: the 27 EU member states (Greece as EL or GR); Northern Ireland (XI) numbers are checked for shape only. Optional requesterVatId, your own EU VAT number with its country prefix: each answered row then carries the European Commission's consultation number, registered to you, and a requester VIES refuses costs nothing (those rows come back unknown, never invalid). Read-only; nothing is stored. A valid number today says nothing about tomorrow, and this is not a tax opinion.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | The list: 1 to 20 rows per call. A longer list is refused with the limit named — send it in parts of 20. | |
| requesterVatId | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly/openWorld/idempotent hints, and the description meaningfully elaborates each: 'Read-only; nothing is stored', same-payload-within-10-minutes charging, and the open-world 'unknown, never invalid' semantics. It also discloses the metered pricing model (1 credit per answered row, charged once after the call) and edge behavior (member state down, rate limit, 40-second time budget → `unknown` with reason), which annotations alone cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense unbroken paragraph, which hurts scannability, but it is aggressively front-loaded (core purpose in the first clause) and every sentence carries hard operational information — pricing, retries, coverage, requester behavior. For a tool with this much behavioral complexity the length is justified; structured sections would earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of explaining return semantics, and it succeeds: per-row answer values (`valid` with registered name, `invalid`, `unknown` with reason, `not_covered`) and the `retry.indexes` mechanism are all specified. Coverage boundaries, the 40-second time budget, the pricing model, and the tax-opinion disclaimer are all present — nothing an agent needs to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: the row-for-row response ordering contract, the functional consequence of requesterVatId (EC consultation number per answered row; a refused requester costs nothing), and the coverage taxonomy per vatId prefix (`not_covered` for GB/CH/NO/non-EU). These go beyond the schema's syntax-level documentation.
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 opens with a specific verb+resource: 'Check a whole LIST of EU VAT numbers against the EU VIES register in one call — up to 20 rows of { reference?, vatId }'. It clearly delineates the batch live-register check from mere format-level work by spelling out the two-tier design (local normalization vs live VIES lookup), which prevents confusion with the sibling check_vat_list_format.
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?
Operational guidance is extensive and precise: retry semantics ('send ONLY the rows listed in retry.indexes'), idempotent re-send ('the same payload re-sent within ten minutes is charged once'), the balance pre-requirement, and coverage boundaries (GB/CH/NO are `not_covered`). However, the description never names an alternative or states when not to use this tool — with check_vat_list_format overlapping on format validation, an explicit exclusion would push this to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The FREE half of check_vat_list: normalise and check up to 20 VAT numbers locally — no register, no network, no account, no cost. Says per row whether the number is empty, malformed for its member state (the published VIES shape per country; the Belgian check digit is verified), a duplicate of an earlier row, or not covered by VIES (GB, CH, NO … are not_covered, never invalid). register is always not_run: a well-formed number is NOT a registered one. Use it to clean a list first, then send the well-formed rows to check_vat_list.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | The list: 1 to 20 rows per call. A longer list is refused with the limit named — send it in parts of 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description reveals operational details: no network/register/account/cost, per-row checks for empty/malformed/duplicate/not_covered, and the critical caveat that well-formed does not mean registered. These are behavioral traits an agent must know, and they are not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense yet efficient. It front-loads the core distinction (local vs register), enumerates the per-row outcomes, then gives usage guidance in a final sentence. No wasted words; every clause carries meaning.
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 single-parameter, no-output-schema tool, the description fully covers what an agent needs: input constraints, per-row result semantics, and the relationship to the sibling. The absence of an output schema is mitigated by the description's explicit statement of what it reports for each row.
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 the schema itself already documents vatId format, reference echoing, and row limits in detail. The description adds no new parameter semantics beyond what the schema provides; it focuses on tool behavior instead. Baseline 3 is 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?
The description states a precise action ('normalise and check up to 20 VAT numbers locally') and immediately distinguishes itself from the sibling check_vat_list by calling itself the 'FREE half' and explicitly excluding register checks. It also clarifies edge cases such as 'not_covered' vs 'invalid', leaving no ambiguity about scope.
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?
It gives explicit sequencing guidance: 'Use it to clean a list first, then send the well-formed rows to check_vat_list.' It also implicitly states when not to use it (when register verification is needed) by clarifying that 'register is always not_run'. This is direct, actionable routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Router / IF-ELSE block: compare two values (e.g. invoice amount > 1000) and route the workflow down a True or False branch. Local, free, side-effect-free — the building block for conditional automations.
| Name | Required | Description | Default |
|---|---|---|---|
| left | Yes | Left-hand value — a literal or a value from a previous step. | |
| label | No | Optional human label, e.g. "High-value invoice?". | |
| right | Yes | Right-hand value to compare against. | |
| operator | Yes | How to compare, e.g. ">" for "Invoice amount > 1000". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety. The description adds 'Local, free, side-effect-free' which provides useful behavioral context beyond the annotations, emphasizing it does not have external side effects. It also clarifies it's a router with no side effects on data, adding value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and example, then adds the 'Local, free, side-effect-free' qualifier and its role in workflows. No wasted words; it's efficient and easy to parse.
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 conditional router with no output schema, the description covers all that an agent needs: it explains the purpose, the comparison mechanism, and the routing outcome. The schema details the parameters, and the annotations cover side-effects. No gaps 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 each parameter well. The description adds context by explaining the abstract meaning of left/right as 'values from previous steps' and shows an example of operator usage. However, it does not detail the specifics of each operator (e.g., 'contains' behavior) or how to reference previous step values, but since the schema covers basic semantics, a 4 (above baseline 3) is justified for the added example and conceptual framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a router/IF-ELSE block that compares two values and routes down True or False branches. It names the specific verb 'compare' and the resource (values), and provides a concrete example (invoice amount > 1000), making it easy to distinguish from siblings that perform financial analysis or file processing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: for conditional branching in automations. It does not explicitly state when not to use it or name alternative tools, but the phrase 'building block for conditional automations' implies its role as a control-flow tool, which is distinct from the sibling tools that are all domain-specific actions. Exclusions are lacking, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a topic + research into ready-to-review social post drafts (LinkedIn, X, Instagram, Facebook, or general). Text only — it never posts or sends; publishing stays a separate, approval-gated step.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Voice of the drafts, free-form (e.g. "direct, warm, no buzzwords"). | |
| count | No | How many drafts to produce (default 3, max 5). | |
| facts | No | The ONLY approved product/business claims (from the Brand Profile). | |
| topic | Yes | What the posts should be about, in one or two sentences. | |
| format | No | The post shape to write in (e.g. how-to, story, question). | |
| pillar | No | Today's editorial pillar for these drafts. | |
| context | No | Optional research to ground the drafts (e.g. the Markdown from fetch_web_markdown). | |
| signals | No | Recent signals from the tenant's APPROVED sources, with trust tiers. Posts that use one must cite its ref in their sources array. | |
| campaign | No | Active campaign goal + CTA policy, when one is running. | |
| contract | No | The agent's JOB CONTRACT (purpose/audience/outcome/done). | |
| language | No | Language of the drafts (default en). | |
| platform | No | The platform the drafts should be written for (default general). | |
| learnings | No | Real recorded outcomes (never invented) to improve on. | |
| minAnchors | No | Concrete-detail floor per post (escalates on owner feedback). | |
| recentNote | No | Prompt note listing recent posts the model must not repeat. | |
| ownerUpdate | No | The owner's own news ('we shipped X') — the post's core material when present. | |
| bannedClaims | No | Claims that must never appear — enforced in-prompt AND post-generation. | |
| feedbackNote | No | Real recorded owner behaviour on this agent's recent work. | |
| avoidSignatures | No | Compact signatures of this agent's recent posts — the deterministic anti-repetition gate drops any draft too similar to one of these. | |
| requireFreshBasis | No | Currency-dependent agents: refuse (honestly, before any model spend) when no fresh signals exist to work from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds crucial behavioral context beyond annotations: it explicitly states 'Text only — it never posts or sends; publishing stays a separate, approval-gated step.' This clarifies that the tool has no external side effects, which is valuable for an agent deciding to invoke it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose and then a clarifying note about non-publishing. It is concise, with no fluff or redundant information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 20 parameters, all covered by schema descriptions, and no output schema, the description provides sufficient high-level context. It does not explain return format, but that is not required given the absence of an output schema. The description adequately conveys the tool's role and boundary (drafting, not publishing). Minor gap: it does not mention any prerequisites or constraints like requiring research input, but the schema covers that.
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 every parameter has a description in the schema. The tool description does not add any parameter-specific semantics beyond what the schema already provides. The baseline for high schema coverage is 3, and the description does not exceed that by explaining parameter interactions or additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: turning a topic and research into social post drafts for specific platforms. It explicitly lists the platforms (LinkedIn, X, Instagram, Facebook, general) and distinguishes it from publishing, which is a separate step. It is easily differentiated from sibling tools, which are all finance/invoice related.
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 implies when to use the tool: when you need drafts, not actual publishing, by stating 'publishing stays a separate, approval-gated step.' It does not explicitly name alternatives or exclusions, but the sibling context makes it clear this is the social-content drafting tool. A clear usage condition is present, though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public web page and return its text as clean Markdown for an agent to reason over — no HTML/scripts/styles. Bounded: 5s timeout, byte-capped fetch, truncated output. Read-only; runs without approval.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public https page to read. | |
| maxChars | No | Max Markdown characters to return (default 8000, hard cap 12000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses useful behavioral constraints: 5s timeout, byte-capped fetch, truncated output, and no HTML/scripts/styles. This gives the agent realistic expectations about performance and output scope.
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 tightly packed sentences front-load the purpose and follow with constraints. Every clause adds value, and there is no filler or repetition of schema details.
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 simple read-only fetch tool with complete parameter schemas and safety annotations, the description covers purpose, output form, constraints, and operational context. There is no obvious missing information an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both url and maxChars clearly. The description adds general behavior like truncation but no parameter-specific meaning beyond what the schema provides, matching the baseline for full schema coverage.
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 uses a specific verb and resource: 'Read a public web page and return its text as clean Markdown.' It clearly distinguishes the tool from the unrelated siblings and explains the output format while explicitly excluding HTML/scripts/styles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: for public web pages, for text extraction, and with no approval needed. It implies exclusions like authenticated or non-public pages, though it does not name alternative tools explicitly, which is acceptable given the sibling list contains no direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 1 of turning a business file into data: hand in a supplier price list, a customer import or an order file (CSV or other delimited text, XLSX, JSON, NDJSON; at most 3 MiB, 50,000 rows, 200 columns). Returns the recognised columns and types, a PROPOSED mapping to a built-in target schema (supplier_price_list, customer_import, order_lines) or to your own, each line with a confidence and a reason, the issues found so far, and the limits with how much the file used. The proposal is deterministic arithmetic over headers (EN/NL/FR/DE/ES) and column types — no AI — and nothing is carried out until you send it to file_to_data_transform. Free, no account, nothing is stored; formulas and macros are never executed.
| Name | Required | Description | Default |
|---|---|---|---|
| sheet | No | XLSX only: the sheet's name exactly as written, or its position starting at 0. Default: the first sheet. | |
| content | No | The file's TEXT, for CSV / delimited text / JSON / NDJSON. Give this OR contentBase64. At most 3 MiB. | |
| fileName | No | 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. | |
| headerRow | No | The row number of the header row, counted from 1. Default: the first row that holds anything. | |
| targetSchema | No | Your own target schema: { "id"?, "title"?, "fields": [{ "name", "type", "required"?, "description"?, "synonyms"? }] } with type one of string, identifier, integer, decimal, date, boolean, email. | |
| contentBase64 | No | The file's BYTES, base64-encoded — required for .xlsx, fine for any format. Give this OR content. At most 3 MiB of file. | |
| targetSchemaId | No | A built-in target schema: supplier_price_list, customer_import or order_lines. Give this OR targetSchema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent hints, the description discloses that the proposal is deterministic arithmetic with no AI, that files are not stored, that formulas/macros are never executed, and that no transformation occurs until the next step. This is rich behavioral context and is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a dense single paragraph, but almost every clause earns its place: formats, limits, output, determinism, pipeline step, and privacy. It is longer than strictly necessary but not padded.
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 explains what the tool returns at a sufficient level and covers capacity limits, accepted formats, accepted target schemas, and side-effect behavior. An agent has enough context to select and invoke this tool correctly and to know that file_to_data_transform is the next step.
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?
Since schema coverage is 100%, the per-parameter documentation already carries the detailed meaning. The description adds value by naming supported formats, hard limits (3 MiB, 50,000 rows, 200 columns), and the built-in target schema values, which helps the agent pick valid inputs without duplicating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear first step ('Step 1 of turning a business file into data') and specifies the resource (business files) and the exact outputs: recognized columns/types, proposed schema mapping with confidence and reason, issues, and usage limits. It distinguishes itself from the sibling file_to_data_transform by stating that nothing is carried out until that tool is called.
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?
It gives explicit context for when this tool is appropriate: inspecting a supplier price list, customer import, or order file before transformation, and it names the follow-up tool. It stops short of explicit when-not-to-use or alternative selection guidance beyond the pipeline relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 2: carry out EXACTLY the mapping you send (normally the proposal of file_to_data_inspect, corrected). Returns the rows as JSON, the same as CSV text, an error report per row (JSON and CSV), counts, and fileSha256, mappingSha256 and resultSha256 — the same file and mapping always give the same result, so a lost call is simply repeated and compared. It never corrects silently: leading zeros and long ids stay as written, a number is read only under the mapping's decimal mark, an ambiguous date stays unconverted with an issue, a missing value stays null. Large results are paged (offset / limit / page.nextOffset). Free, no account, nothing is stored; over a limit is a refusal that names the limit, never a partial result.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 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. | |
| sheet | No | XLSX only: the sheet's name exactly as written, or its position starting at 0. Default: the first sheet. | |
| offset | No | First row of the page, starting at 0. Use page.nextOffset of the previous answer. | |
| content | No | The file's TEXT, for CSV / delimited text / JSON / NDJSON. Give this OR contentBase64. At most 3 MiB. | |
| mapping | Yes | THE EXPLICIT MAPPING to carry out — normally `proposedMapping` from file_to_data_inspect, corrected where needed: { "targetSchemaId" | "targetSchema", "fields": [{ "target", "source", "sourceIndex"?, "decimalMark"?: "." | ",", "dateFormat"?: "YMD" | "DMY" | "MDY" | "excel_serial" }] }. A number is read ONLY under decimalMark, a date ONLY under dateFormat. | |
| fileName | No | 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. | |
| headerRow | No | The row number of the header row, counted from 1. Default: the first row that holds anything. | |
| targetSchema | No | Your own target schema: { "id"?, "title"?, "fields": [{ "name", "type", "required"?, "description"?, "synonyms"? }] } with type one of string, identifier, integer, decimal, date, boolean, email. | |
| contentBase64 | No | The file's BYTES, base64-encoded — required for .xlsx, fine for any format. Give this OR content. At most 3 MiB of file. | |
| targetSchemaId | No | A built-in target schema: supplier_price_list, customer_import or order_lines. Give this OR targetSchema. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations for readOnly, openWorld, idempotent, and destructive already present, the description still adds substantial behavioral detail: exact non-silent-correction rules, deterministic result hashes, paging via page.nextOffset, privacy guarantees, and refusal behavior over limits. This far exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it front-loads the core purpose, then covers outputs, determinism, data-handling rules, pagination, and limits/refusal behavior. Every clause carries operational value, and nothing feels redundant with 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 complex 10-parameter tool with no output schema, the description is remarkably complete. It explains what is returned, how errors are reported, how pagination works, how results are reproducible via hashes, what happens on limits, and that no data is stored. An agent has enough context to call and interpret the result 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%, so the baseline is 3. The description reinforces mapping semantics ('never corrects silently', 'leading zeros stay as written') and mentions paging behavior tied to offset/limit, but it does not materially add parameter-level meaning beyond the schema's already-detailed property descriptions.
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 a specific verb and resource: 'carry out EXACTLY the mapping you send' and explicitly positions itself as 'Step 2' after file_to_data_inspect. It also enumerates the exact outputs (rows as JSON/CSV, per-row error report, counts, hashes), so an agent can distinguish it from sibling tools 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?
The description gives an explicit workflow: use this after file_to_data_inspect, normally with its corrected proposal. It also states when results are paged and when a request is refused, giving clear operational context and enough distinction from file_to_data_inspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a compliant UBL 2.1 / Peppol BIS Billing 3.0 e-invoice XML from structured invoice fields (supplier, customer, line items, VAT).
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Free-text invoice note. | |
| lines | Yes | Invoice lines. Totals are computed from these. | |
| dueDate | No | Optional payment due date (YYYY-MM-DD). | |
| currency | No | ISO 4217 currency code (uppercase). Defaults to EUR. | EUR |
| customer | Yes | Buyer / accounting customer party. | |
| supplier | Yes | Seller / accounting supplier party. | |
| issueDate | Yes | Issue date (YYYY-MM-DD). | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is lower. It adds useful context about the output standard and input source, but does not describe behaviors like strict validation, error handling, or how the XML is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the key compliance standards upfront and lists the essential input categories economically.
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 names the exact output artifact and standard, and the schema handles parameter documentation thoroughly. The only notable gap is that it does not specify whether the XML is returned inline, as a file, or how validation failures are surfaced, but for a pure generation tool this is a minor omission.
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 every parameter is already documented in the schema. The description merely lists the same categories (supplier, customer, line items, VAT) without adding new parameter-level meaning, which aligns with the baseline score of 3.
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 a specific verb ('Generate'), a precise resource ('UBL 2.1 / Peppol BIS Billing 3.0 e-invoice XML'), and the source fields. This clearly distinguishes it from related siblings like generate_pdf_invoice, review_invoice, or check_peppol_ready.
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 intended use is implied by the task-specific wording: an agent would use this when it needs a compliant Peppol e-invoice XML from structured fields. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as generate_pdf_invoice or review_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a polished, human-readable PDF invoice from structured invoice data (supplier, customer, line items, totals) and return it as a base64-encoded document. Local rendering; pairs with send_email_resend to email the PDF as invoice.pdf.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | One or more invoice line items. | |
| notes | No | Optional footer notes / payment terms. | |
| dueDate | No | Optional due date (ISO 8601). | |
| currency | No | ISO 4217 currency code (uppercase). Defaults to EUR. | EUR |
| customer | Yes | The company being BILLED. | |
| supplier | Yes | The company ISSUING the invoice (you / your business). | |
| issueDate | Yes | Issue date (ISO 8601), e.g. 2026-06-06. | |
| invoiceNumber | Yes | Invoice number, e.g. "INV-2026-0001". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: 'Local rendering' (no external calls) and the return format as base64. It does not contradict the annotations and provides additional operational detail beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The main action is front-loaded, and the extra detail (local rendering, pairing with send_email_resend) is concise and relevant. 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?
There is no output schema, but the description clearly states the return type (base64-encoded PDF). It also covers the local rendering aspect and suggests a companion tool. While it doesn't discuss error handling or edge cases, the annotations and schema cover validation and safety, making it sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a clear description. The tool description adds no extra meaning beyond the schema, only restating that it uses supplier, customer, line items, and totals. The baseline of 3 is appropriate given the schema fully documents parameters.
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 a specific verb ('Generate'), a concrete resource ('polished, human-readable PDF invoice'), and the input ('structured invoice data') and output ('base64-encoded document'). It clearly differentiates from the sibling format_peppol_invoice by emphasizing human-readable PDF, and the local rendering note adds specificity.
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 guidance on when to use this tool versus alternatives. It mentions pairing with send_email_resend, but that is not a sibling tool and does not clarify selection criteria. No exclusions or conditions are provided for choosing this over format_peppol_invoice or other invoice-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an official European company by VAT or enterprise number via the free EU VIES register — any EU member state, including the Belgian KBO/BCE. Returns its registered name, VAT id, address, and status. Read-only; pairs with format_peppol_invoice to resolve a buyer.
| 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. Defaults to BE; inferred from the VAT prefix when present. | BE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the bar is lower. The description adds useful context beyond those: the data source is the free EU VIES register, scope includes any EU member state and Belgian KBO/BCE, and the returned fields are name, VAT id, address, and status. It does not discuss failure modes or rate limits, but the added context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the action, resource, and source; the second covers return values, read-only status, and workflow pairing. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter, read-only lookup with no output schema, and the description is complete for invocation: it states the source, scope, returned fields, and a concrete use case. It also compensates for the missing output schema by naming exactly what the caller gets back.
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%: both vatNumber and countryCode already have detailed descriptions, including examples and default behavior. The prose mostly restates 'VAT or enterprise number' without adding new parameter semantics, so the baseline score of 3 is 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?
The description names a specific verb and resource: 'Look up an official European company by VAT or enterprise number' via the EU VIES register, and it lists the returned fields. It is clear, but it does not explicitly differentiate itself from nearby siblings like lookup_peppol_participant or analyze_kbo_financials; it only mentions a pairing with format_peppol_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete workflow signal, 'pairs with format_peppol_invoice to resolve a buyer,' and notes it is read-only, which helps an agent decide when to call it. It does not explicitly state when not to use it or name alternative tools, 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.
Can this customer receive an e-invoice over Peppol today — and if the send still fails, is it his problem, yours, or your software's? Asks the live Peppol registers about a THIRD PARTY: the public directory, the lookup the network uses today, and the lookup Peppol retired. Returns whether he is reachable, which document types his access point accepts, and — the part nobody else answers — who to call when it still does not work. A customer found by the current lookup but not by the retired one is reachable, and software reporting him as absent is asking the question Peppol retired: a message for the software vendor, not for the customer. Free, read-only, nothing stored. Do not confuse it with check_peppol_ready, which checks YOUR OWN invoice against the rules offline. It is never a promise that an invoice will arrive, be accepted or be paid — every answer says so.
| 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. Left out, a Belgian enterprise number is assumed. | |
| identifier | Yes | The customer's enterprise or VAT number, as written on the invoice — "BE 0403.170.701", "0403170701" and "BE0403170701" are all accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds substantial behavioral context: it queries multiple live Peppol registers (including a retired one), explains interpretation of results, notes it is free and stores nothing, and states that every answer includes a disclaimer. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured: it opens with the core question, explains the operational scope, differentiates from a sibling, and ends with a disclaimer. While verbose, each sentence carries value and the key information is front-loaded. It could be trimmed slightly without losing content, but it is not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent tool with no output schema, the description covers all essential aspects: what it checks, the source of data, how to interpret different results, and what not to expect. The annotations supply the safety profile, and the description explains the nuanced distinction between current and retired lookups, making it fully actionable for an agent.
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 input schema provides 100% coverage of both parameters with detailed descriptions (scheme options, default, identifier format examples). The description does not add extra meaning about the parameters themselves; it focuses on the tool's purpose and interpretation. Given the schema coverage, a baseline of 3 is appropriate; the description adds context to the overall use case but not to parameter semantics specifically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (lookup/asks) and resource (Peppol participant registers), and explicitly differentiates from sibling check_peppol_ready. It also details what is returned (reachability, document types, escalation contact), leaving no ambiguity about the tool's function.
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 provides explicit guidance on when to use the tool (to check if a customer can receive an e-invoice via Peppol) and contrasts it with check_peppol_ready, which checks the user's own invoice offline. It also clarifies that the tool is not a promise of delivery, acceptance, or payment, setting correct expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch the tenant's APPROVED sources (own changelog, notes, RSS feeds, GitHub releases, approved pages) for real changes and store grounded signal records for drafting. Reads only registered https sources (SSRF-guarded); writes only this tenant's Memory Vault. Never posts.
| Name | Required | Description | Default |
|---|---|---|---|
| maxSources | No | How many due sources to check this run (default 5, max 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says it 'writes only this tenant's Memory Vault,' which directly contradicts the annotation readOnlyHint=true. This is a serious side-effect inconsistency, so the behavioral transparency score must be 1 despite the otherwise useful SSRF and scope details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the purpose, then packs security behavior, write scope, and a clear exclusion into the second sentence.
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 source types, SSRF guard, write target, and non-posting behavior, which is strong for a simple one-parameter tool. However, the readOnlyHint contradiction undermines the overall picture, and no return behavior is described even though there is no output 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 100% for the single optional maxSources parameter, so the description doesn't need to repeat it. The description adds no extra parameter-level meaning, 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?
The description opens with the specific verb 'Watch' and names exact approved sources (changelog, notes, RSS, GitHub releases, approved pages), making the tool's resource and action unmistakable. It also distinguishes itself from publishing tools with 'Never posts.'
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?
It provides clear context: use this to monitor approved sources and store grounded signals for drafting. It also gives exclusions via 'reads only registered https sources' and 'Never posts,' though it does not explicitly name sibling tools or spell out when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-modal receipt/invoice parser: from a photo (URL or base64), use a vision LLM to extract merchant, total, VAT, date, currency and line items as clean JSON. Bounded: 5MB image cap, 5s download timeout. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| imageUrl | No | Public https URL of the receipt/invoice image. One source required. | |
| imageBase64 | No | Base64 image payload (with or without a data: prefix). One source required. | |
| currencyHint | No | Optional ISO-4217 hint (e.g. "EUR") when the receipt is ambiguous. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful constraints: a 5MB image cap and 5s download timeout, plus the fact it uses a vision LLM. It redundantly states 'Read-only' but the added limits provide value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded, constraints are appended, and every word contributes to understanding the tool. It is appropriately concise without sacrificing critical details.
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 tool is fairly simple: takes an image and returns JSON. The description lists the extracted fields, so an agent knows what to expect. It includes size and timeout limits. It lacks explicit error-handling behavior, but given the annotations and the tool's read-only nature, it is largely 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 the schema already documents all three parameters. The description does not add new meaning beyond what the schema states, such as the requirement for one source or the optional nature of currencyHint. The baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses receipts/invoices from images, specifies the input types (URL or base64), lists the extracted fields (merchant, total, VAT, date, currency, line items), and notes it uses a vision LLM. This distinguishes it from sibling tools like file_to_data_inspect or transcribe_and_slice_audio.
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 implies the tool is for receipt/invoice images but does not explicitly state when to use it versus alternatives, nor when not to use it. It gives input constraints but no exclusion criteria or mention of other tools that might be more appropriate for different document types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review one structured invoice end to end and say whether it can be sent as an e-invoice. Checks the Peppol field contract, recomputes every line total and the document total, verifies the supplier and customer VAT numbers against the free EU VIES register, and builds the UBL 2.1 / Peppol BIS Billing 3.0 document. Returns findings with a concrete fix for each, plus a draft e-mail and the XML export. Reads structured invoice data only — no OCR, so PDFs and scans are refused rather than guessed at. Read-only: it never sends, files, pays or signs, and a VAT check that cannot reach the register is reported as unknown, never as a pass or a failure.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Free-text invoice note. | |
| lines | Yes | Invoice lines. Totals are computed from these. | |
| dueDate | No | Optional payment due date (YYYY-MM-DD). | |
| currency | No | ISO 4217 currency code (uppercase). Defaults to EUR. | EUR |
| customer | Yes | Buyer / accounting customer party. | |
| supplier | Yes | Seller / accounting supplier party. | |
| issueDate | Yes | Issue date (YYYY-MM-DD). | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, and the description adds high-value behavior beyond those flags: VIES unreachability is reported as `unknown`, PDFs/scans are refused rather than interpreted, and the tool returns findings with fixes plus draft e-mail and XML export. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, followed by checks, outputs, then constraints. Each sentence carries distinct information and none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 9-parameter tool with nested objects and no output schema, the description covers inputs, processing, outputs, constraints, and edge-case behavior. An agent has enough context to call it correctly and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds meaning by explaining how line items (totals recomputed) and supplier/customer vatId values (checked against VIES) are used and validated. It does not explain every parameter, but the schema already does that.
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 a precise action and object: 'Review one structured invoice end to end and say whether it can be sent as an e-invoice.' It enumerates specific checks (Peppol field contract, line/document totals, VIES VAT verification, UBL 2.1/Peppol BIS Billing 3.0 build), which separates it from siblings like format_peppol_invoice or check_peppol_ready.
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?
It gives clear when-not guidance: structured invoice data only, no OCR, so PDFs and scans are refused; and read-only, so it never sends or signs. It stops short of naming sibling tools to route to alternative workflows, so it lacks fully explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Voice-to-action: download or accept an audio recording, split it into frame-aligned MP3 chunks, and transcribe it to text via an AI speech endpoint — so a user can dictate a task instead of typing. Bounded: 5s download timeout, 25MB cap, chunk-capped. Read-only; runs without approval.
| Name | Required | Description | Default |
|---|---|---|---|
| audioUrl | No | Public https URL of the audio file (mp3/m4a/wav). One source required. | |
| language | No | Optional ISO-639-1 hint (e.g. "nl", "en", "fr"). | |
| audioBase64 | No | Base64 audio payload (with or without a data: prefix). One source required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds concrete bounds: 5s download timeout, 25MB cap, chunk-capped, and the note that it runs without approval. This provides risk-related context beyond the annotations. It does not contradict any annotation and adds useful operational 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?
The description is a single sentence but well-structured, front-loading the core purpose and then adding bounds. It avoids fluff and every clause earns its place. It's concise yet informative. It could arguably be split into two sentences for readability, but it remains clear and efficient.
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 tool that downloads, slices, and transcribes, the description covers the main behavior and constraints. It mentions the output is text, so that's clear. It doesn't describe the exact output format (e.g., whether it returns a transcript file or plain text), but given the absence of an output schema and the simplicity of the tool, this is sufficiently complete. The absence of explicit failure handling (e.g., what happens on timeout) is a minor gap, but the bounds are 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 coverage is 100% – all three parameters are described in the schema. The description adds the clarification that exactly one source (audioUrl or audioBase64) is required, which is not enforced by the schema (required: 0). This helps resolve ambiguity. However, it doesn't add any new details about language parameter or behavior beyond what the schema says. Relative to the baseline of 3, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: download or accept audio, slice into MP3 chunks, and transcribe via AI. It uses a specific verb sequence and resource (audio), and it notably distinguishes itself from the sibling tools, none of which perform transcription or audio processing. The description is concrete and action-oriented.
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 provides clear usage context by framing it as 'voice-to-action' and for users who want to dictate a task. It doesn't explicitly mention alternative tools, but given the sibling list, none are natural alternatives, so exclusions aren't necessary. However, it lacks explicit guidance on when not to use this tool (e.g., if the audio is too large, but it does mention the 25MB cap, which is implicit). Overall, the context is clear but could benefit from a direct statement of when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a payment account number (IBAN) before paying or before sending an invoice: ISO 13616 structure and ISO 7064 check digits, for 70+ countries, offline and free. Catches the single mistyped character a format check cannot. Optionally reports whether the account is issued in the country of the party being paid — as an observation, not a fraud verdict. It never claims the account exists or who owns it.
| 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. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world behavior, but the description adds substantial operational context: it is offline and free, catches single mistyped characters that format checks miss, and reports country-of-issuance as an observation rather than a fraud verdict. These caveats meaningfully shape agent expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the use case and scope, the core verification capability, and the critical limitations. The most decision-relevant information is front-loaded, and there is no fluff or repetition of schema details.
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 simple two-parameter verification tool with rich annotations, the description covers inputs, scope, behavior, limitations, and optional country logic. Even without an output schema, an agent has enough context to invoke it correctly and interpret the result's intended meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that expectedCountry controls whether the response reports country-of-issuance and clarifying that this is an observation, not a fraud verdict. The iban parameter is already well documented in the schema, so the description's contribution is helpful but not essential.
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 a specific verb and resource: 'Check a payment account number (IBAN)' before paying or sending an invoice. It names the exact standards verified (ISO 13616 structure, ISO 7064 check digits) and covers 70+ countries, which cleanly distinguishes it from sibling tools like check_vat_list even without naming them.
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?
It explicitly says when to use the tool ('before paying or before sending an invoice') and what it does not do ('It never claims the account exists or who owns it'). This gives an agent clear selection and exclusion criteria, even though it does not name sibling tools.
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.
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_iban11.3M entities, 10 countries, 12 tools. EU VAT (VIES), BORME, GLEIF, KYB. Free: 100 req/month.
Read-only EU e-invoice checks: VAT format, VIES, Peppol lookup. Returns evidence, no filing.
Commerce validators: live EU VAT (VIES), EORI, email/MX lookups; IBAN/ABA/GTIN checksums; VAT rates.
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
Add one secure layer between your agents and this server.
