[!IMPORTANT] This is a screening aid, not legal or compliance certification. Every tool returns potential matches with a transparent score and source provenance — never a verdict. A hit means "review this candidate against the official source"; an empty result never means "cleared." Real sanctions compliance is a legal process — it requires human review and a qualified compliance determination. This server feeds that process; it does not perform it, and its output is not a compliance record.

Overview

sanctions-screening-mcp-server turns the world's open sanctions data plus the global legal-entity registry into one screening-and-resolution workflow, answered offline and fuzzy-matched. It screens a name against the consolidated US (OFAC), EU, UK, and UN sanctions lists at once, and resolves legal entities against the GLEIF Legal Entity Identifier (LEI) database with corporate-ownership tracing.

All sources are bulk-downloadable, keyless, and clear for redistribution. The server mirrors them to a local SQLite + FTS5 index and serves matches from that mirror — no live API key, no per-request rate limit on the hot path. The agent sees screening verbs (screen_name, resolve_entity, trace_ownership); which list answered a query surfaces only as provenance on each hit.

The matching model is transparent by design: strict token matching first (exact-normalized, then all-tokens-present via FTS5), with a scored Jaro-Winkler + phonetic fuzzy fallback. Approximate hits carry the raw Jaro-Winkler similarity (0–1) — a real measurement, never a fabricated "confidence percentage."

Tools

Six tools organized around two workflows — screen a name against the watchlists, and resolve a legal entity to its global identifier and ownership graph:

sanctions_screen_name

The 80% entry point — "is this entity on a watchlist?"

• Fans out across all four sanctions lists (OFAC SDN + Consolidated, EU, UK, UN) in one call; the source surfaces only as provenance per hit
• Alias-aware: matches against every published primary name, a.k.a., and f.k.a., not just the canonical name
• Strict mode (default): exact-normalized equality, then all-tokens-present via FTS5 — handles word-order swaps and missing interior words with no fuzzy library
• Fuzzy mode (opt-in, or automatic when strict finds nothing): adds Jaro-Winkler similarity and Double-Metaphone phonetic matching for transliteration-class misses
• Hits labeled exact / strong / approximate; approximate hits carry the raw Jaro-Winkler score (0–1) plus queryTokenCoverage — how many query tokens the candidate explains, which ranks candidates that one shared exact token pins at the same score
• Filter by entity type, source list subset, similarity floor (minScore), and result limit
• Paged: totalAvailable and hasMore report matches beyond the returned page and nextOffset retrieves them, with totalAvailableBasis marking that count exact (strict) or a scanned-set floor (fuzzy)
• On an empty result, returns guidance on how to broaden — and states explicitly that no match is not a clearance

sanctions_get_designation

The drill-in after sanctions_screen_name surfaces a candidate.

• Full normalized record by source + entryId (the sourceEntryId from a screen hit)
• All published aliases, structured identifiers (passport / national ID / tax / registration), addresses, dates and places of birth, nationalities, sanctioning program, legal basis, and designation date
• Preserves source sparsity — missing fields mean the source omitted them; the record is never padded with fabricated data

sanctions_resolve_entity

The bridge from a free-text counterparty name to a stable LEI that the entity tools key off.

• Resolves a company / organization name to ranked GLEIF LEI candidates
• Optional ISO 3166-1 alpha-2 jurisdiction filter and registration-status filter (issued default, lapsed, or any)
• Same strict-then-fuzzy matching model as name screening; approximate hits carry the raw Jaro-Winkler score and the same queryTokenCoverage count
• Matches against legal names and published other/trading names
• Paged on the same contract as sanctions_screen_name — totalAvailable, totalAvailableBasis, hasMore, nextOffset

sanctions_get_entity

Who is this legal entity — plus a watchlist cross-reference in the same call.

• Full GLEIF Level 1 record: legal name, other/trading names, legal and headquarters addresses, registration status, jurisdiction, registration authority and ID, last-update date
• Cross-references the entity's legal name against all loaded watchlists (strict match only — auto-fuzzy on a generic legal name would flood the result with single-common-token false positives)
• screeningStatus says whether that cross-reference actually ran: an empty hit list under not_ready means the sanctions mirror was unavailable, not that nothing matched
• A screened entity carries sanctionsScreen — totalAvailable, totalAvailableBasis, hasMore — since the hit list is capped at twenty-five; re-screen the legal name with sanctions_screen_name for the full set
• LEI input is regex-validated (20 chars: 18 alphanumerics + 2 check digits)

sanctions_trace_ownership

Beneficial-ownership screening — the cross-source workflow that single-list tools can't do.

• Traverses the GLEIF Level 2 ownership graph breadth-first to a bounded depth (1–5)
• direction: walk parents (who owns it), children (what it owns), or both
• Returns nodes (with role and depth) and directed ownership edges with relationship type
• screenNodes: true screens every entity in the graph against all watchlists — "is anyone in this ownership chain sanctioned?"
• Per-node screen is strict-only and reports screenedNodeCount / flaggedNodeCount so a caller can see coverage at a glance
• Reports whether the graph is the full known picture: complete, truncated (further relationships exist past the requested depth), and missingEntityLeis (nodes with no GLEIF Level 1 record, which carry their LEI where a legal name would be)
• screeningStatus separates a completed node screen from one never requested and one the sanctions mirror could not run; each screened node carries sanctionsScreen — totalAvailable, totalAvailableBasis, hasMore — since its hit list is capped at ten

Resources and prompts