Skip to main content
Glama
fairquery

fairquery-sanctions-screener

Official
by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Sanctions & Watchlist Screener (OFAC, EU, UK, UN)

Screens people and company names against the OFAC, EU, UK and UN sanctions lists (from the official sources, re-downloaded at least every 6 hours, with each list's publication date in every row) for $3 per 1,000 names. You pay $0.003 per name that gets a screening row, and if no list can be downloaded nothing is charged. Example: re-screening 2,000 suppliers costs 2,000 × $0.003 = $6.00, plus a $0.007 Actor-start fee per run.

Fairquery Apify Actor that screens people and company names against the main public sanctions lists, downloaded from the official sources (re-downloaded whenever the cached copy is older than 6 h, configurable 0–12 h): OFAC SDN and Consolidated (US), EU Consolidated Financial Sanctions, the UK Sanctions List (FCDO / OFSI), and the UN Security Council Consolidated List. Each name gets a potential_match / no_match status, a 0–100 fuzzy score, and the matching entries with aliases, programs, countries and dates of birth.

Not a certified screening service. This is automated fuzzy matching against public lists. It can return false positives and can miss true matches (transliterations, very short names, lists that fail to download). Review every potential match manually against the official source, and get legal advice before acting on results. It does not replace a regulated KYC/AML provider.

When to use this Actor (LLM / tool selection)

Use it when an agent or workflow needs to:

  • Pre-screen a new customer, supplier, vendor or marketplace seller against sanctions lists (KYB / onboarding)

  • Re-screen a counterparty list in bulk (thousands of names per run)

  • Check whether a company or person is on OFAC, EU, UK or UN lists and see the program and listing details

  • Add a sanctions check step to an export, payments or procurement workflow

Related MCP server: Sanctions Screening MCP Server

Lists and sources

lists id

List

Source

OFAC_SDN

OFAC Specially Designated Nationals

sanctionslistservice.ofac.treas.gov SDN.CSV + ALT.CSV + ADD.CSV

OFAC_CONS

OFAC Consolidated (non-SDN: SSI, NS-MBS, FSE, …)

CONS_PRIM / CONS_ALT / CONS_ADD.CSV

EU

EU Consolidated Financial Sanctions List

webgate.ec.europa.eu/fsd/fsf CSV 1.1 (falls back to CSV 1.0)

UK

UK Sanctions List (incl. OFSI asset-freeze targets)

sanctionslist.fcdo.gov.uk CSV

UN

UN Security Council Consolidated List

scsanctions.un.org XML

List freshness and cache. Parsed lists are cached in a named key-value store in your Apify account (fairquery-sanctions-list-cache, about 1.6 MB) and reused only while they are younger than listCacheMaxAgeHours (default 6, max 12, measured from the download time). An older copy is never used: the list is downloaded again, and if that download fails the list is reported as unavailable rather than served stale. Set listCacheMaxAgeHours to 0 to download fresh on every run. Every result row carries list_versions with each list's published_at (the date stated by the source: OFAC file time, EU fileGenerationDate, UK Report Date, UN dateGenerated), source_last_modified, fetched_at, from_cache and cache_age_secs. Only your account's storage is used; no screened names are stored. If a source is down, the run continues with the other lists and every row reports it in lists_unavailable; per-list entry counts, download times and errors are in RUN_SUMMARY.

Matching

  • Names are normalised (diacritics, case, punctuation, &, legal suffixes such as LLC/GmbH/JSC, honorifics) and compared token by token with Jaro-Winkler, so word order (PUTIN, Vladimir), extra middle names, and spelling variants (Poutine, Usama/Osama, Gaddafi/Qadhafi) still match.

  • Every alias (a.k.a., f.k.a., non-Latin script names) is screened; matched_on tells you whether the hit was the primary name or an alias.

  • Optional country (ISO-2 or name) adds country_match; excludeNonMatchingCountry drops mismatches.

  • Optional dateOfBirth drops individuals whose listed birth years differ by more than dobYearTolerance; entries without a DOB are kept.

Input

Field

Type

Default

Description

names

string[]

– (sample names are prefilled in the Console form)

One name per line

queries

object[]

[]

{name, id?, country?, dateOfBirth?, entityType?}

lists

string[]

all five

OFAC_SDN, OFAC_CONS, EU, UK, UN

minScore

int

85

60–100

maxMatchesPerName

int

10

Top matches per name

entityType

any | individual | entity

any

country

string

–

Default country for all names

excludeNonMatchingCountry

bool

false

dobYearTolerance

int

1

listDownloadTimeoutSecs

int

60

Per list file

maxNames

int

10000

Safety cap

{
  "names": ["Banco Nacional de Cuba", "Jane Example Smith"],
  "queries": [{ "name": "Ali Khamenei", "id": "cust-42", "country": "IR", "dateOfBirth": "1939" }]
}

Output

{
  "schema_version": "1.0.0", "type": "screening",
  "query": { "name": "Ali Khamenei", "id": "cust-42", "country": "IR", "date_of_birth": "1939", "entity_type": "any" },
  "status": "potential_match", "best_score": 92.5, "match_count": 1,
  "matches": [{
    "score": 92.5, "matched_name": "KHAMENEI, Ali Husseini", "matched_on": "primary",
    "list": "OFAC_SDN", "list_name": "OFAC Specially Designated Nationals (SDN) List", "entry_id": "…",
    "entity_type": "individual", "primary_name": "KHAMENEI, Ali Husseini", "aliases": ["…"], "programs": ["IRAN-EO13876"],
    "countries": ["Iran"], "dates_of_birth": ["19 Apr 1939"], "listed_on": null,
    "country_match": true, "dob_match": true, "source_url": "https://sanctionssearch.ofac.treas.gov/Details.aspx?id=…"
  }],
  "lists_screened": ["OFAC_SDN", "OFAC_CONS", "EU", "UK", "UN"], "lists_unavailable": [],
  "min_score": 85, "disclaimer": "Not a certified screening service. …"
}

Error rows (type: "error", never charged): INPUT_EMPTY, MAX_NAMES_EXCEEDED, LISTS_UNAVAILABLE (no list could be downloaded).

Pricing

Event

Price

When

name-screened

$0.003

Each name that gets a screening row (potential_match or no_match)

apify-actor-start

$0.007

Once per run (memory is capped at 512 MB, so always one event)

Error rows (INPUT_EMPTY, MAX_NAMES_EXCEEDED, LISTS_UNAVAILABLE) are never charged. If no list can be downloaded, nothing is charged.

Worked example: a monthly re-screen of 2,000 counterparties in one run: 2,000 × $0.003 = $6.00, plus $0.007 (512 MB counts as one start event). Put all names into one run: the per-name price is the same, but every run pays its own $0.007 start fee, so a single-name run costs $0.003 + $0.007 = $0.01.

To cap spend, set a maximum cost per run in the run options; the Actor stops cleanly at the limit. maxNames caps how many names one run screens. Prices are from the Store pricing tab (October 2026).

Memory / runtime

Default and maximum 512 MB. Each run loads and indexes all five lists (about 33k entries, 100k+ names) before screening: about 1–5 s from a fresh cache, or 10–40 s (up to about 60 s when a government server is slow) when the lists are downloaded again. After that, screening runs at hundreds of names per second. Put all names into one run rather than one run per name.

MCP / Apify tools

Call from agents via Apify MCP with Actor fairquery/sanctions-watchlist-screener:

{ "actor": "fairquery/sanctions-watchlist-screener", "input": { "names": ["Acme Trading LLC"] } }

Local stdio MCP server

The mcp/ folder is a stdio MCP server (TypeScript, @modelcontextprotocol/sdk) with two tools, both with annotations and output schemas:

Tool

What it does

Cost

screen_names

Runs this Actor and returns the rows

Needs APIFY_TOKEN, billed per name

list_sources

Lists covered lists, source URLs, score scale, disclaimer

Free, local, no token

cd mcp && npm install && npm run build
node scripts/smoke-test.mjs                          # initialize + tools/list + free tool, no token
APIFY_TOKEN=... node scripts/smoke-test.mjs --call   # real call
{ "mcpServers": { "fairquery-sanctions-screener": { "command": "node", "args": ["/path/to/sanctions-watchlist-screener/mcp/dist/index.js"], "env": { "APIFY_TOKEN": "<your Apify token>" } } } }

Docker: the root Dockerfile builds the MCP server image (docker build -t fairquery-sanctions-screener-mcp .); it is also the Dockerfile for Glama. The Actor image is .actor/Dockerfile. glama.json lists fairquery as maintainer.

Works well after

  • Website Contact & Company Enricher or Google Maps Scraper: screen the company names they return before you onboard a supplier, partner or marketplace seller.

  • Any CRM or ERP export of customers, vendors or payees: map name, country and date of birth into queries to cut false positives.

Troubleshooting

Symptom

Cause and fix

Run ends with only an INPUT_EMPTY row

No names in names or queries. The sample names in the Console form are prefill only and are not sent with API calls.

lists_unavailable is not empty

An official source was down or slow. The other lists were still screened. Re-run later, or raise listDownloadTimeoutSecs (default 60 s per file). Per-list errors are in RUN_SUMMARY.

LISTS_UNAVAILABLE error and nothing charged

No list could be downloaded at all (network or source outage). Retry later.

Too many potential matches for common names

Add country and dateOfBirth per query, set entityType, raise minScore (default 85), or turn on excludeNonMatchingCountry.

A known listed name was not matched

Try a lower minScore (60–80) and check the spelling or transliteration. Very short names and unusual transliterations can be missed; see the disclaimer.

First minute of the run shows no results

This is expected when the cache is older than the window: the lists are downloaded and indexed first (usually 10–40 s, up to about 60 s).

FAQ

Is this a certified screening service?

No. It is automated fuzzy matching against public lists. Review every potential match against the official source, and use a regulated KYC/AML provider where the law requires one.

How fresh are the lists?

They come from OFAC, the European Commission, the UK FCDO and the UN. A run reuses a copy cached in your account only if it was downloaded less than listCacheMaxAgeHours ago (default 6 h, max 12 h); otherwise it downloads them again. Each row's list_versions shows the publication date and download time of every list used.

How long does a run take?

Usually 10–40 s (up to about 60 s) to load the lists, then hundreds of names per second.

How much does it cost?

$0.003 per screened name ($3 per 1,000), plus a $0.007 start fee per run. Error rows are free, and nothing is charged if no list loads.

How do I limit spend?

Set a maximum cost per run in the run options and/or lower maxNames.

Can an AI agent call it?

Yes, through Apify MCP with Actor fairquery/sanctions-watchlist-screener, or through the Fairquery MCP server (npx -y @fairquery/agent-trust-mcp, tool sanctions_screen_names).

Fairquery family

Other Fairquery tools on the Apify Store. Each one returns structured rows with machine-readable error codes, and error rows are never charged:

All Fairquery Actors: https://apify.com/fairquery

Kits & templates

Optional guides from Fairquery for wiring this Actor into agents and automations (the Actor works fine without them):

Disclaimer

Not a certified screening service. Results come from automated fuzzy matching against public lists downloaded from the official sources (at run time or from a cache no older than the freshness window) and are provided as is, without warranty. They may be incomplete, out of date or wrong. Always confirm potential matches with the official publication of the relevant authority (OFAC, European Commission, UK FCDO/OFSI, UN Security Council) and take legal advice before making compliance decisions. Data comes from public government sources; Fairquery is not affiliated with any of them.

Links

Development

Local development, tests and deployment notes are in DEVELOPMENT.md. The Apify Store README is .actor/README.md.

Available Tools

2 tools
list_sourcesList covered sanctions sources (free)A
Read-onlyIdempotent
Inspect

WHAT: Static list of the official sanctions lists screen_names checks (id, name, issuing authority, download URL), the 0-100 score scale and the legal disclaimer. WHEN TO USE: to choose the lists parameter for screen_names, cite sources in a report, or explain coverage. WHEN NOT TO USE: to screen a name - use screen_names. Does not download lists or report list freshness. COST: free; local, no network, no APIFY_TOKEN, deterministic. (screen_names costs $0.003 per name.) RETURNS: {sources:[{id,name,authority,url}], score_scale, disclaimer}. PARAMETERS: None: call with an empty object {}; the result is static and cannot be filtered. Its output feeds screen_names: each sources[].id (OFAC_SDN, OFAC_CONS, EU, UK, UN) is a valid value for its lists parameter, and score_scale explains how its minScore threshold is applied. EXAMPLE: {} -> {"sources":[{"id":"OFAC_SDN","authority":"US Treasury OFAC",...},...]}

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
sourcesYesCovered lists; id is the value for screen_names.lists
disclaimerYesLegal disclaimer to show with results
score_scaleYesHow best_score is computed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds behavior they cannot express: cost is free and local with no network or APIFY_TOKEN, deterministic output, versus $0.003 per name for screen_names. This cost/execution context is exactly the kind of value-add that structured fields 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?

Labeled sections (WHAT/WHEN/COST/RETURNS/PARAMETERS/EXAMPLE) are scannable and front-loaded. However, the RETURNS shape and the EXAMPLE line largely duplicate each other, and the parameter-less nature is restated in two places, so a small amount of text is redundant.

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?

Given an output schema exists, return values need not be explained, yet the description still sketches the shape and adds the cross-tool linkage to screen_names that the output schema cannot convey. Nothing an agent needs to call a zero-parameter, closed-world tool correctly 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?

Zero parameters, so the baseline is 4. The description still earns its keep by stating the empty-object calling convention and that results cannot be filtered, plus mapping output ids (OFAC_SDN, OFAC_CONS, EU, UK, UN) to the sibling's lists parameter. That is invocation guidance rather than parameter semantics, so it does not push above the baseline.

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?

States a specific verb and resource ('Static list of the official sanctions lists screen_names checks') and enumerates the returned fields (id, name, issuing authority, download URL). An agent can instantly separate this reference-data tool from the sibling screen_names screening tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN TO USE section names three concrete scenarios (choosing the lists parameter, citing sources, explaining coverage) and WHEN NOT TO USE explicitly routes screening to screen_names. It also discloses what the tool does not do (no downloading, no freshness).

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

screen_namesScreen names against sanctions listsA
Read-onlyIdempotent
Inspect

WHAT: Fuzzy-match people or organisation names against the OFAC SDN, OFAC Consolidated (non-SDN), EU, UK and UN sanctions lists, from the official sources (cached in your Apify account for at most 6 h, otherwise re-downloaded; each row reports list publication dates). Order-, case- and diacritics-insensitive; optional country and date-of-birth filters per name. WHEN TO USE: KYC/KYB onboarding, vendor or counterparty checks, bulk re-screening of customer lists. Put all names into one call (lists are downloaded once per run). WHEN NOT TO USE: to see which lists/authorities are covered or to cite sources, call list_sources (free). Not a PEP/adverse-media check, not a certified screening service. COST: paid. Runs Apify Actor fairquery/sanctions-watchlist-screener with your APIFY_TOKEN; pay-per-event "name-screened": $0.003 per name that gets a screening row, match or no match, plus a $0.007 start fee per call (one run); nothing is charged per name if no list could be loaded, and error rows are free. 200 names in one call ~ $0.61. Lists load in ~2-5 s from a cache in your Apify account (at most 6 h old) or ~10-40 s when re-downloaded, then hundreds of names/s. RETURNS: {count, items}. type="screening" row per name: query, status (potential_match | no_match), best_score 0-100, match_count, matches[] (list, entry id, primary name, aliases, programs, countries, DOB, score, country_match, dob_match), lists_screened, lists_unavailable, min_score, screened_at, disclaimer; or type="error" rows (code, message). EXAMPLE: {"queries":[{"name":"Banco Nacional de Cuba","entityType":"entity"}],"minScore":90} -> one screening row, status potential_match with OFAC_SDN matches. PARAMETERS: names and/or queries: at least one is required although the schema marks both optional (neither -> a free INPUT_EMPTY error row); both may be combined and every entry is billed once ($0.003), so send all names in ONE call (one $0.007 start fee and one list load per run). Use names for bare strings and queries when you have per-name country / dateOfBirth / entityType or want your own id echoed. Per query, dateOfBirth drops listed individuals whose recorded birth year differs by more than 1 year (entries without a DOB are kept); country only sets country_match (true/false/null) unless excludeNonMatchingCountry=true, which then drops matches whose listed countries exclude it (entries without country data are kept). entityType: a query's own value wins over the top-level one; "entity" means anything that is not an individual (organisations, vessels, aircraft), and list entries of unknown type always pass. lists: omit for all five; a list whose download fails is reported in lists_unavailable rather than failing the run. minScore: a candidate is returned only if its 0-100 name similarity is >= minScore; it does not change the price - 85 default, 90-95 for large batches with fewer false positives, 75-80 for transliterated names. maxMatchesPerName trims matches[] (best first) but match_count still counts all. Not a certified screening service. Automated fuzzy matching against public lists downloaded at run time; results can contain false positives and miss matches. Review every potential match manually and consult official sources and legal counsel before acting.

ParametersJSON Schema
NameRequiredDescriptionDefault
listsNoOptional, default all five. Any subset of "OFAC_SDN" | "OFAC_CONS" | "EU" | "UK" | "UN" (ids from list_sources). Example: ["OFAC_SDN","EU"]
namesNoOptional if queries is given (at least one of the two is required). Plain person or organisation names (non-empty strings, any order/case/diacritics); $0.003 each. Example: ["Vladimir Putin","Acme Trading LLC"]
queriesNoOptional if names is given. {name, id?, country?, dateOfBirth?, entityType?} objects with per-name filters; $0.003 each. Example: [{"name":"Ali Khamenei","id":"cust-42","country":"IR","dateOfBirth":"1939","entityType":"individual"}]
minScoreNoOptional integer 60-100, default 85. Minimum 0-100 fuzzy name-similarity score for a match. Use 90+ for fewer false positives, ~80 for more recall. Example: 90
entityTypeNoOptional, one of "any" | "individual" | "entity", default "any". Entity filter for all names; a query's own entityType wins. Example: "entity"
maxMatchesPerNameNoOptional integer 1-100, default 10. Top matches returned per name (best first); match_count still reports the total. Example: 3
excludeNonMatchingCountryNoOptional boolean, default false. true removes matches whose listed countries do not include the query country (entries without country data are kept). No effect without queries[].country.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesNumber of rows in items
itemsYesDataset rows: type=screening or type=error

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnly/idempotent/openWorld, and the description adds substantial behavior beyond them: 6-hour cache vs re-download latency, the Apify Actor dependency and token requirement, the exact pay-per-name/start-fee model with per-name free cases, and failure handling (failed lists surface in lists_unavailable rather than aborting).

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 WHAT/WHEN/COST/RETURNS/PARAMETERS headers, making a long description navigable, and each section earns its place. There is minor redundancy (the 'not a certified screening service' caveat appears twice) that keeps it just short of a 5.

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, open-world, network-dependent tool with 7 optional params, the definition covers cost, return shape, latency, failure modes, and legal caveats; the separate output schema handles the row fields, so nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds real meaning the schema lacks: precedence rules (a query's entityType beats top-level; unknown-type entries always pass), the DOB ±1-year drop behavior with entries lacking DOB kept, country only setting country_match unless excludeNonMatchingCountry, and the fact that names/queries are billed identically so all names should go in one call.

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 a specific verb+resource ('Fuzzy-match people or organisation names') and names the exact scope (OFAC SDN, OFAC Consolidated, EU, UK, UN). It also distinguishes itself from its only sibling by naming list_sources as the tool for coverage questions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit WHEN TO USE (KYC/KYB onboarding, vendor checks, bulk re-screening), WHEN NOT TO USE (pointing to list_sources, and disclaiming PEP/adverse-media/certified screening), and an operational directive to batch all names into one call to avoid repeated list loads.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.2
    • Changedlist_sources3 fields changed
      • addedOutput schema / properties / disclaimer / description
        Added value: +"Legal disclaimer to show with results"
      • addedOutput schema / properties / score_scale / description
        Added value: +"How best_score is computed"
      • addedOutput schema / properties / sources / description
        Added value: +"Covered lists; id is the value for screen_names.lists"
    • Changedscreen_names13 fields changed
      • addedInput schema / properties / entityType / description
        Added value: +"Optional, one of \"any\" | \"individual\" | \"entity\", default \"any\". Entity filter for all names; a query's own entityType wins. Example: \"entity\""
      • addedInput schema / properties / excludeNonMatchingCountry / description
        Added value: +"Optional boolean, default false. true removes matches whose listed countries do not include the query country (entries without country data are kept). No effect without queries[].country."
      • changedInput schema / properties / lists / description
        Previous value: -"Default: all five"New value: +"Optional, default all five. Any subset of \"OFAC_SDN\" | \"OFAC_CONS\" | \"EU\" | \"UK\" | \"UN\" (ids from list_sources). Example: [\"OFAC_SDN\",\"EU\"]"
      • addedInput schema / properties / maxMatchesPerName / description
        Added value: +"Optional integer 1-100, default 10. Top matches returned per name (best first); match_count still reports the total. Example: 3"
      • changedInput schema / properties / minScore / description
        Previous value: -"Default 85"New value: +"Optional integer 60-100, default 85. Minimum 0-100 fuzzy name-similarity score for a match. Use 90+ for fewer false positives, ~80 for more recall. Example: 90"
      • changedInput schema / properties / names / description
        Previous value: -"Names to screen"New value: +"Optional if queries is given (at least one of the two is required). Plain person or organisation names (non-empty strings, any order/case/diacritics); $0.003 each. Example: [\"Vladimir Putin\",\"Acme Trading LLC\"]"
      • changedInput schema / properties / queries / description
        Previous value: -"Names with optional country (ISO-2 or name), dateOfBirth (YYYY or YYYY-MM-DD), entityType"New value: +"Optional if names is given. {name, id?, country?, dateOfBirth?, entityType?} objects with per-name filters; $0.003 each. Example: [{\"name\":\"Ali Khamenei\",\"id\":\"cust-42\",\"country\":\"IR\",\"dateOfBirth\":\"1939\",\"entityType\":\"individual\"}]"
      • addedInput schema / properties / queries / items / properties / country / description
        Added value: +"Optional. ISO 3166-1 alpha-2 code (\"IR\") or English country name (\"Iran\"); adds country_match to each match (filters only with excludeNonMatchingCountry=true)"
      • addedInput schema / properties / queries / items / properties / dateOfBirth / description
        Added value: +"Optional. Format YYYY or YYYY-MM-DD, e.g. \"1939\" or \"1939-04-19\"; drops listed individuals whose birth year differs by more than 1 year"
      • addedInput schema / properties / queries / items / properties / entityType / description
        Added value: +"Optional, one of \"individual\" | \"entity\" | \"any\"; default = top-level entityType. \"entity\" = organisations, vessels, aircraft"
      • addedInput schema / properties / queries / items / properties / id / description
        Added value: +"Optional. Your own reference echoed in the output row, e.g. \"cust-42\""
      • addedInput schema / properties / queries / items / properties / name / description
        Added value: +"Required. Person or organisation name to screen (non-empty), e.g. \"Ali Khamenei\""
      • addedOutput schema / properties / count / description
        Added value: +"Number of rows in items"
  2. 2 tool updatesv0.1.0
    • First observedlist_sources
    • First observedscreen_names
Deploy Server
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

TDQS

A4.7/5.0

Scored across 2 tools

Disambiguation5/5

screen_names performs actual sanctions screening while list_sources only returns static metadata about the covered lists. The descriptions explicitly state when to use each and forbid using the other for the wrong task, so an agent can easily tell them apart.

Naming Consistency5/5

Both tools follow a clean verb_noun pattern in snake_case (screen_names, list_sources). There is no mixing of conventions or vague verbs.

Tool Count3/5

The server has only two tools, and while each earns its place (screen_names does the core work, list_sources supports it), the surface is thin for a screening service that could plausibly offer tools to inspect cache status or retrieve specific entry details. This is borderline per the rubric for 1-2 tools.

Completeness4/5

The core screening workflow is fully covered with rich parameters (names/queries, filters, minScore, list selection) and a helper for source metadata. Minor gaps exist, such as no tool to manage or inspect the Apify cache or fetch a single list entry outside of screening results, but these are workable.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers