Skip to main content
Glama

OFAC sanctions screening

sanctions_screen
Read-onlyIdempotent

Answers "Is this company or person sanctioned by the US?" and "Is this crypto wallet on OFAC's list?" for KYC, vendor onboarding, payments and compliance checks. Screens a name against the US Treasury OFAC Specially Designated Nationals (SDN) list and the Consolidated (non-SDN) sanctions lists, primary names and aliases, tolerant of word order ("PUTIN, Vladimir"), accents, punctuation, honorifics, legal suffixes and small typos; and a cryptocurrency address against the addresses OFAC lists (exact match). Each match has a 0-100 score, the name it matched (primary or a.k.a.), and the listing: OFAC ID, type, programs, title, aliases, addresses, date of birth, nationality, crypto addresses and remarks. Filter by type and country; set the score threshold. clear is true when nothing matched. Lists are refreshed from OFAC every 12 hours. A screening aid, not legal advice. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.005 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
nameNoPerson, company, vessel or aircraft name, e.g. "Vladimir Putin" or "Rosneft".
typeNoOnly this kind of listing: individual, entity, vessel or aircraft.
limitNoMost matches to return, best first (default 10).
countryNoOnly listings with an address or nationality in this country, e.g. "Iran".
min_scoreNoLowest name-match score (0-100) to report. Default 85.
crypto_addressNoA cryptocurrency address to check against the addresses OFAC lists (exact match), e.g. a Bitcoin or Ethereum address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
      +  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description goes well beyond by disclosing the 12-hour list refresh, exact pricing ($0.005 USDC via x402), the billing rule that 400 and 4xx/5xx are not settled, and the fuzzy-vs-exact matching behavior. That is exactly the extra context annotations cannot carry.

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 two core questions, then matching behavior, then return shape, then cost — a sensible ordering with no filler. It is dense and long, but nearly every clause carries distinct information an agent needs.

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?

With no output schema, the description carries return-value burden and does: score, matched name (primary vs a.k.a.), listing fields, and the `clear` flag on no match. Combined with cost, refresh cadence and matching rules, nothing material is missing for correct invocation.

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, but the description adds semantics the schema lacks: name matching is tolerant of word order, accents, punctuation, honorifics, suffixes and typos, while crypto_address is exact match only, and it explains that the score is a 0-100 name-match value used with the threshold and that type/country act as filters.

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?

Opens with the two exact questions the tool answers and names the resource precisely (OFAC SDN and Consolidated lists, plus listed crypto addresses). An agent can distinguish it from wallet_risk_check or counterparty_check 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?

Explicitly names the situations it serves: KYC, vendor onboarding, payments and compliance checks, with the 'screening aid, not legal advice' boundary. It stops short of naming sibling alternatives (e.g. when to prefer wallet_risk_check or counterparty_check), so it is clear context without exclusions.

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