Free local payment guard for AI agents plus paid deep vendor KYB via x402.
Scored across 2 tools
Both tools share the 'preflight' concept and both gate payments, so an agent could initially hesitate between them. However, the descriptions clearly delineate scope (payment-destination validation vs. vendor KYB/identity), and payment_preflight explicitly redirects deep KYB to vendor_preflight.
Both tools follow the same <noun>_preflight snake_case pattern, which is predictable and directly mirrors their purpose. No convention mixing.
Only two tools, one of which is explicitly flagged as legacy and points users to an external SDK, leaving a very thin surface. Borderline for the stated payment-safety/KYB purpose.
The pair covers a pre-payment allow/review/block decision, but there is no way to retrieve underlying evidence, review history, or re-verify after a decision, and one tool is deprecated. Coverage is workable but has notable gaps and a dead-end dependency on an external SDK.
LEGACY REMOTE COMPATIBILITY (0.01 USDC). New integrations should use the free local Payment Guard SDK at https://github.com/Andy229651/agentkyb-agent-tools. 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 full burden, and it does disclose the most consequential trait: the call costs 0.01 USDC. It also reveals the outcome space (allow/review/block). It does not say whether the fee is charged on failure, what thresholds distinguish review from block, or whether the check itself mutates anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the legacy/cost warning and the migration pointer, then the check list, then the sibling routing. Dense but every clause carries information; the repository URL takes up space but is warranted by the deprecation notice.
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 7 parameters and no output schema, the description does the essential work of naming the return verdicts and the validation dimensions. The main residual gap is decision semantics: what makes a result 'review' versus 'block' is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds real meaning by explaining the expected_* parameters collectively as a change-detection baseline ('detects recipient/network/price changes against caller expectations'), which tells the agent why all three exist together rather than as isolated fields.
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 resource (payment preflight) and enumerates exactly what is validated: HTTPS destination, EVM payTo format, Base network, amount validity, and drift detection against expectations. It also names the verdict it produces (allow/review/block) and explicitly separates itself from vendor_preflight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear steering away from this tool for new integrations (use the local SDK) and names the alternative for deep KYB checks (vendor_preflight). The positive trigger is only implied by 'LEGACY', not stated as a condition, so it falls short of full when/when-not coverage.
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 | |
| registration_number | No | Required for PL: 10-digit KRS, SK: 8-digit IČO, US: SEC CIK (1–10 digits). Optional company number for IE/LV. See country coverage for limited scopes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the output shape (allow/review/block), the evidence classes returned (legal-entity, sanctions signals, RDAP domain, domain consistency), and an explicit limitation ('not legal or transaction approval'). It omits auth requirements, latency, and whether the call is purely read-only, but the core behavior is transparent.
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 the action and purpose front-loaded, followed by return values and then scope limits. No filler; each clause carries information, though the final disclaimer clause is slightly terse for its importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description usefully specifies the decision verdicts and evidence returned, and it bounds liability scope. Combined with 100% schema coverage on inputs, an agent has enough to call it correctly; only operational details like auth or the x402 payment mechanics are left implicit.
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 all four parameters, including the country-specific registration_number rules. The description adds no parameter-level meaning beyond that, making the baseline 3 correct.
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 ('Verify vendor identity') and enumerates the checks performed (KYB, supplier risk, counterparty checks), which lets an agent separate it from the sibling payment_preflight by subject (vendor vs. payment). It never names the sibling explicitly, so differentiation relies on inference.
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?
'Verify vendor identity before paying' implies the triggering context, and 'not legal or transaction approval' bounds the scope. However, it never states when to prefer this over payment_preflight or what happens if the two are combined, leaving routing to inference.
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.
vendor_preflight2 fields changedInput schema / properties / name / maxLengthAdded value: +200Input schema / properties / registration_numberAdded value: +{
+ "description": "Required for PL: 10-digit KRS, SK: 8-digit IČO, US: SEC CIK (1–10 digits). Optional company number for IE/LV. See country coverage for limited scopes.",
+ "maxLength": 11,
+ "minLength": 1,
+ "type": "string"
+}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.
