Apify Public Data & Leads

OFAC Sanctions Search

ofac_sanctions_search

Read-only

Search U.S. Treasury OFAC SDN and non-SDN records by name, alias, program, country, or entity type. Return sanctions programs, aliases, addresses, and source IDs for list reconciliation.

Instructions

Search official US Treasury OFAC SDN and consolidated non-SDN data by primary name, alias, program, country and entity type. Returns sanctions programs, aliases, addresses and source identifiers.

Behavioral Transparency:

Execution: Network call executed synchronously in the cloud via Apify Actor 'captainhandsome/ofac-sanctions-search'.
Side Effects: Reads public sources and creates a billed Actor run and dataset on your Apify account.
Authentication: Requires APIFY_TOKEN environment variable.
Latency & Limits: Typical run duration is 10-40 seconds; results are exact source matches, not fuzzy compliance screening scores.

Usage Guidelines:

When to use: Use for research, list reconciliation, sanctions-data enrichment and exact/substring name discovery.
When NOT to use: Do not treat a name match as a legal compliance determination; do not use for corporate filings (use 'sec_edgar_filings') or entity-registration verification (use 'us_business_entity_search').
Named alternatives: Use 'sec_edgar_filings' for US public-company filings, 'gleif_lei_search' for legal-entity identifiers, or 'us_business_entity_search' for state registrations.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Case-insensitive primary name or alias to search.
`country`	No	Optional country filter across addresses and vessel flag.
`program`	No	Optional OFAC sanctions program code.
`list_scope`	No	Search SDN, consolidated non-SDN, or both.	all
`match_mode`	No	Substring discovery or exact normalized matching.	contains
`entity_type`	No	Optional party type such as individual, entity, vessel or aircraft.
`max_results`	No	Maximum sanctions records to return.
`include_aliases`	No	Match the query against alternate names as well as primary names.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`run`	No
`error`	No
`status`	Yes
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Sep 15, 2026
Removedv1.1.0Sep 15, 2026
Addedv1.0.13Sep 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/destructive annotations, the description discloses a billed Actor run, required APIFY_TOKEN environment variable, typical 10-40 second latency, exact-match behavior vs fuzzy screening, and the side effect of creating a run/dataset on the user's Apify account. This is far richer than the annotations alone and fully informs the agent of real-world consequences.

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?

The description is well-structured with clear sections for behavioral transparency and usage guidelines. The core purpose is front-loaded, and every sentence provides actionable information with no filler. The length is justified by the tool's complexity and side-effect profile.

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?

The description covers execution model, side effects, authentication, latency, result semantics, and explicit alternatives. An output schema exists, and annotations cover safety hints, so nothing critical is missing for an agent to decide when and how to invoke this tool.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already has a meaningful description, so the baseline is 3. The tool description restates some parameter concepts (name, alias, program, country, entity type) but does not add new semantic detail beyond what the schema already provides.

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 names a specific resource ('official US Treasury OFAC SDN and consolidated non-SDN data'), a precise verb ('search'), and the key query dimensions (primary name, alias, program, country, entity type). It also states what is returned, which clearly separates it from sibling search tools without needing to inspect schemas.

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 description explicitly states when to use the tool (research, list reconciliation, name discovery) and when not to use it, including named alternatives like sec_edgar_filings, gleif_lei_search, and us_business_entity_search. This is exactly the guidance an agent needs to route correctly.

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

Deploy Server