Israeli invoice PAY/HOLD/BLOCK gate; cheapest paid path company-changes $0.01 USDC.
Scored across 13 tools
Several tools serve overlapping purposes with only paid/free distinctions, e.g., preview_company and preview_israeli_company_free both offer free company previews, and verify_company and verify_israeli_company_paid both provide paid verification. The similar names and descriptions make it difficult for an agent to reliably pick the intended tool without deep inspection.
Tool names are inconsistent: some include 'israeli', some don't; some have '_paid' or '_free' suffixes, others use 'preview_' prefixes. Verbs are mixed (assess, authorize, describe, get, preview, verify) with no uniform pattern, making it hard to predict naming conventions.
13 tools is within the typical range for a domain-specific server, but the count is inflated by redundant preview/paid pairs. Each tool has a defined role, so the overall count is acceptable though slightly heavier than necessary.
The server covers core workflows: free previews, paid verification, vendor payment risk, invoice payment authorization, and company change monitoring. It explicitly excludes full KYB and tax authority integration, which are acknowledged limitations. Minor gaps exist (e.g., no direct list/search tool), but the surface is fairly complete for its stated purpose.
RECOMMENDED immediately before an agent pays an Israeli supplier. Resolves the legal entity, compares invoice identity and contact domains, evaluates buyer-observed payment-change and urgency signals, then returns an evidence-backed PROCEED, REVIEW, or BLOCK decision with deterministic reason codes. Costs $0.10 USDC on Base Mainnet. It does not verify bank-account ownership, invoice authenticity, sanctions, PEPs, UBOs, adverse media, or creditworthiness. Use preview_israeli_vendor_payment_risk_free first.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en | |
| company_name | No | Israeli legal or trading name claimed by the buyer or invoice. | |
| invoice_city | No | Supplier city printed on the invoice or payment request. | |
| vendor_email | No | Supplier contact email used for the payment request. | |
| company_number | No | Israeli company number claimed by the buyer or invoice. | |
| invoice_amount | No | Optional invoice amount used as audit context, not as a credit signal. | |
| invoice_website | No | Supplier website presented in the transaction context. | |
| invoice_currency | No | Optional invoice currency. | |
| first_time_vendor | No | Whether this is the buyer's first transaction with the vendor. | |
| invoice_company_name | No | Supplier name printed on the invoice or payment request. | |
| invoice_company_number | No | Company number printed on the invoice or payment request. | |
| urgent_payment_request | No | Buyer-observed signal that unusual urgency was used to request payment. | |
| payment_details_changed | No | Buyer-observed signal that payment instructions recently changed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, and the description adds important non-obvious context: it costs $0.10 USDC, it does not verify bank-account ownership or sanctions, and it returns deterministic reason codes. This meaningfully exceeds what the annotations alone 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?
The description is compact and front-loaded with the most important guidance: when to use it. Every sentence adds distinct value—timing, process, output, cost, limitations, and the free-preview alternative—with no redundant 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 paid, decision-returning API with no output schema, the description provides the essential invocation context: cost, when to use, what it returns, what it cannot do, and which sibling to try first. The extensive input schema covers parameter details, so nothing critical 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 92%, so the schema already documents the parameters well. The description contributes only high-level grouping, such as 'invoice identity and contact domains' and 'payment-change and urgency signals,' which adds context but does not materially improve per-parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it assesses an Israeli vendor before payment and returns a PROCEED, REVIEW, or BLOCK decision. It clearly separates itself from the free preview sibling by stating 'Use preview_israeli_vendor_payment_risk_free first,' so an agent can select the correct tool without opening 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 states exactly when to use the tool: immediately before paying an Israeli supplier. It also names the free preview as the prerequisite alternative and lists capability exclusions, telling agents when this tool is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRE-PAYMENT GATE for an Israeli tax invoice and accounts-payable agent. Checks VAT and total arithmetic; date, amount, VAT component, authorized-dealer buyer and buyer-request conditions for an Israel Invoices allocation number; supplier public-registry identity; and vendor-risk signals. Returns PAY, HOLD, or BLOCK with deterministic reason codes and fails safely when buyer context is missing. Costs $0.25 USDC on Base Mainnet. This service does not call the Tax Authority; buyer-authorized TA access is required for official allocation verification; buyer-attested results are labeled and not independently authenticated. Use preview_israeli_invoice_payment_gate_free first.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | ILS | |
| language | No | en | |
| vat_amount | Yes | ||
| invoice_city | No | ||
| invoice_date | Yes | ||
| total_amount | Yes | ||
| vendor_email | No | ||
| supplier_name | No | ||
| invoice_number | Yes | ||
| invoice_website | No | ||
| buyer_vat_number | No | ||
| allocation_number | No | ||
| amount_before_vat | Yes | ||
| expected_vat_rate | No | ||
| first_time_vendor | No | ||
| official_verification | No | Optional result obtained by the buyer through the Israel Tax Authority authenticated service. It is treated as buyer-attested, not independently authenticated by this API. | |
| urgent_payment_request | No | ||
| payment_details_changed | No | ||
| supplier_company_number | Yes | Nine-digit Israeli supplier company or VAT number. | |
| buyer_is_authorized_dealer | No | Buyer-attested answer: whether the invoice recipient is an Israeli authorized dealer (osek murshe). Required for a definitive allocation-number applicability result above the threshold. | |
| buyer_requested_allocation_number | No | Buyer-attested answer: whether the buyer requested an allocation number for this invoice. Required for a definitive applicability result above the threshold. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds substantial behavioral context: it does not call the Tax Authority, requires buyer-authorized TA access for official verification, labels buyer-attested results as not independently authenticated, fails safely when buyer context is missing, costs $0.25 USDC, and returns deterministic reason codes. 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?
Four compact sentences with high signal-to-noise. The core purpose is front-loaded, followed by return behavior, cost, important caveats about external verification, and the recommended preview step. No filler or redundant restatement of the tool name.
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 21-parameter schema, nested object, paid nature, and no output schema, the description covers the most important operational context: cost, return decision values, failure mode, external dependency limitations, and buyer-attestation semantics. The main gap is that it could more explicitly describe the expected structure of the PAY/HOLD/BLOCK result for an agent parsing it downstream.
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 only 19%, so the description must compensate. It does group parameters into meaningful categories: VAT and total arithmetic, date/amount/VAT component, allocation-number conditions, supplier registry identity, and vendor-risk signals. However, it does not explain many optional fields or the nested official_verification object's role in enough detail, so parameter semantics remain only partially clarified.
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: a PRE-PAYMENT GATE for an Israeli tax invoice that returns PAY, HOLD, or BLOCK. It distinguishes itself from siblings by describing the invoice-payment decision scope and explicitly routing to preview_israeli_invoice_payment_gate_free for the free first pass.
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 clearly says 'Use preview_israeli_invoice_payment_gate_free first,' which conveys the expected paid-vs-free workflow. It does not explicitly list exclusions or when to choose assess_israeli_vendor_payment_risk_paid instead, but the gate purpose is specific enough that the main alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: inspect Israel company-verification capabilities, exact paid/free boundaries, public-registry evidence scope, pricing, and limitations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 adds helpful context by clarifying this is a free informational inspection with no parameters. It does not contradict annotations and adds the practical behavioral trait of being free with zero input requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence front-loads the most important signal ('Free:') and then enumerates the exact topics covered. Every phrase adds information, and there is no redundant or filler content.
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 that the tool takes no parameters and has a simple informational purpose, the description fully covers what the agent needs to know before calling it. It names the specific categories of information the tool provides, making the return expectations clear even without an 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?
The tool has zero parameters, so the baseline is 4. The description meaningfully explains what the agent will learn without needing schema details, compensating for the absence of 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 uses a specific verb ('inspect') and a clear resource (Israel company-verification capabilities, paid/free boundaries, evidence scope, pricing, limitations). It clearly distinguishes itself from the paid and preview sibling tools by signaling this is a free informational entry point.
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 opening 'Free:' and the focus on exact paid/free boundaries and pricing give clear context that this tool should be used to understand service limits and costs before using paid alternatives. It does not explicitly name sibling alternatives or state 'use when...', but the intended use case is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LOW-COST REPEATABLE MONITORING LOOKUP for an exact Israeli company number. Returns recent official filing and status-change events, newest first, with source URLs and deterministic categories. Costs $0.01 USDC on Base Mainnet. Coverage is approximately one year and an empty result is not proof that no earlier change occurred.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of most-recent events to return. | |
| language | No | en | |
| lookback_days | No | Return events recorded during this many recent days. | |
| company_number | No | Exact nine-digit Israeli company registration number. Defaults to the public sample 514744887 when omitted (marketplace canary / empty paid body). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description correctly aligns. It adds valuable behavioral context beyond annotations: the $0.01 cost, approximately one-year coverage, and the caveat that an empty result does not prove no earlier change occurred. This enriches the agent's understanding of side effects and limitations.
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 focused sentence that front-loads the core purpose and key constraints (cost, coverage, empty-result caveat) without redundancy. Every clause contributes to the agent's decision to call the tool.
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 no required parameters and no output schema, the description covers the essential usage context: what it returns, cost, coverage, and a crucial interpretation caveat. It omits details like pagination handling or the meaning of 'deterministic categories', but these are minor given the tool's simplicity and the annotations covering safety.
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 75% (three of four parameters have descriptions), so the schema already documents most parameter semantics. The description reinforces that company_number must be exact and nine-digit, but does not add new meaning beyond what the schema provides. 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 specific verb ('returns') and resource ('recent official filing and status-change events') for an exact Israeli company number, with clear output ordering and content. It distinguishes itself from siblings by emphasizing 'paid' and 'monitoring', which is distinct from the free preview and verification tools.
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 a monitoring use case and notes it is low-cost and repeatable, but it does not explicitly name alternatives or state when to use this tool versus the free previews or verification tools. It gives context (cost, exact number) but lacks direct 'use when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE STATIC SAMPLE: inspect a representative complete verification report with resolved company fields, field-level evidence, source URLs, confidence, missing-data disclosure, and checked_at. This does not perform a live lookup and never charges a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context beyond those: it is static, free, representative, non-live, and never charges a wallet. There is no contradiction between the description and 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 only two sentences, with the key differentiator 'FREE STATIC SAMPLE' front-loaded. It packs relevant content details (fields, evidence, source URLs, confidence, missing-data disclosure, checked_at) without unnecessary fluff.
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 zero-parameter, read-only sample tool, the description fully covers what the agent can expect: the report's contents, the fact that it is not a live lookup, and the absence of charges. An output schema is absent, but the description compensates by enumerating the report components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to clarify beyond confirming no inputs are needed. This matches the baseline for a parameterless tool, and the description's 'FREE STATIC SAMPLE' framing reinforces the no-configuration nature.
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 ('inspect') and a clearly defined resource ('a representative complete verification report'), explicitly listing the types of content included. It also distinguishes itself from live lookups, which sets it apart from sibling paid verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'FREE STATIC SAMPLE' and the explicit statement 'This does not perform a live lookup' clearly imply the tool is for previewing/inspecting a sample report rather than obtaining live verification. It provides clear usage context, though it does not explicitly name a sibling alternative for live lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: get distinct machine-readable schemas for the limited preview_company tool and paid verify_company evidence result.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that the call is free and returns machine-readable schema definitions, but it does not describe the response shape or how the included schemas are organized. 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?
A single sentence contains the pricing signal, target tools, and output type with no filler. The wording is slightly awkward ('distinct... schemas'), but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input, read-only metadata tool, the description is nearly complete: it identifies the free schemas for the two relevant tools. Because there is no output schema, a slightly clearer statement of what is returned (one schema per tool) would fully close the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter burden for the description to carry; the baseline of 4 applies. The description does not introduce any parameter-related ambiguity.
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 action ('get') and resource ('machine-readable schemas') for preview_company and verify_company, so an agent can tell this is a schema-metadata tool. Some ambiguity remains around 'distinct' and 'evidence result,' and the title mentions only verify_company while the description covers both tools.
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 context for use: this is the free way to obtain schemas for the limited preview_company tool and paid verify_company evidence result. It does not explicitly state when not to use it or name an alternative, but for a zero-parameter schema tool the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE AGENT PAYMENT FIREWALL: before an AI agent signs an x402 payment, bind the Israeli company identity, service origin, signed domain payee manifest, destination wallet, payment fingerprint, and buyer mandate into an ALLOW, REVIEW, or DENY decision. This dry-run never signs or submits a payment and does not claim legal wallet ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| mandate | No | ||
| payment | Yes | ||
| language | No | en | |
| manifest | No | ||
| service_url | Yes | ||
| company_name | No | ||
| manifest_mode | No | fetch | |
| company_number | No | ||
| previous_payment_fingerprint | No |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| checks | Yes | |
| entity | Yes | |
| decision | Yes | |
| manifest | Yes | |
| checked_at | Yes | |
| limitations | Yes | |
| next_action | Yes | |
| assessment_version | Yes | |
| payment_fingerprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral clarity by emphasizing this is a dry-run that never signs or submits a payment and does not claim legal wallet ownership. This goes beyond annotations and clarifies a critical distinction for an agent considering payment actions.
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 informative sentence, front-loaded with the key purpose ('FREE AGENT PAYMENT FIREWALL') and a clear before-signing gate. It includes a defensive clarity sentence about not signing/submitting. It is compact and each sentence earns its place, though the all-caps acronym could be seen as stylistic noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description captures the essential behavioral promise: free dry-run, decision verdict, and no signing/submission. The complexity of the nested inputs is high, but the schema itself is rich. The description doesn't mention return value shape or result handling, but the output schema likely covers that; a brief mention of ALLOW/REVIEW/DENY actually covers the output concept.
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 0%, so the description could compensate, but it does not explain any parameters individually. It does enumerate the conceptual input categories (Israeli company identity, service origin, signed domain payee manifest, destination wallet, payment fingerprint, buyer mandate) which loosely map to schema properties. However, with 9 parameters and nested object structures, the agent must rely entirely on the schema for actual parameter 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 performs a dry-run preview of an x402 payment trust decision, binding multiple inputs into an ALLOW/REVIEW/DENY verdict. It distinguishes itself from signing/submitting via the 'never signs or submits' clause. However, it does not explicitly differentiate itself from the several similarly-named preview siblings.
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 conveys when to use this tool: before signing an x402 payment, to get a free firewall/decision. It also states what it does NOT do (never signs or submits), providing an implicit exclusion from signing tools. It doesn't explicitly name alternatives like preview_israeli_invoice_payment_gate_free or when not to use it, but the x402-specific scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE LIMITED PREVIEW for an Israeli company legal name or company number. Returns only identity, registry status, match candidates, confidence, and an exact next action. It never returns field-level evidence, source URLs, address, incorporation, annual-report, or law-violation fields. Use the paid verify_company tool for the complete evidence-backed public-registry result.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Israeli city used to disambiguate companies with similar names. | |
| website | No | Optional public company website used only as supporting resolution context. | |
| language | No | Language for the human-readable summary: en or he. Defaults to en. | en |
| company_name | No | Israeli legal or trading name. Provide this or company_number; add city when the name may be ambiguous. | |
| company_number | No | Israeli company registration number. A nine-digit number gives the most reliable exact match. | |
| expected_entity_type | No | Optional expected legal entity type, such as private company, used for disambiguation. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| company | Yes | |
| candidates | Yes | |
| checked_at | Yes | |
| confidence | Yes | |
| request_id | Yes | Unique preview request identifier. |
| next_action | Yes | |
| paid_actions | Yes | |
| preview_version | Yes | Preview contract version. |
| full_verification | Yes | |
| resolution_status | Yes | |
| preview_limitations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds substantial transparency beyond that by clearly listing excluded fields (evidence, source URLs, address, incorporation, annual-report, law-violation) and stating that verification depth is not accepted.
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 with no wasted words. The free/limited nature is front-loaded, the return scope is precise, and the pointer to the paid alternative is placed last. Every sentence contributes 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 read-only, idempotent lookup with an output schema and 100% schema-described parameters, the description fully covers purpose, exclusions, and routing. Nothing essential is missing for an agent to decide whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a clear description. The tool description does not add parameter-level meaning beyond the schema, which is acceptable given full schema coverage. It does reinforce that company_name or company_number is needed, but the schema already conveys this.
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 ('preview'), a resource ('Israeli company identity'), and a clear scope ('free and limited'). It explicitly enumerates what is returned and what is never returned, and distinguishes itself from the paid verify_company tool by contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus the paid alternative: use preview_company for a free limited identity preview, and use verify_company when a complete evidence-backed public-registry result is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RECOMMENDED FREE FIRST STEP for Israel company verification, Israeli supplier checks, counterparty due diligence, or public-registry KYB evidence. Resolves legal identity and registry status without payment, then returns exact reusable arguments for the paid full report. No field-level evidence or source URLs are included.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Israeli city used to disambiguate companies with similar names. | |
| website | No | Optional public company website used only as supporting resolution context. | |
| language | No | Language for the human-readable summary: en or he. Defaults to en. | en |
| company_name | No | Israeli legal or trading name. Provide this or company_number; add city when the name may be ambiguous. | |
| company_number | No | Israeli company registration number. A nine-digit number gives the most reliable exact match. | |
| expected_entity_type | No | Optional expected legal entity type, such as private company, used for disambiguation. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| company | Yes | |
| candidates | Yes | |
| checked_at | Yes | |
| confidence | Yes | |
| request_id | Yes | Unique preview request identifier. |
| next_action | Yes | |
| paid_actions | Yes | |
| preview_version | Yes | Preview contract version. |
| full_verification | Yes | |
| resolution_status | Yes | |
| preview_limitations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: it is free, returns reusable arguments for a paid report, and includes no field-level evidence or source URLs. This fully discloses the tool's limitations.
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 compact sentences with no filler. The key message 'RECOMMENDED FREE FIRST STEP' is front-loaded, and each sentence adds essential information about scope, output, and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is present and the annotations cover safety, the description is complete: it explains the free nature, the limited evidence scope, and how the results feed into the paid workflow. No critical information an agent needs to call 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?
The input schema already has 100% coverage with detailed descriptions for all six parameters, including disambiguation guidance and the company_name/company_number relationship. The tool description adds no parameter-specific semantics, but the schema carries the burden fully, 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?
The description states a specific action and resource: it resolves legal identity and registry status for an Israeli company without payment. It also explicitly frames itself as the recommended free first step versus the paid full report, distinguishing it from the paid sibling tools.
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 clearly names target use cases: Israel company verification, supplier checks, counterparty due diligence, and KYB evidence. It implies using this before the paid full report and says it returns arguments for that report, but it does not explicitly name an alternative tool or state 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.
FREE FIRST STEP before paying an Israeli tax invoice. Checks VAT and total arithmetic plus date-, amount-, VAT-, and buyer-sensitive Israel Invoices allocation-number applicability. Missing buyer context fails safely to HOLD. It never authorizes payment, resolves the supplier, or contacts the Tax Authority. Use authorize_israeli_invoice_payment_paid for the registry-backed PAY, HOLD, or BLOCK decision.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | ILS | |
| language | No | en | |
| vat_amount | Yes | ||
| invoice_city | No | ||
| invoice_date | Yes | ||
| total_amount | Yes | ||
| vendor_email | No | ||
| supplier_name | No | ||
| invoice_number | Yes | ||
| invoice_website | No | ||
| buyer_vat_number | No | ||
| allocation_number | No | ||
| amount_before_vat | Yes | ||
| expected_vat_rate | No | ||
| first_time_vendor | No | ||
| official_verification | No | Optional result obtained by the buyer through the Israel Tax Authority authenticated service. It is treated as buyer-attested, not independently authenticated by this API. | |
| urgent_payment_request | No | ||
| payment_details_changed | No | ||
| supplier_company_number | Yes | Nine-digit Israeli supplier company or VAT number. | |
| buyer_is_authorized_dealer | No | Buyer-attested answer: whether the invoice recipient is an Israeli authorized dealer (osek murshe). Required for a definitive allocation-number applicability result above the threshold. | |
| buyer_requested_allocation_number | No | Buyer-attested answer: whether the buyer requested an allocation number for this invoice. Required for a definitive applicability result above the threshold. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds meaningful context beyond that: missing buyer context 'fails safely to HOLD,' and the tool never authorizes payment, resolves the supplier, or contacts the Tax Authority. These are concrete behavioral disclosures that help the agent avoid misusing the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the value proposition, the concrete checks performed, the failure behavior, the non-behaviors, and the alternative tool in four dense sentences. There is no filler or repetition of schema constraints.
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 21-parameter tool with no output schema, the description is not exhaustive: it does not describe the exact return shape or discuss the meaning of several optional fields. However, required fields are clear from the schema, annotations cover the side-effect profile, and the fail-to-HOLD behavior plus the explicit handoff to authorize_israeli_invoice_payment_paid give the agent enough context to select and invoke the tool 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 only 19%, so the description carries extra responsibility. It adds high-level meaning by grouping parameters into 'VAT and total arithmetic' and 'date-, amount-, VAT-, and buyer-sensitive' allocation-number checks, and it notes buyer-context behavior. However, it does not explain most optional parameters such as official_verification, contact fields, currency, or language, so the compensation for low schema coverage is only partial.
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 action and scope: it is a free pre-payment gate that 'Checks VAT and total arithmetic plus date-, amount-, VAT-, and buyer-sensitive Israel Invoices allocation-number applicability.' It also separates itself clearly from the final authorization tool, authorize_israeli_invoice_payment_paid, by naming that tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly positions the tool as the 'FREE FIRST STEP before paying an Israeli tax invoice' and tells the agent when to stop using it: 'Use authorize_israeli_invoice_payment_paid for the registry-backed PAY, HOLD, or BLOCK decision.' It also states exclusions such as not authorizing payment, resolving the supplier, or contacting the Tax Authority.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE PREVIEW before paying an Israeli supplier. Confirms whether the company can be resolved and shows which invoice and payment-context signals will be evaluated. It does not reveal a risk score, mismatch findings, or decision. Use assess_israeli_vendor_payment_risk_paid for the evidence-backed PROCEED, REVIEW, or BLOCK result.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | en | |
| company_name | No | Israeli legal or trading name claimed by the buyer or invoice. | |
| invoice_city | No | Supplier city printed on the invoice or payment request. | |
| vendor_email | No | Supplier contact email used for the payment request. | |
| company_number | No | Israeli company number claimed by the buyer or invoice. | |
| invoice_amount | No | Optional invoice amount used as audit context, not as a credit signal. | |
| invoice_website | No | Supplier website presented in the transaction context. | |
| invoice_currency | No | Optional invoice currency. | |
| first_time_vendor | No | Whether this is the buyer's first transaction with the vendor. | |
| invoice_company_name | No | Supplier name printed on the invoice or payment request. | |
| invoice_company_number | No | Company number printed on the invoice or payment request. | |
| urgent_payment_request | No | Buyer-observed signal that unusual urgency was used to request payment. | |
| payment_details_changed | No | Buyer-observed signal that payment instructions recently changed. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| company | Yes | |
| checked_at | Yes | |
| request_id | Yes | |
| paid_assessment | Yes | |
| preview_version | Yes | |
| resolution_status | Yes | |
| preview_limitations | Yes | |
| supplied_signal_types | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral boundaries beyond the annotations: it confirms that this preview only verifies resolvability and signal coverage, and deliberately withholds the risk score, mismatch findings, and final decision. This prevents false expectations without contradicting 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 succinct sentences front-load the free-preview purpose, then state the scope, exclusions, and routing to the paid sibling. There is no filler or redundant detail; 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?
For a read-only preview tool with an output schema, high schema coverage, and zero required parameters, the description provides enough context to invoke it correctly: when to use it, what it returns, what it intentionally does not return, and which sibling covers the full paid decision. Nothing essential 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 92%, so the input schema already documents the individual parameters well. The description only refers generically to 'invoice and payment-context signals' rather than restating parameter semantics, which is acceptable given the high schema coverage and the baseline 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 free preview action for an Israeli vendor payment-risk assessment and clearly states what it confirms (company resolvability) and what it shows (invoice and payment-context signals). It also explicitly differentiates itself from the paid assessment tool by stating what it does not reveal: a risk score, mismatch findings, or a decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this tool as the pre-payment free option and instructs the agent to use assess_israeli_vendor_payment_risk_paid for the evidence-backed PROCEED, REVIEW, or BLOCK result. This gives an unambiguous when-to-use vs. when-not-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Israeli invoice payment gates and paid company verification. Checks invoice arithmetic and allocation-number rules, resolves records in the Israeli Companies Registry, and returns structured public-registry evidence. Tax Authority access requires buyer authorization. Not Full Regulatory KYB. PAID FULL RESULT: $0.05 USDC per successful call on Base Mainnet. Use preview_israeli_company_free first when only a free identity/status check is needed. One-command buyer bridge: https://israel-counterparty-intelligence.vercel.app/israel-company-verify-buyer-0.4.0.tgz
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Israeli city used to disambiguate companies with similar names. | |
| depth | No | Paid verification processing hint retained for compatibility. Both values currently return the complete evidence-backed public-registry result; standard is the default. | standard |
| website | No | Optional public company website used only as supporting resolution context. | |
| language | No | Language for the human-readable summary: en or he. Defaults to en. | en |
| company_name | No | Israeli legal or trading name. Provide this or company_number; add city when the name may be ambiguous. | |
| company_number | No | Israeli company registration number. A nine-digit number gives the most reliable exact match. | |
| expected_entity_type | No | Optional expected legal entity type, such as private company, used for disambiguation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial context: the $0.05 USDC cost per successful call on Base Mainnet, the buyer-authorization requirement, the fact that it returns structured public-registry evidence rather than full KYB, and the depth compatibility behavior. 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 front-loaded with the core purpose and packs in pricing, routing, and prerequisites efficiently. It is slightly noisy, however: it repeats 'paid' and 'full' from the title, uses all-caps for the pricing line, and ends with a bridge URL that is not essential to tool selection.
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 7 optional parameters and no output schema, the description adequately covers what the tool does, what evidence it returns, what authorization is required, and what it costs. It is slightly incomplete because it does not sketch the returned evidence fields and leaves the relationship to verify_israeli_company_paid ambiguous, but it is sufficient for 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 coverage is 100%: all 7 parameters have meaningful descriptions, enums, defaults, and formatting guidance. The free-text description provides no additional parameter-level meaning beyond what the schema already contains, so the baseline score 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?
The description states a specific action: resolving Israeli Companies Registry records and checking invoice arithmetic/allocation-number rules, and it identifies itself as the paid full-evidence verification versus the free preview sibling. It loses a point because the opening phrase 'Israeli invoice payment gates and paid company verification' blends two different services, and it does not distinguish itself from the similarly named verify_israeli_company_paid sibling.
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 to use preview_israeli_company_free first when only a free identity/status check is needed, and it gives a clear when-not boundary with 'Not Full Regulatory KYB'. It also notes the buyer-authorization prerequisite for Tax Authority access, giving the agent actionable routing and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RECOMMENDED PAID NEXT STEP after preview_israeli_company_free. Verifies an Israeli company number or legal name and returns the complete field-level Israeli Companies Registry evidence report with source URLs, confidence, missing-data disclosure, and checked_at. Costs $0.05 USDC on Base Mainnet. Not Full Regulatory KYB. One-command buyer bridge: https://israel-counterparty-intelligence.vercel.app/israel-company-verify-buyer-0.4.0.tgz
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Israeli city used to disambiguate companies with similar names. | |
| depth | No | Paid verification processing hint retained for compatibility. Both values currently return the complete evidence-backed public-registry result; standard is the default. | standard |
| website | No | Optional public company website used only as supporting resolution context. | |
| language | No | Language for the human-readable summary: en or he. Defaults to en. | en |
| company_name | No | Israeli legal or trading name. Provide this or company_number; add city when the name may be ambiguous. | |
| company_number | No | Israeli company registration number. A nine-digit number gives the most reliable exact match. | |
| expected_entity_type | No | Optional expected legal entity type, such as private company, used for disambiguation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive; the description adds meaningful behavioral facts beyond this: the $0.05 USDC cost on Base Mainnet, the paid nature of the operation, the report contents, and the KYB limitation. This is valuable context that annotations alone do not 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 compact and front-loaded with the key recommendation and core purpose. The cost, report contents, KYB disclaimer, and buyer bridge are all useful, though the long URL adds mild noise. 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?
For a paid read-only verification tool with no output schema, the description sufficiently conveys the core result shape (evidence report fields) and cost model. It does not fully explain edge cases, payment mechanics beyond the bridge link, or failure behavior, but the schema and annotations cover the remaining operational details well.
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 that company_number or company_name is the core input, but it does not add meaningful semantic details about city, website, language, expected_entity_type, or depth beyond what each parameter's schema description already states.
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-resource pair ('Verifies an Israeli company number or legal name') and clearly states the deliverable: a complete field-level Israeli Companies Registry evidence report with source URLs, confidence, missing-data disclosure, and checked_at. It also distinguishes this paid tool from preview_israeli_company_free, making its role among siblings clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this as the recommended paid next step after preview_israeli_company_free and adds a clear exclusion ('Not Full Regulatory KYB'). It could more directly name alternative paid siblings like assess_israeli_vendor_payment_risk_paid, but the free-vs-paid progression and KYB limitation provide solid usage context.
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.
get_israeli_company_changes_paid2 fields changedInput schema / properties / company_number / descriptionPrevious value: -"Exact nine-digit Israeli company registration number."New value: +"Exact nine-digit Israeli company registration number. Defaults to the public sample 514744887 when omitted (marketplace canary / empty paid body)."Input schema / requiredRemoved value: -[
- "company_number"
-]assess_israeli_vendor_payment_risk_paidauthorize_israeli_invoice_payment_paiddescribe_serviceget_israeli_company_changes_paidget_sample_verification_reportget_schemapreview_agent_payment_trustpreview_companypreview_israeli_company_freepreview_israeli_invoice_payment_gate_freepreview_israeli_vendor_payment_risk_freeverify_companyverify_israeli_company_paidIsrael payments for AI agents — cards / Apple Pay via Stripe. Never holds funds.
Taiwan payments (ECPay 綠界 + NewebPay 藍新) & e-invoices for AI agents. Stateless, never holds funds.
8 pay-per-call agent tools: company card $0.03, page meta $0.002. USDC on Base via x402.
x402 payment firewall + Agent Credit Bureau. Invoice/verify/score via RLUSD on XRPL.
Add one secure layer between your agents and this server.