fairquery-agent-trust-mcp

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

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

sanctions_screen_names

Read-onlyIdempotent

Screen people and organisations against OFAC, EU, UK, and UN sanctions lists with fuzzy matching to flag potential matches for KYC/KYB onboarding, vendor checks, and bulk re-screening.

Instructions

WHAT: Runs the Fairquery Apify Actor sanctions-watchlist-screener: fuzzy-match people/organisations against OFAC SDN, OFAC Consolidated, EU, UK and UN lists downloaded fresh from official sources each run; optional country/DOB filters. WHEN: KYC/KYB onboarding, vendor/counterparty checks, bulk re-screening. Put all names in ONE call (lists download once per run, ~10-40 s). WHEN NOT: PEP/adverse media, certified compliance decisions. For coverage info use free sanctions_list_sources. COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $0.005 per name screened. 200 names ~ $1.00. RETURNS: Paged rows type="screening" (query, status potential_match|no_match, best_score, match_count, matches[] with list/programs/countries/score, lists_screened, lists_unavailable, disclaimer) or type="error". 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: Read-only, no side effects, idempotent for a given list snapshot. Makes network calls: runs an Apify Actor billed to your APIFY_TOKEN; latency seconds to minutes (300 s timeout). Up to 10,000 names. PARAMETERS: names = plain names, or queries = names with country/dateOfBirth/entityType filters (one required); lists = subset of OFAC_SDN, OFAC_CONS, EU, UK, UN (default all); minScore = fuzzy-match threshold 60-100, higher = fewer false positives (default 85); maxMatchesPerName = top matches per name (default 10); limit = page size (default 100, max 1000); offset = items to skip for paging (default 0). EXAMPLE: {"queries":[{"name":"Banco Nacional de Cuba","entityType":"entity"}],"minScore":90} -> status potential_match (OFAC_SDN).

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size: items to return, integer 1-1000 (default 100)
`lists`	No	Subset of OFAC_SDN, OFAC_CONS, EU, UK, UN (default all five)
`names`	No	Plain names, e.g. ["Acme Trading LLC"]. Optional if queries given
`offset`	No	Items to skip for paging, integer >= 0 (default 0); pass nextOffset from the previous response
`queries`	No	Names with per-name filters. Optional if names given
`minScore`	No	Fuzzy threshold 60-100 (default 85; 90+ fewer false positives)
`maxMatchesPerName`	No	Top matches per name 1-100 (default 10)

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	No	Tool-specific context (summary counts, cost notes, ...)
`count`	Yes	Number of items in this page
`items`	Yes	Result rows for this page
`total`	Yes	Total items before paging
`offset`	Yes	Offset of the first item in this page
`hasMore`	Yes	True if more items exist after this page
`nextOffset`	Yes	Offset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds substantial context beyond them: paid billing to the caller's APIFY_TOKEN at $0.005/name, 10-40 s list download and 300 s timeout, a full list of error codes, and the false-positive/miss disclaimer. It also notes idempotence is per list snapshot, which sharpens the annotation's claim.

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?

The WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR ordering is strongly front-loaded and scannable, with cost and latency surfaced early. The PARAMETERS block largely duplicates the schema's own descriptions, which is the one section that doesn't fully earn its space.

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, network-bound, 7-parameter screening tool this is complete: cost, latency, limits (up to 10,000 names), auth failure modes, and result shape are all covered, and an output schema exists so return-field details are not owed by the description. An agent has everything needed to call it correctly and to set caller expectations.

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 baseline is 3, but the description adds real information the schema lacks: the top-level schema has no required fields, and only the description states that names or queries is 'one required'. The worked EXAMPLE with minScore=90 and entityType also clarifies intent. It mostly paraphrases the remaining defaults, so not a 5.

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 opens with a specific verb+resource ('Runs the ... sanctions-watchlist-screener: fuzzy-match people/organisations against OFAC SDN, OFAC Consolidated, EU, UK and UN lists') and names the exact watchlists, so the scope is unambiguous. It also distinguishes itself from the sibling sanctions_list_sources by casting that tool as the free coverage-info alternative.

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 (KYC/KYB onboarding, vendor/counterparty checks, bulk re-screening) and WHEN NOT (PEP/adverse media, certified compliance decisions) sections, plus a routing hint to the free sanctions_list_sources tool. It even states the batching rule ('Put all names in ONE call') and why (lists download once per run).

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

Deploy Server