Skip to main content
Glama

Sanctions Screen OFAC EU UK UN

sanctions_screen
Read-onlyIdempotent

Sanctions screening (OFAC, EU, UK, UN): is a company, organisation, vessel (name or IMO), aircraft or crypto wallet address sanctioned? Screens the official US OFAC SDN and Consolidated lists, the EU consolidated financial sanctions list and the UK Sanctions List, flagging UN Security Council designations, with fuzzy name and alias matching; returns matches, scores, programs and each list's date. EU and UK are updated and freshness-checked separately, each for 48 hours; lists= selects which apply, and a stale requested list returns 503 before any payment. A UK update does not refresh EU. Entities only, not individuals. Use for KYB, AML, vendor and pre-payment screening. Data lookup, not a compliance determination. Signed receipt. Price: $0.005 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: {"name":"Huawei Technologies","lists":"all"}.

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_screen"
  }
}

Input Schema

NameRequiredDescriptionDefault
imoNo7-digit IMO vessel number
nameNoCompany, organisation, vessel or aircraft name to screen (give exactly one of name, imo, address). Entities only, not individuals
listsNoWhich lists: comma list of ofac, eu, uk, un, or all (default all). un = UN Security Council designations as carried in the UK and EU lists
addressNoCrypto wallet address (checked against OFAC only; see also /v1/sanctions/address)
min_scoreNoFuzzy match threshold 0.6-1.0, default 0.85

Output Schema

NameRequiredDescriptionDefault
dataNoSanctions matches with list (SDN, CONS, EU, UK), entry ID, type, programs, score, UN designation flag; plus each list's publish date and the lists screened
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. Changed2 schema fields 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."
      +}
    • 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."
  2. Changed6 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Crypto wallet address"New value: +"Crypto wallet address (checked against OFAC only; see also /v1/sanctions/address)"
    • addedInput schema / properties / imo / examples
      Added value: +[
      +  "9187629"
      +]
    • addedInput schema / properties / lists
      Added value: +{
      +  "description": "Which lists: comma list of ofac, eu, uk, un, or all (default all). un = UN Security Council designations as carried in the UK and EU lists",
      +  "examples": [
      +    "all",
      +    "ofac",
      +    "eu,uk"
      +  ],
      +  "pattern": "^(all|(ofac|eu|uk|un)(,(ofac|eu|uk|un)){0,3})$",
      +  "type": "string"
      +}
    • changedInput schema / properties / name / description
      Previous value: -"Organisation, vessel or aircraft name (give exactly one of name, imo, address)"New value: +"Company, organisation, vessel or aircraft name to screen (give exactly one of name, imo, address). Entities only, not individuals"
    • addedInput schema / properties / name / examples
      Added value: +[
      +  "Huawei Technologies",
      +  "Rosneft"
      +]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Paid result: { data, receipt }. Unpaid calls return an x402 PaymentRequired object instead (isError: true).",
      +  "properties": {
      +    "data": {
      +      "description": "Sanctions matches with list (SDN, CONS, EU, UK), entry ID, type, programs, score, UN designation flag; plus each list's publish date and the lists screened",
      +      "properties": {
      +        "dataset_source": {},
      +        "lists": {},
      +        "lists_screened": {},
      +        "loaded_at": {},
      +        "match_counts": {},
      +        "matches": {},
      +        "method": {},
      +        "notice": {},
      +        "other_lists_loaded_at": {},
      +        "other_sources": {},
      +        "potential_match": {},
      +        "query": {},
      +        "scope": {},
      +        "source": {}
      +      }
      +    },
      +    "receipt": {
      +      "description": "Ed25519-signed, hash-chained receipt; verify free with the verify_receipt tool or POST /v1/verify-receipt"
      +    }
      +  },
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, and the description still adds substantial operational context: per-list 48-hour freshness, the fact that a UK update does not refresh EU, a 503 returned before any payment when a requested list is stale, a signed receipt, and a provenance block with no score or verdict. Pricing ($0.005/call via x402) is also disclosed, which an agent needs before invoking.

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 core question and source lists are front-loaded, but the text is a dense single block of semicolon-separated clauses that mixes screening semantics, pricing, freshness policy and provenance. Some content duplicates the output schema (returned matches, scores, programs, list dates, provenance block), which the agent can read directly.

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 paid, multi-source screening tool this covers what an agent needs: inputs, sources, entity-type limit, freshness/error behavior, cost, and the non-determinative nature of the result. An output schema exists, so the return-value detail is redundant rather than 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 already documents name/imo/address/lists/min_score. The description nonetheless adds meaning the schema cannot: how list freshness interacts with the lists= selection (stale requested list yields 503, EU and UK refreshed independently). It adds nothing for min_score or the address-only-OFAC constraint beyond what the schema states.

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 states a concrete question ('is a company, organisation, vessel (name or IMO), aircraft or crypto wallet address sanctioned?') and names the exact data sources (OFAC SDN/Consolidated, EU consolidated, UK Sanctions List, UN designations). It also bounds the resource type ('Entities only, not individuals'), which separates it from person-screening tools and from the sibling sanctions_address 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?

Explicit use cases are given ('KYB, AML, vendor and pre-payment screening') plus an important exclusion ('Entities only, not individuals') and a scope caveat ('Data lookup, not a compliance determination'). What is missing is routing to named alternatives such as sanctions_address or counterparty_check — the address parameter merely points at '/v1/sanctions/address' inside the schema, not the tool.

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