Skip to main content
Glama
Sign In

Distill

by com.spencermcw.data
OverviewDiscussionsAdmin

Is this crypto address on OFAC’s SDN sanctions list? SDN entry, program, asset and list date for Bitcoin, Ethereum and EVM, Tron, Solana and other addresses, checked by Distill against OFAC’s own SDN file

sanctions_address
Read-only

Is this crypto address on OFAC’s SDN sanctions list? SDN entry, program, asset and list date for Bitcoin, Ethereum and EVM, Tron, Solana and other addresses, checked by Distill against OFAC’s own SDN file. Matches one digital currency address (Bitcoin, Ethereum and every EVM chain, Tron, Solana, Monero, …) against the “Digital Currency Address” identifiers of OFAC’s Specially Designated Nationals list, read from OFAC’s Sanctions List Service SDN.XML and refreshed daily. Returns whether it is listed in the latest publication, each listing’s SDN entry (UID, name, type, programs), asset and chain, the publication date, and any earlier listing a later publication removed. Not listed is an answer too. Exact match only; not a compliance determination. The address is not stored. Refreshed daily (live freshness: /status). Price: $0.005 per call. Free tier: 3 free calls a day per IP, at most 3 rows per answer, taken by an unpaid call unless its _meta["distill/free-tier"] is "skip". Answers in a summary view of about 3,000 tokens; view: "full" for every row. Confidence: Freshness only (the list is OFAC’s, matched exactly): 1 until 3 days after the last check of OFAC’s Sanctions List Service, then halving every 3 days. Facts from the OFAC SDN list as published on the date stated: an exact match of the address as given (EVM and Bech32 addresses case-insensitively). Not legal advice and not a compliance determination: no ownership (50% rule) analysis, no indirect exposure, no other sanctions list. Computed by Distill from OFAC’s SDN.XML. See /terms.

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
viewNosummary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).
addressYesA digital currency address as used on its chain: EVM 0x… (any case), Bitcoin (1…, 3…, bc1…), Tron T…, Solana, Monero, ….

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / view
      Added value: +{
+  "description": "summary (the default): the answer a model needs, budgeted; full: every row (a free answer stays capped).",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses data provenance (OFAC's own SDN.XML via the Sanctions List Service), daily refresh with a /status freshness endpoint, a decaying confidence score tied to days since last check, no storage of the submitted address, cost ($0.005/call), and free-tier quirks including the 3-row cap and the _meta skip flag. These are exactly the operational facts an agent needs before deciding to spend a call.

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?

Purpose is front-loaded, but the body is a dense run-on that repeats the 'not a compliance determination / not legal advice' caveat twice and restates the title's framing in the first sentence. Pricing, free-tier mechanics, confidence decay, and disclaimers all compete for attention in a single paragraph with little structural separation.

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 two-parameter lookup with no output schema, the description covers return contents, freshness, confidence, cost, free-tier constraints, and explicit non-goals. There is essentially nothing a caller would need to know before invoking it that 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 schema baseline is 3, but the description adds real semantics on top: single-address matching, exact match only, and case-insensitive comparison for EVM and Bech32 addresses, plus the summary-vs-full output tradeoff and the free-tier row cap. It does not explain the address pattern/128-char limit, which stays schema-side.

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 opening sentence names a specific question ('Is this crypto address on OFAC's SDN sanctions list?') and the description enumerates exactly what it returns: SDN entry (UID, name, type, programs), asset, chain, publication date, and earlier removed listings. It also scopes the input surface (Bitcoin, EVM, Tron, Solana, Monero), so an agent cannot confuse it with any sibling data-lookup tool.

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 clearly frames the use case (exact-address sanctions screening) and states explicit limits: exact match only, not a compliance determination, no 50% rule analysis, no indirect exposure, no other lists, and 'not listed is an answer too.' It does not name a competing tool or say when to prefer a batch/other approach, but no sibling offers an alternative here, so the absence is minor.

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

All Distill toolsInspect
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