Tolca: business verification (KYB)

payment-check

payment_check

Read-onlyIdempotent

Check an x402 endpoint before paying it: is this x402 seller safe to pay? Send the seller's URL (or its 402). One call screens the payTo wallet against OFAC SDN crypto addresses, checks official USDC on its network (13 networks incl. Base, Solana, Polygon, Arbitrum) and compares price and payTo with the seller's Coinbase Bazaar listing. Returns allow / review / block, invoice hash and Ed25519-signed receipt. Input: url or payment_required, optional network, seller_name. Costs $0.01 USDC per call (x402 v2, Base or Solana). Send the HTTP header PAYMENT-SIGNATURE with your x402 payment, or call POST https://tolca.tonbot.ca/v1/payment-check with an x402 client.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "payment_check"
  }
}

Input Schema

Name	Required	Description
`url`	No	Or just the seller's paid URL: Tolca fetches its 402 payment request itself, without paying
`method`	No	Optional: method to use on the seller URL (default: GET, then POST)
`network`	No	Optional: network to check when the seller offers several, e.g. eip155:137, polygon, solana (default: Base)
`seller_name`	No	Optional: seller company name, screened against sanctions lists
`requirements`	No	One entry of the accepts array from the seller's 402 response
`seller_country`	No	Optional ISO-2 country code of the seller
`payment_required`	No	Or the full 402 response body

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 9, 2026
- addedInput schema / properties / payment_required / properties / accepts / description
```
Added value: +"The accepts array from the 402 response: the seller's payment options (1 to 20)"
```
- addedInput schema / properties / requirements / properties / maxAmountRequired / description
```
Added value: +"Amount in atomic units, x402 v1 field name (use amount for v2)"
```
- addedInput schema / properties / requirements / properties / scheme / description
```
Added value: +"x402 payment scheme, e.g. exact"
```

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / network

Added value: +{
+  "description": "Optional: network to check when the seller offers several, e.g. eip155:137, polygon, solana (default: Base)",
+  "type": "string"
+}

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / method

Added value: +{
+  "description": "Optional: method to use on the seller URL (default: GET, then POST)",
+  "enum": [
+    "GET",
+    "POST"
+  ],
+  "type": "string"
+}

changedInput schema / properties / payment_required / properties / accepts / maxItems
```
Previous value: -10New value: +20
```

addedInput schema / properties / url

Added value: +{
+  "description": "Or just the seller's paid URL: Tolca fetches its 402 payment request itself, without paying",
+  "type": "string"
+}

AddedNov 4, 2026

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given readOnlyHint and idempotentHint are already declared, the key additions are strong: cost ($0.01 USDC per call), payment/auth mechanics (PAYMENT-SIGNATURE header, x402 v2, Base or Solana), and the shape of the result (allow/review/block, invoice hash, Ed25519-signed receipt). Rate limits and failure/timeout behavior when the seller URL is unreachable are not covered, and the blocking semantics of a "review" verdict are left undefined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical intent is front-loaded in the first sentence, and the appended sentence on pricing and the PAYMENT-SIGNATURE flow earns its place because it governs whether the call will succeed. The middle clause enumerating networks is dense but informative; a slightly tighter phrasing would improve it further.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, nested objects, and no output schema, the description does the work of naming what comes back (allow/review/block, invoice hash, signed receipt) and how to pay for the call. It leaves gaps only around error conditions and the meaning of a "review" verdict, which are material for a pre-payment safety gate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 field including the nested requirements and payment_required objects. The description adds the either/or framing of "url or payment_required" and confirms which parameters are optional, but offers no extra detail on network or method resolution beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("Check an x402 endpoint before paying it") and then enumerates the concrete checks performed: OFAC SDN wallet screening, official USDC verification across 13 networks, and price/payTo comparison against the Coinbase Bazaar listing. This is distinguishable from siblings like sanctions_check or verify_business because it is explicitly scoped to x402 sellers and invoices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the trigger condition clearly ("before paying it") and even offers an alternative invocation path (POST to the endpoint with an x402 client). It does not explicitly say when to prefer a sibling tool such as sanctions_check for a plain wallet screen, so an agent must infer the boundary, but the usage context is otherwise unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tolca: business verification (KYB) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.