Skip to main content
Glama

Sanctions screening

sanctions_screening
Read-onlyIdempotent

Use when you need to screen a wallet address or a person/company name against sanctions lists before paying or trading: OFAC SDN, UK, EU, Canada and US CSL in one call (UK and Canada: organisations and wallets only). Returns the paid x402 request for your input (GET /sanctions/check, $0.005 per call; schema linked). Call that URL with an x402 or MPP client to get the data. Bad input is refused before any charge. Sanctions lists only (OFAC SDN, UK, EU, Canada, US CSL; UK and Canada: organisations and wallets only). Send address or name, not both. For a broader rule-based risk label use wallet_risk (addresses) or token_risk (tokens); for a list of addresses use sanctions_screening_batch; for a payee address before paying use check_payee; for a company or person with country or LEI use check_counterparty. 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

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": "sanctions_screening"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoperson or entity name in Latin letters (transliterated), at least one word of 3+ characters (send this or address)
limitNoname matches only: max hits
addressNocrypto address to screen (send this or name)
min_scoreNoname matches only: lowest similarity score to report

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: per-call price ($0.005), the x402/MPP two-step handshake, the free-first-call-per-day behavior, that invalid input is refused before any charge, and the bearer-key authentication path. These are exactly the operational facts an agent cannot infer from structured fields.

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?

Front-loaded with the screening purpose and sibling routing, which is good, but there is real waste: the list enumeration "OFAC SDN, UK, EU, Canada, US CSL; UK and Canada: organisations and wallets only" appears twice in near-identical form, and the payment paragraph is dense enough to blunt the reading order. The content is valuable; the packaging is redundant.

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

Completeness5/5

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

No output schema exists, and the definition compensates by describing the return shape (a paid x402 request to GET /sanctions/check, or the data directly when an access key is present or on the first call of the day). Pricing, auth, input constraints, and alternative tools are all present, so nothing needed to invoke it correctly is missing.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns an extra point by stating the mutual-exclusion rule "Send address or name, not both," a constraint the schema does not express (both params are optional with no anyOf). It does not explain limit/min_score, but those are already documented as name-match-only in the 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?

States a specific verb and resource ("screen a wallet address or a person/company name against sanctions lists") and enumerates the exact source lists covered. It then names each sibling it is *not* — wallet_risk, token_risk, sanctions_screening_batch, check_payee, check_counterparty — so an agent can partition the family 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.

Usage Guidelines5/5

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

Explicit when-to-use framing ("before paying or trading") plus a complete routing table: use wallet_risk/token_risk for a broader risk label, sanctions_screening_batch for multiple addresses, check_payee for a payee before paying, check_counterparty when country or LEI is involved. Also states the eligibility exclusion (UK/Canada limited to organisations and wallets).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources