AI agents are good at reasoning and terrible at facts. Ask Claude whether "Rosoboronexport" appears on the EU Consolidated Sanctions List, under which programme, and since when, and it will give you a confident answer from its training data that may be months or years stale, or simply wrong. For an AML or compliance team with European exposure, "probably listed" is not an answer you can open an account or release a payment on. A missed match is a breach of EU restrictive measures; a false all-clear is an enforcement action.
In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that screens a name against the EU Consolidated Sanctions List, and turn "is this party sanctioned in the EU?" from a guess into a live lookup against the source of record. By the end you will have a working sanctions-screening tool that Claude, Cursor, or any MCP client can call during a conversation, and you will understand exactly where in the run the tool fires and what it returns.
Everything below is a real setup with real output. No mocked responses.
What is the Apify MCP server?
Model Context Protocol (MCP) is an open standard that lets AI clients call external tools. The Apify MCP server (https://mcp.apify.com) implements that standard on top of the Apify platform, which means every one of the thousands of Actors in the Apify Store becomes a tool an agent can invoke.
Why route an Actor through MCP instead of hard-coding an API call?
- The agent decides when to screen. Claude reads the conversation, notices a counterparty name it must verify, and calls the tool on its own. You do not write glue code for every question.
- Structured input and output. The MCP server hands Claude the Actor's input schema, so the model fills in the parameters correctly, and returns a clean dataset it can reason over.
-
One connection, many tools. The same MCP endpoint exposes
search-actors,fetch-actor-details, andcall-actor, so an agent can discover and run any Actor without new configuration. - No infrastructure. The server is hosted. You add a few lines to a config file and you are done.
The Actor we will use
We will expose the EU Consolidated Sanctions List Scraper (Persons & Entities). It screens a name against the EU Consolidated Sanctions List and returns the full match record: the listed party's primary name, whether it is a person or an enterprise, the sanctions programme and the legal basis (the EU regulation that imposed the measure), all known aliases, the EU reference number, the designation and publication dates, addresses, nationalities, birth details for individuals, and registration or tax identifiers.
That field set is exactly what an AML, KYC, or payments-screening check with EU exposure needs. The EU Consolidated list is the authoritative record of everyone subject to EU financial restrictive measures: any funds or economic resources belonging to a listed party must be frozen, and screening against it is public, authoritative, and mandatory for regulated institutions operating in or with the European Union. It is the natural counterpart to the U.S. OFAC list for any book with both American and European exposure.
Step 1: Get your Apify API token
Sign in to the Apify Console, open Settings → Integrations, and copy your personal API token. The MCP server uses it to authenticate and to bill Actor runs to your account.
📌 Note: the token is a secret. Keep it in the client config only, never in a prompt or a committed file.
Step 2: Point Claude Desktop at the Apify MCP server
Open Claude Desktop's config file (Settings → Developer → Edit Config, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the Apify server. The tools query parameter is the important part: it tells the server which Actor to expose, so Claude gets one focused tool instead of the entire Store.
{
"mcpServers": {
"apify": {
"url": "https://mcp.apify.com?tools=scrapers_lat/eu-sanctions-list-scraper",
"headers": {
"Authorization": "Bearer YOUR_APIFY_TOKEN"
}
}
}
}
Cursor uses the same JSON in .cursor/mcp.json. If you prefer to run it locally over stdio instead of the hosted endpoint:
{
"mcpServers": {
"apify": {
"command": "npx",
"args": ["-y", "@apify/actors-mcp-server", "--tools", "scrapers_lat/eu-sanctions-list-scraper"],
"env": { "APIFY_TOKEN": "YOUR_APIFY_TOKEN" }
}
}
}
Restart Claude Desktop so it picks up the new server.
Step 3: Confirm the tool is loaded
After the restart, the Actor shows up as a callable tool. If you list the tools the Apify server exposes, you will see the storage helpers plus the Actor itself, named after its Store handle:
get-actor-run, get-dataset-items, get-key-value-store-record,
abort-actor-run, scrapers_lat--eu-sanctions-list-scraper
That last entry, scrapers_lat--eu-sanctions-list-scraper, is our screening tool. Claude now knows it exists, what it does (from the Actor's README), and what inputs it takes (from the input schema the server passes along).
Step 4: Ask Claude to screen a counterparty
Now the payoff. In a normal chat, ask a question that requires ground truth:
"We are onboarding a supplier in the EU and the counterparty is Rosoboronexport. Screen that name against the EU Consolidated Sanctions List before we open the account."
Claude recognizes it cannot answer this reliably from memory, selects the EU sanctions tool, and fills in the input from your question. Under the hood the client sends a tools/call with the Actor's parameters:
{
"name": "scrapers_lat--eu-sanctions-list-scraper",
"arguments": {
"nameQuery": "Rosoboronexport",
"subjectType": "all",
"maxEntries": 50
}
}
The Apify MCP server starts the Actor, waits for it to finish, and returns the dataset. Here is the real run metadata it produced:
{
"runId": "Ple1v3yZc2MAm5W9A",
"actorName": "scrapers_lat/eu-sanctions-list-scraper",
"status": "SUCCEEDED",
"matchCount": 1
}
One EU match, live against the Consolidated Sanctions List.
Step 5: Read the real output
The dataset the tool returns is structured sanctions data. This is an actual record from the run (trimmed to the fields that matter for screening):
{
"primaryName": "AO Рособоронэкспорт",
"subjectType": "enterprise",
"aliases": ["Rosoboroneksport", "JSC ROSOBORONEXPORT"],
"programme": "UKR",
"regulationType": "amendment",
"regulationNumberTitle": "2023/571 (OJ L75 I)",
"organisationType": "council",
"euReferenceNumber": "EU.7808.66",
"designationDate": "2022-03-15",
"addressCity": "Moscow",
"addressCountry": "RUSSIAN FEDERATION",
"idNumber": "7718852163",
"idType": "National Fiscal Code",
"publicationUrl": "https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32023R0571",
"source": "EU Consolidated Financial Sanctions List"
}
Claude reads that and answers in plain language: the party is a positive match on the EU list. The listed party is AO Рособоронэкспорт, an enterprise (not an individual), designated on 2022-03-15 under the UKR programme through Regulation 2023/571 (OJ L75 I), a Council designation. It also trades under the aliases Rosoboroneksport and JSC ROSOBORONEXPORT, it is based in Moscow, Russian Federation, and it carries EU reference EU.7808.66 and tax ID 7718852163. The agent's verdict: do not open the account. Every one of those facts is traceable to the official EU record, not the model's memory, and the agent can attach the EUR-Lex regulation link as the documented legal basis for the block.
The counter-example is just as important. Screen an ordinary, clean counterparty name and the same tool returns zero matches, a clear pass. That negative result is not a non-answer; it is the documented evidence a compliance file needs to show the party was screened and cleared on a specific date. An agent that can distinguish "matched, block it" from "screened, no hits, proceed" gives you both halves of the control. The model alone can produce neither with authority.
A real use case: an EU-facing onboarding and screening agent
Put this in context. A compliance or payments team that touches EU customers or suppliers must screen every new counterparty at onboarding and every payee before funds move. The obligation is absolute: if a name matches the EU Consolidated list, the assets are frozen and the case is reported. The work is high-volume, repetitive, and unforgiving of a miss, and a European alias or a Cyrillic legal name is exactly the kind of match a rushed manual search skips.
Without a tool, an analyst opens the EU sanctions map or portal, types each name, reads the results, judges whether a fuzzy alias is the same party, and pastes the outcome into a case file, once per counterparty, all day. With the tool wired into Claude, the analyst drops the day's list into the chat and asks the agent to screen each name. Claude calls the Actor per counterparty, and for every hit it returns the primary name, the sanctions programme, the regulationNumberTitle legal basis, the aliases, and the reference and identifiers, then flags the party as blocked with that evidence attached. Clean names come back as documented passes. The mechanical lookup disappears; the escalation decision on a borderline match stays with the human.
This is the shape of every good agent tool: it removes the mechanical fetch, not the decision.
Going further: chain a second tool
Sanctions screening rarely stops at one list. A firm with both U.S. and EU exposure has to clear a counterparty against the U.S. OFAC SDN list and the EU Consolidated list, because a party can be listed in one jurisdiction and not the other. The same MCP connection can expose more Actors by extending the tools parameter:
https://mcp.apify.com?tools=scrapers_lat/eu-sanctions-list-scraper,scrapers_lat/ofac-sanctions-scraper
Now the agent can screen a counterparty against the EU Consolidated Sanctions List and the U.S. Treasury OFAC SDN list in the same conversation, then combine both results into one screening summary that covers both jurisdictions. Because each Actor is a separate tool, the agent picks the right one for each step, runs both, and reports a party that is clean on one list but flagged on the other, on its own. For an AML team that owes dual-jurisdiction coverage, that is the whole check in a single prompt.
🏹 Troubleshooting: if the tool does not appear in Claude, the two usual causes are a missing or misspelled Actor handle in the tools parameter (it must be the exact username/actor-name from the Store URL) and a config that was edited while Claude was running. Fix the handle, save, and fully restart the client.
📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). For one-off screening the cost is a fraction of a cent; if you need to screen thousands of names on a schedule or rescreen your whole book against list updates, run the Actor directly through the Apify API or a scheduled task instead of one call per chat message.
Wrapping up
You now have an AI agent that can screen any counterparty against the EU Consolidated Sanctions List, on demand, mid-conversation, and return the programme, legal basis, aliases, and evidence an AML decision actually needs, plus a documented clean pass when there is no match. The pattern is reusable: pick an Actor that returns authoritative structured data, expose it through the Apify MCP server with the tools parameter, and let the agent decide when to call it.
To take it further:
- Add the U.S. OFAC SDN list, UK OFSI, or a company-registry Actor to build a full onboarding-and-screening compliance agent that covers every jurisdiction you touch.
- Screen not just the counterparty but its beneficial owners and officers in the same conversation.
- Read the Apify MCP server docs for OAuth setup, resource reads, and the
search-actors/call-actortools that let an agent discover Actors it was not preconfigured with.
The Actor used in this guide: EU Consolidated Sanctions List Scraper (Persons & Entities).
Top comments (0)