Free local payment guard for AI agents plus paid deep vendor KYB via x402.
Scored across 2 tools
payment_preflight handles transaction/technical consistency while vendor_preflight handles vendor identity and risk, so the two tools have clearly separated responsibilities. Both return allow/review/block, but the descriptions make the distinction obvious, including an explicit pointer to vendor_preflight for deep KYB.
Both tools follow the identical <noun>_preflight pattern, making their shared purpose and distinct subject matter immediately clear. There is no mixing of verb styles or casing conventions.
Two tools is at the low end of the spectrum and feels somewhat thin for a KYB/payment-safety server. Each tool earns its place, but the set would be more robust with additional capabilities such as report retrieval or ongoing monitoring.
The two preflight tools cover the core vendor-identity and payment-consistency decisions without dead ends. Minor gaps exist around persisted KYB records, historical checks, or follow-up investigation, but agents can still complete the primary workflow.
Fast pre-payment consistency guard for AI agents. Checks HTTPS destination, EVM payTo format, Base network, amount validity, and detects recipient/network/price changes against caller expectations. Returns allow/review/block. Use vendor_preflight for deep KYB.
| Name | Required | Description | Default |
|---|---|---|---|
| pay_to | Yes | Observed payment recipient wallet | |
| network | Yes | Observed CAIP-2 network, e.g. eip155:8453 | |
| endpoint | Yes | HTTPS service or payment endpoint | |
| amount_usd | Yes | Observed payment amount in USD/USDC terms | |
| expected_pay_to | No | Previously trusted or expected recipient wallet | |
| expected_network | No | Previously expected CAIP-2 network | |
| expected_amount_usd | No | Previously quoted or expected amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does a good job: it lists the checks performed and the allow/review/block verdicts. It does not explicitly state that no payment is executed, but 'pre-payment guard' strongly implies a non-executing safety check.
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 tight sentences with no filler. The core function is front-loaded, the checks are summarized, the output verdict is stated, and the sibling tool reference is placed at the end.
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 parameters and no output schema, the description covers the main behavior and the verdict type. It could be more explicit about the return shape or the exact conditions for block, but the essential decision-making context is present and the sibling routing is included.
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 semantic grouping: 'EVM payTo format' maps to pay_to, 'Base network' to network, 'amount validity' to amount_usd, and 'recipient/network/price changes' to the expected_* parameters. This clarifies how the optional expected parameters relate to the tool's purpose.
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 purpose: a pre-payment consistency guard that checks HTTPS destination, EVM payTo format, Base network, amount validity, and changes against caller expectations. It clearly distinguishes itself from vendor_preflight by naming what it does and what it does not cover.
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 routes agents to vendor_preflight for deep KYB, giving a clear alternative and the condition for choosing it. The 'pre-payment' and 'consistency guard' wording makes the intended use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify vendor identity before paying: KYB, supplier risk and counterparty checks for AI agents. Returns allow/review/block with legal-entity evidence, potential sanctions signals, RDAP domain evidence and company-domain consistency. Payment safety decision support via x402; not legal or transaction approval.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Vendor or counterparty name | |
| domain | No | Optional vendor domain | |
| country | No | Optional ISO 3166-1 alpha-2 country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavior disclosure burden. It clearly states the tool returns allow/review/block, what evidence types are included, and that it is decision support rather than legal or transaction approval. It does not disclose authentication or rate-limit behavior, but the essential behavioral contract is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both substantive and front-loaded with the core purpose. Every phrase adds value: the business context, the decision categories, the evidence types, the protocol context, and the explicit limit that this is not legal or transaction approval.
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?
Without an output schema, the description still conveys the decision categories and the nature of the returned evidence, which is sufficient for an agent to gauge expected results. Parameters are fully documented in the schema. Minor gaps like auth requirements or rate limits remain, but they do not block correct selection or 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 baseline of 3 applies because the schema already documents the three parameters. The description adds useful context like 'company-domain consistency' and 'RDAP domain evidence', which indirectly signals how the domain parameter is used, but it does not add significant new meaning on top of 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 opens with 'Verify vendor identity before paying', pairing a specific verb with the resource and the business context. It also enumerates concrete checks (KYB, supplier risk, counterparty) and the expected decision output, so an agent can immediately understand what the tool accomplishes.
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 states when to use it: 'before paying' and for 'payment safety decision support'. There are no sibling tools and no alternative to contrast, so stating the intended moment of use and the qualification 'not legal or transaction approval' provides clear usage context even without exclusions.
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.
payment_preflightcheck_domainresolve_companyscreen_sanctionsvendor_preflight1 field changedInput schema / properties / country / descriptionPrevious value: -"Optional ISO country code"New value: +"Optional ISO 3166-1 alpha-2 country code"check_domainresolve_companyscreen_sanctionsvendor_preflightx402 payment security and pre-execution transaction risk screening for autonomous AI agents.
Pay-per-call checks for AI agents: sanctions, MiCA, French KYB, AI Act. USDC via x402.
Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.
Verified LATAM data for AI agents: sanctions, entity, rates, KYB. Pay via x402.
Add one secure layer between your agents and this server.
