This server provides tools to screen names against the official UK FCDO Sanctions List and retrieve detailed sanctions entries.
screen_name: Screen a person, company, or vessel name against the UK Sanctions List. Returns ranked possible matches with designation details including regime, entity type, sanctions imposed, and a statement-of-reasons snippet. Supports an optional limit parameter to control the number of results returned.
get_sanctions_entry: Fetch the complete official UK Sanctions List record for a specific Unique ID (e.g. RUS0251), including all names and aliases, regime, designation date, sanctions imposed, nationality, date of birth, and the UK statement of reasons.
Important caveats:
Results are indicative name-matches only — matches must be human-verified and are not confirmation of identity.
A "no match" is not a clearance — it only covers the UK FCDO list and reflects the dataset's report date.
This is not legal, compliance, KYC/AML, or regulated sanctions-screening advice.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sanctionwise screen 'Alexander Ivanov' on the UK sanctions list"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Verified UK sanctions screening for AI agents — official FCDO UK Sanctions List, not guesses.
Verified, trustworthy data tools for AI agents. "Qiniso" means "truth" in Zulu.
Website · npm · MCP Registry
Ask an LLM "is this person on the UK sanctions list?" and it will answer from stale, fuzzy memory. Designations change constantly and are specific — that's data, not something to recall. sanctionwise screens a name against the official FCDO UK Sanctions List and returns possible matches with their real designation details, or a clean "no match".
Indicative name-match only. A match is a POSSIBLE match that a human must verify against the official entry (names are widely shared and transliterated). It is not confirmation that the party you mean is the sanctioned party.
A "no match" is NOT a clearance. It covers the UK (FCDO) list only, screens the name string you pass (not DOBs or aliases you didn't supply), and reflects the dataset's report date, not real-time.
Not advice. Not legal, compliance, KYC/AML or sanctions advice, and not a substitute for a regulated sanctions-screening process. Every response includes this disclaimer.
Related MCP server: mcp-open-sanctions
{ "mcpServers": { "sanctionwise": { "command": "npx", "args": ["-y", "sanctionwise"] } } }The official UK Sanctions List data is bundled in the package (works offline, out of the box). The tool also auto-refreshes from a weekly-updated GitHub Release on startup — cached locally, no key, no token, no manual step — so it stays current on its own. Every response reports the dataset's report date.
npm i sanctionwiseimport { screenName, getSanctionsEntry } from "sanctionwise";
screenName("Vladimir Putin");
// { matchCount: 3, results: [{ id: "RUS0251", type: "Individual",
// primaryName: "Vladimir Vladimirovich PUTIN", matchType: "exact",
// regimes: ["The Russia (Sanctions) (EU Exit) Regulations 2019"], sanctions: "Asset freeze|…" }],
// disclaimer: "INDICATIVE NAME-MATCH SCREEN ONLY. …" }
screenName("Acme Quilting Supplies Ltd").matchCount; // 0 — no match (NOT a clearance)
getSanctionsEntry("RUS0251"); // full official entry for a Unique IDMatching folds accents and is case/punctuation-insensitive, and screens primary names and aliases.
Tool | What it does |
screen_name | Screen a person/company/vessel name → ranked POSSIBLE matches with official designation details |
get_sanctions_entry | Full official entry for a Unique ID (names, aliases, regime, statement of reasons, …) |
The data is the official FCDO UK Sanctions List (designated persons, entities and ships under the Sanctions and Anti-Money Laundering Act 2018), published under the Open Government Licence v3.0. scripts/build-data.mjs parses the official CSV into one record per target (all names/aliases grouped); the bundled build currently carries 6,200+ designated targets. A weekly GitHub Action (.github/workflows/refresh-data.yml) re-downloads the list and publishes it as a GitHub Release asset; the installed tool fetches that asset on startup (cached, offline-safe), so it self-updates with no npm token and no manual step. The bundled copy is the offline / first-run fallback.
Not a compliance determination. Indicative screening to surface possible matches for human review — nothing more.
Not multi-list. UK (FCDO) list only — not the EU, US (OFAC), UN consolidated, or any other list.
Not real-time. Reflects the dataset's report date; check the live list for the current position.
Not advice, and not a regulated screening service.
This tool runs locally on your machine and is built not to collect, store, or transmit your data — no analytics, no telemetry, no account. Screening runs locally; on startup it may download the latest public UK Sanctions List from a GitHub Release, but the names you screen are never transmitted. Full policy: https://qinisolabs.github.io/privacy.html.
Apache-2.0 (code). Sanctions data © Crown copyright, FCDO, Open Government Licence v3.0; see NOTICE.
USE THIS to fetch the full official UK Sanctions List entry for a Unique ID (e.g. one returned by screen_name) — all names/aliases, regime, designation date, sanctions imposed, nationality/DOB, and the UK statement of reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The UK Sanctions List Unique ID, e.g. 'RUS0001'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool fetches data and lists fields, but does not mention behavioral traits like read-only nature, authentication needs, rate limits, or error handling. It is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with 'USE THIS', and efficiently conveys all necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (full entry with listed fields). It could mention output format or any limitations, but for a simple fetch tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter with an example. The description adds value by noting that the ID can come from 'screen_name', providing operational context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch', the resource 'full official UK Sanctions List entry', and distinguishes from the sibling tool 'screen_name' by mentioning IDs returned by it. It also lists the data fields included, making the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE THIS' and provides context that the ID can come from 'screen_name', linking it to the sibling. However, it does not explicitly state when not to use or give alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USE THIS to screen a person, company or vessel name against the UK Sanctions List before onboarding, paying, or transacting with them — never decide from memory whether someone is sanctioned. Returns ranked POSSIBLE matches with the official designation details (regime, type, sanctions imposed, statement-of-reasons snippet). CRITICAL: this is an INDICATIVE name-match only — a match MUST be verified by a human against the official entry and is NOT confirmation; a 'no match' is NOT a clearance (it covers the UK FCDO list only, screens the name string only, and reflects the dataset's report date). Not legal, compliance or KYC/AML advice.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person/company/vessel name to screen. | |
| limit | No | Max matches to return (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses behavior: returns ranked possible matches with designation details, indicative only, must be verified, covers only UK list, string-based, data date, and not legal advice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the critical usage instruction, then provides essential details, warnings, and disclaimers. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sanctions screening and lack of output schema, the description fully explains the output (ranked matches, details), limitations (indicative, not clearance), and dataset scope. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema descriptions are present. The tool description adds context by linking 'name' to person/company/vessel and 'limit' to number of matches, reinforcing their purpose in the screening workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool screens a name against the UK Sanctions List, using the verb 'screen' and specifying the resource. It distinguishes itself from the sibling tool 'get_sanctions_entry' by focusing on proactive screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use ('before onboarding, paying, or transacting') and when-not-to-use: warnings that a match is not confirmation, no match is not clearance, and it covers only the UK FCDO list. Explicitly directs to human verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_sanctions_entryscreen_nameThe two tools have clearly distinct purposes: screen_name screens names against the sanctions list, while get_sanctions_entry retrieves full details for a specific entry by ID. There is no overlap or ambiguity.
Both tool names follow a consistent verb_noun pattern using snake_case: screen_name and get_sanctions_entry. This makes the action and target immediately clear.
With only two tools, the server is minimal but well-scoped for its purpose of sanctions screening and detail retrieval. It is slightly thin, but each tool serves a critical and distinct function.
The server covers the two primary actions needed for sanctions list interaction: screening a name and fetching a full entry. Missing tools like listing entries or regimes are minor gaps, but the core workflow is supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Checks whether a name is on the UK's financial sanctions list (HM Treasury), for compliance and AML
Screen a name or entity against OFAC SDN, the EU Consolidated list and the UK list.
Screen names against OFAC, EU, UK, UN sanctions lists; resolve entities via GLEIF. Screening aid.
Screen people & companies against 12 US sanctions & exclusion lists (OFAC, LEIE, SAM, Medicaid).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/qinisolabs/sanctionwise'
If you have feedback or need assistance with the MCP directory API, please join our Discord server