Adding sanctions screening to your AI agent with MCP

AI agents are increasingly doing work that used to require a human clicking through a compliance dashboard — vendor onboarding, customer due diligence, procurement approval, even autonomous payment workflows. Any of those tasks can involve a counterparty that turns out to be sanctioned, which means an agent doing this work responsibly needs the same capability a human compliance analyst has: the ability to check a name against the official sanctions lists before acting.

Why this is a tool-calling problem, not a prompting problem

It's tempting to just ask a language model "is this name sanctioned?" and trust whatever it says. This doesn't work reliably: a model's training data has a cutoff, sanctions lists change weekly, and there's no way to verify or cite where an answer came from. Sanctions screening needs to be a real tool call against a live, current dataset — not a recalled fact — with a structured, citable result the agent (and whoever reviews its decisions later) can trust.

This is exactly the kind of capability the Model Context Protocol (MCP) was built for: giving an agent a well-defined tool it can call, with a typed request and a structured, inspectable response, rather than relying on free-text reasoning about something it can't actually verify.

What an MCP-based screening tool looks like

Conceptually, an MCP sanctions-screening tool takes a name (and optionally a date of birth, nationality, and entity type) and returns a structured result: a match band (clear / possible match / match), a numeric score, and, for any hit, the matched entity's primary name, source list, sanctions program, and a citation back to the source entry. The agent gets back something it can reason over and quote — not a paragraph it has to interpret.

Conceptual example: calling the API directly

Before wiring up MCP, the same capability is available as a plain REST call — useful for understanding the shape of the data an agent will be working with:

curl https://screen100.com/api/v1/screen \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Ramzan Kadyrov",
    "type": "individual"
  }'

{
  "result": "match",
  "top_score": 0.97,
  "hits": [{
    "primary_name": "KADYROV, Ramzan Akhmadovich",
    "source": "OFAC_SDN",
    "programs": ["MAGNIT", "UKRAINE-EO13661"],
    "score": 0.97
  }]
}

Conceptual example: an agent calling it as an MCP tool

Wired up as an MCP tool, an agent framework sees a callable tool roughly shaped like this — the agent decides when to invoke it based on the task, rather than a developer hard-coding the call site:

// Tool definition exposed to the agent via the Screen100 MCP server
{
  "name": "screen_sanctions",
  "description": "Screen a person or company name against the OFAC SDN, OFAC Consolidated and UN Security Council sanctions lists.",
  "input_schema": {
    "name": "string",
    "type": "individual | organization",
    "date_of_birth": "string (optional)",
    "nationality": "string (optional)"
  }
}

// The agent's own reasoning, at the point it decides to call the tool:
// "Before approving this vendor, I should screen '{vendor_name}'
//  against sanctions lists using the screen_sanctions tool."

// Tool result returned to the agent's context:
{
  "result": "clear",
  "top_score": 0.12,
  "list_version": "2026-07-06",
  "hits": []
}

The agent can now condition its next action on a structured, cited result — proceed with onboarding on a Clear result, pause and flag a human reviewer on a Match, or ask a follow-up question with more identifying detail on a Possible match — instead of guessing or, worse, skipping the check entirely because it has no reliable way to perform one.

Why the result needs to be citable

An agent's decisions increasingly need to be auditable after the fact, especially in a compliance-adjacent workflow. A screening tool that returns "matched OFAC_SDN entry, program UKRAINE-EO13661, score 0.97, list version 2026-07-06" gives you something to point to later. A tool — or a language model's unaided guess — that just says "this looks sanctioned" gives you nothing to stand behind if the decision is ever questioned. This is the same reasoning behind our developer's guide to the sanctions screening API: cited, structured results over free-text guesses.

Getting started

Screen100 exposes the same screening engine both ways: a single-key REST API for direct integration, and a hosted MCP server for agent frameworks that support MCP tool calling — so a human-built workflow and an autonomous agent get identical, cited results from the same underlying data. Both are available on every plan, with a small free quota to test against before moving to production volume. See the API reference and MCP setup docs to get a key.