Skip to main content
Glama

Crypto Wallet Sanctions (OFAC)

sanctions_address
Read-onlyIdempotent

Crypto wallet sanctions check (OFAC): is this blockchain address on the US Treasury OFAC sanctions lists? Exact match against all 1,000+ digital currency addresses OFAC publishes on SDN and Consolidated entries (Bitcoin, Tron, Ethereum and EVM chains, USDT, Litecoin, Monero and more), returning the listing's program and entry ID. Use before sending or accepting a crypto payment. No tracing or risk scoring. Signed receipt. Price: $0.002 per call via x402 (USDC on Base or XRP on XRPL). The response includes a provenance block (sg-provenance/1): each fact carries its source, source URL, retrieval time and limits; evidence only, no score, rating or verdict. Example arguments: {"address":"0x098B716B8Aaf21512996dC57EB0615e2383E2f96"}.

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

Input Schema

NameRequiredDescriptionDefault
addressYesCrypto wallet address to check (exact match; 0x EVM and bech32 case-insensitive)

Output Schema

NameRequiredDescriptionDefault
dataNoWhether the address is OFAC-listed, the matching SDN/Consolidated entries (program, entry ID, currency) and the list coverage by currency
receiptNoEd25519-signed, hash-chained receipt; verify free with the verify_receipt tool or POST /v1/verify-receipt. New receipts carry a signed `evidence` object: service_version, data_timestamp, validation, terms_version, terms_hash, provenance_hash.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / data / properties / provenance
      Added value: +{
      +  "description": "The response includes a `provenance` block (sg-provenance/1): each fact carries its source, source URL, retrieval time and limits; evidence only, no score, rating or verdict."
      +}
  2. Changed1 schema field changed
    • changedOutput schema / properties / receipt / description
      Previous value: -"Ed25519-signed, hash-chained receipt; verify free with the verify_receipt tool or POST /v1/verify-receipt"New value: +"Ed25519-signed, hash-chained receipt; verify free with the verify_receipt tool or POST /v1/verify-receipt. New receipts carry a signed `evidence` object: service_version, data_timestamp, validation, terms_version, terms_hash, provenance_hash."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: exact-match-only behavior, what the response returns (listing program and entry ID), a signed receipt, the per-call price and payment rails, and the provenance block format. It also sets expectations that output is evidence-only with no score or verdict, which the annotations alone would not convey.

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?

Front-loaded with the core question and scope, followed by constraints, then commercial and provenance details. Slightly long, and the x402 pricing and provenance paragraph compress into a dense run-on, but every element is decision-relevant.

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?

For a single-parameter lookup with an output schema and rich annotations, the description covers scope, matching semantics, cost, output shape, and limitations. Nothing needed to invoke it correctly or interpret the result 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 the address parameter is already documented in structured data. The description adds value by restating exact-match semantics, enumerating which chain families are covered, and supplying a concrete example invocation, though it does not clarify the length/case-sensitivity rules the schema mentions.

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: check whether a blockchain address appears on OFAC sanctions lists, with exact-match semantics against 1,000+ published digital-currency addresses across named chains. It distinguishes itself from the name-based sibling sanctions_screen by the resource type (address vs. entity) and by explicitly disclaiming tracing/risk scoring.

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?

Gives a concrete trigger: "Use before sending or accepting a crypto payment," plus a clear scope exclusion ("No tracing or risk scoring"). It does not explicitly name sanctions_screen as the alternative for entity/name screening, so routing between the two still requires inference from the names.

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