P0: sanctions, KYB and payee checks

by dev.workers.x402-bazaar-rank-worker.x402-bazaar-rank

Check payee

check_payee

Read-onlyIdempotent

Use before an agent pays an address: one call screens the payee address against OFAC SDN, UK and EU wallet entries (sanctions lists), adds the rule-based wallet risk (EVM). Returns the paid x402 request for your input (GET /check/payee, $0.015 per call; schema linked). Call that URL with an x402 or MPP client to get the data. Bad input is refused before any charge. One payee address (0x EVM or Solana): sanctions wallet entries plus, for EVM, the rule-based wallet risk; for a person or company name use check_counterparty; for a list of addresses use sanctions_screening_batch. With an access key (Authorization: Bearer p0k_..., buy at https://x402-bazaar-rank.x402-bazaar-rank-worker.workers.dev/keys/buy?usd=5) the tool pays the call itself, returns the data and deducts the price. First call each day returns the data itself, free; later calls return the paid request.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "check_payee"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	Optional endpoint URL: probed once to see if it answers 402 paying that same address
`address`	Yes	The address you are about to pay: 0x EVM address or Solana address

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only declare this a safe read, but the description adds pricing ($0.015 per call), the two-step x402/MPP payment mechanics, the bearer access-key flow with a purchase URL, the free-first-call-per-day behavior, and the guarantee that bad input is refused before any charge. Those are exactly the operational facts an agent needs and none of them are derivable from 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.

Conciseness3/5

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

The guidance is front-loaded and the routing sentence is well placed, but the return behavior is stated three times in different words ("returns the paid x402 request", "call that URL... to get the data", "later calls return the paid request"), and the parenthetical price/schema note is buried mid-sentence. Trimming the duplicated payment explanation would sharpen it.

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?

For a paid proxy tool with no output schema and a non-obvious two-mode payment model, the description covers cost, auth, failure handling and return shape well enough to call it confidently. What is thin is the meaning of the optional url parameter and what a 'hit' looks like versus a clean screen.

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 coverage is 100%, so the 0x EVM vs Solana constraint and the address format are already documented in the schema. The description restates the single-address scope but adds nothing about the optional url parameter's probing behavior, so it stays at the baseline for a fully documented schema.

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 names a concrete verb (screens) and a concrete resource (payee address) and lists the exact list sources: OFAC SDN, UK and EU wallet entries plus EVM rule-based wallet risk. It explicitly separates itself from check_counterparty (person/company name) and sanctions_screening_batch (list of addresses), so an agent can route correctly 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.

Usage Guidelines4/5

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

"Use before an agent pays an address" gives a clear triggering condition, and two sibling alternatives are named with their selecting conditions (name vs list). It stops short of distinguishing this tool from the closely related sanctions_screening and wallet_risk siblings, whose coverage overlaps with what is described here, so the exclusion set is incomplete.

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

All P0: sanctions, KYB and payee checks 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.

Resources

Need Help?