Skip to main content
Glama

Fairquery Agent Trust & Data Safety

Screen names against OFAC/EU/UK/UN sanctions (paid)

sanctions_screen_names
Read-onlyIdempotent

WHAT: Runs the Fairquery Apify Actor sanctions-watchlist-screener: fuzzy-match people/organisations against OFAC SDN, OFAC Consolidated, EU, UK and UN lists from the official sources (re-downloaded when the cached copy in your Apify account is older than 6 h; every row reports each list's publication date); optional country/DOB filters. WHEN: KYC/KYB onboarding, vendor/counterparty checks, bulk re-screening. Put all names in ONE call (each call is one run with its own start fee; list loading takes ~2-5 s from the cache, or 10-40 s, up to ~60 s, when lists are re-downloaded). This Worker waits 20 s, so a re-download that runs longer returns APIFY_TIMEOUT. WHEN NOT: PEP/adverse media, certified compliance decisions. For coverage info use free sanctions_list_sources. Leads that also have an email to validate: trust_screen_lead (one merged decision). COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $3.00 per 1,000 names + $7.00 per 1,000 runs. 200 names in one call ~ $0.61. RETURNS: Paged "screening" rows (status potential_match | no_match, matches[] best first, lists_unavailable) or "error" rows. Tool errors: INPUT_EMPTY, APIFY_TOKEN_MISSING, APIFY_TOKEN_INVALID, APIFY_PAYMENT_REQUIRED, APIFY_ACTOR_RUN_FAILED, APIFY_TIMEOUT. Not a certified screening service. Automated fuzzy matching against public lists; false positives and misses are possible. Review every potential match manually and consult official sources/legal counsel before acting. BEHAVIOR: Results are stable for a given list snapshot. Called from this Fairquery-hosted Worker, which forwards your input and Apify token to Apify and waits 20 s (APIFY_TIMEOUT if the run has not finished). This Worker's code is designed not to store them. The Actor runs in your account. Up to 10,000 names. A list re-download can outlast the 20 s wait. PARAMETERS: names and/or queries: at least one non-empty (the schema marks both optional; neither -> INPUT_EMPTY, not billed). Both may be combined; every entry is billed once, so use names for bare strings and queries when you have country/dateOfBirth/entityType or want your own id echoed. In queries, dateOfBirth removes listed individuals born more than 1 year apart, while country never removes matches (it only sets country_match); entityType "entity" covers organisations, vessels and aircraft. lists: omit to screen all five; a list that cannot be downloaded is reported in lists_unavailable instead of failing the run. minScore: a match is returned only if its 0-100 similarity is >= minScore; 85 balances recall and noise, 90-95 for large batches, 75-80 for transliterated names; it does not change the price. maxMatchesPerName caps matches[] only; match_count still reports all matches. limit/offset only page the returned rows: every call screens and bills all names again (also when only offset changes), so set limit (max 1000) to cover all rows instead of paging. EXAMPLE: {"queries":[{"name":"Banco Nacional de Cuba","entityType":"entity"}],"minScore":90} -> status potential_match (OFAC_SDN).

Input Schema

NameRequiredDescriptionDefault
limitNoOptional page size: items to return, integer 1-1000 (default 100). Example: 50
listsNoOptional, default all five. Any subset of "OFAC_SDN" | "OFAC_CONS" | "EU" | "UK" | "UN" (ids from sanctions_list_sources). Example: ["OFAC_SDN","EU"]
namesNoOptional if queries is given (at least one is required). 0-10000 plain person/organisation names, 1-300 chars each. Example: ["Acme Trading LLC","Banco Nacional de Cuba"]
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100
queriesNoOptional if names is given. 0-10000 {name, id?, country?, dateOfBirth?, entityType?} objects. 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; 90+ = fewer false positives, ~80 = more recall. Example: 90
maxMatchesPerNameNoOptional integer 1-100, default 10. Max entries in matches[] per name (best first); match_count still reports the total. Example: 3

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context (summary counts, cost notes, ...)
countYesNumber of items in this page
itemsYesResult rows for this page
totalYesTotal items before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses paid Apify billing, token requirements, cache re-download timing, the 20 s Worker timeout, partial list failures via lists_unavailable, stable results per snapshot, and false-positive/miss limitations. It also states the Worker is designed not to store credentials/input.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the definition is front-loaded and organized under WHAT, WHEN, WHEN NOT, COST, RETURNS, BEHAVIOR, PARAMETERS, and EXAMPLE. Every section carries operational information needed to avoid incorrect or costly calls.

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 screening tool with seven parameters and an output schema, the description covers invocation rules, billing, authentication, timeouts, error codes, result stability, and compliance caveats. It is complete enough for an agent to call it correctly and interpret the risks.

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 already 100%, but the description adds important semantics: names vs queries billing, dateOfBirth filtering behavior, country never filtering matches, entityType meaning, minScore tuning guidance, maxMatchesPerName capping only matches[], and the critical limit/offset billing caveat.

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 first line states a specific verb and resource: runs fuzzy sanctions screening for people/organisations against OFAC SDN, OFAC Consolidated, EU, UK and UN lists. It explicitly distinguishes itself from nearby tools by naming sanctions_list_sources and trust_screen_lead.

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 section gives concrete use cases (KYC/KYB onboarding, vendor checks, bulk re-screening) and instructs putting all names in one call. The WHEN NOT section names alternatives for PEP/adverse media, list coverage, and email-bearing leads, leaving little to inference.

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