Screen names and addresses on US, UN, EU, UK and other sanctions and export-control lists. Free.
Scored across 5 tools
fetch and list_sanctions_sources are clearly distinct reference tools, and screen_address targets addresses rather than names. However search and screen_entity overlap heavily—both search person/company names against the same 14 lists—so an agent may misselect despite subtle differences in output detail and rate limits.
screen_address, screen_entity, and list_sanctions_sources follow a verb_noun pattern, but fetch and search are bare verbs with no explicit object. The set remains readable but does not use a consistent naming convention throughout.
Five tools is well-scoped for a sanctions screening service: one entry lookup, one list-metadata tool, and three screening/search operations. Neither over-built nor thin for the domain.
The surface covers name screening, address screening, free-text search, entry detail retrieval, and list metadata, including list-selection arguments on the screening tools. Minor gaps remain, such as batch or transaction-level screening, but core screening workflows are covered.
One listed entry, by the id a search result gave: its name, list, program, entry type, up to 5 aliases and 3 locations, and when the list was last updated. Free, no account, 200 lookups a day from each internet address.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id of a search result. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description goes well beyond them with access and quota facts an agent needs: free, no account, 200 lookups per day per internet address. It also discloses result truncation (up to 5 aliases, 3 locations), warning that the record may be partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned before the operational constraints. Every clause carries distinct information: identity, field inventory, truncation caps, and quota.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no prose, yet the description flags the aliases/locations caps that the schema alone would not surface. Combined with the auth and rate-limit context, an agent has everything needed to call this correctly and plan around the quota.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter at 100% schema coverage, so the baseline is 3. The description restates the schema's own wording ('the id a search result gave' vs 'The id of a search result') without adding format, casing, or sourcing detail beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific retrieval action and resource: one sanctions list entry, fetched by the id a search result returned, with the exact fields it carries. This separates it from search (which produces the id) and from the screening siblings, though the differentiation from screen_entity/screen_address is implied rather than stated and the bare name 'fetch' adds nothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'by the id a search result gave' establishes the precondition clearly: this is a follow-up to a search, not a discovery tool. It gives no explicit exclusions (e.g. when to prefer screen_entity instead), so it lands short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every list OFACScreen screens against, each with its code (the value the lists argument of screen_entity and screen_address takes), its name and issuing authority, whether it is core (searched when a screening names no lists), when it was last updated and how many entries it holds. Calling this tool is free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| lists | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive, non-open-world call, so the safety profile is covered. The description adds genuinely new behavioral context in 'Calling this tool is free' (no credit/billing cost) and in explaining the semantics of the core flag, which is operational knowledge not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and then a tight clause listing each returned field; the closing sentence about cost is short and purposeful. The first sentence is dense, packing six field descriptions into one clause chain, but every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description still supplies the cross-tool meaning of the two fields an agent must act on (code for the lists argument, core for default screening). For a zero-parameter, read-only discovery tool this leaves nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4 with no schema-level parameter semantics to extend. The description correctly adds no parameter details and instead spends its words on output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete resource (every sanctions list screened against) and enumerates exactly what each entry carries: code, name, issuing authority, core flag, last-updated date, and entry count. It also ties the resource to the sibling tools screen_entity and screen_address, so an agent can distinguish this discovery tool from the screening tools without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong contextual guidance: it explains that 'code' is the value the lists argument of screen_entity and screen_address takes, and that 'core' lists are the ones searched when a screening names no lists — effectively telling the agent when this tool is needed. It stops short of an explicit 'call this first to resolve list codes before screening' instruction, so it is clear context rather than a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a street address against the addresses recorded on 14 sanctions and export-control lists: OFAC SDN, OFAC Non-SDN, EU Financial Sanctions, UN Security Council, UK Sanctions List, Canada SEMA, Swiss SECO, Australia DFAT, BIS Denied Persons, BIS Entity List, BIS Unverified List, BIS Military End-User, ITAR Debarred and State Nonproliferation. Returns the number of listed parties whose recorded address resembles it and the ten highest scoring, each with matched_address (the listed address it matched on), its score, list and program, plus jurisdiction_flags: an embargoed or high-risk country or region the address points to. A jurisdiction flag says where, not who: it is not a sanctions match and never counts as one. The lists record addresses for only some of the parties on them, so no match clears no one at the address: screen their names with screen_entity too. The address must name a street or a building, e.g. "Tverskaya 7, Moscow"; a city or a country alone is refused. Free, no account, 25 screenings a day from each internet address, shared by screen_entity and screen_address; in ChatGPT, each user has their own 25. A screening is not recorded and produces no document: its report_url opens the same search on ofacscreen.com, where a timestamped PDF record of it can be bought. The price is in report_price. Calling this tool is free. Searched only when named in lists: UAE Local Terrorist List, UFLPA Entity List, FBI Most Wanted, FinCEN Special Measures, France Registre des gels, Israel NBCTF crypto wallets, Japan MOF, Mexico SAT 69-B, Poland MSWiA.
| Name | Required | Description | Default |
|---|---|---|---|
| lists | No | List codes to search instead of the default 14. Omit to search the default lists. | |
| address | Yes | The street address to screen: the street and number or the building, with the city and country if known, e.g. "Tverskaya 7, Moscow, Russia". Up to 300 characters. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| query | Yes | |
| results | Yes | |
| contacts | No | |
| report_url | Yes | |
| match_found | Yes | |
| screened_at | No | |
| report_price | Yes | |
| results_count | Yes | |
| results_shown | No | |
| lists_screened | No | |
| contact_matches | No | |
| is_audit_record | No | |
| lists_refreshed | No | |
| place_data_credit | No | |
| results_truncated | No | |
| jurisdiction_flags | Yes | |
| results_count_is_capped | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations: it discloses the daily quota (25, shared with screen_entity), that screenings are not recorded and produce no document, that report_url is an external paid search with price in report_price, and that jurisdiction_flags indicate location and never count as a sanctions match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, scope and the key caveat, and most sentences carry unique information. It is dense and the inline enumeration of all 14 lists plus the trailing 'searched only when named' sentence make it longer than ideal, but nothing is truly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description still usefully explains the shape of the key return fields (matched_address, score, list/program, jurisdiction_flags) and their semantics. Quota, refusal conditions, caveats and the name-screening alternative are all covered, leaving no gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning: it enumerates the default 14 lists and explains that the remaining lists (UAE, UFLPA, FBI, FinCEN, etc.) are searched only when explicitly named via the lists parameter. It also gives an address format example and the street-or-building constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Screen a street address') and names the exact scope: 14 enumerated sanctions and export-control lists. It clearly separates itself from the sibling screen_entity by stating this tool screens addresses while names go to screen_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance ('the address must name a street or a building... a city or a country alone is refused'), routes name screening to screen_entity, and documents the shared 25/day rate limit. The condition selecting the alternative tool is stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a person or company name against 14 sanctions and export-control lists: OFAC SDN, OFAC Non-SDN, EU Financial Sanctions, UN Security Council, UK Sanctions List, Canada SEMA, Swiss SECO, Australia DFAT, BIS Denied Persons, BIS Entity List, BIS Unverified List, BIS Military End-User, ITAR Debarred and State Nonproliferation. Fuzzy name matching, so transliterations and spelling variants still surface. Returns the number of potential matches and the ten highest scoring, each with its score, list, program, aliases and addresses. A score is name similarity, not a finding that a match is the same party: confirm a date of birth, an address or an ID document before acting on it. Free, no account, 25 screenings a day from each internet address, shared by screen_entity and screen_address; in ChatGPT, each user has their own 25. A screening is not recorded and produces no document: its report_url opens the same search on ofacscreen.com, where a timestamped PDF record of it can be bought. The price is in report_price. Calling this tool is free. Searched only when named in lists: UAE Local Terrorist List, UFLPA Entity List, FBI Most Wanted, FinCEN Special Measures, France Registre des gels, Israel NBCTF crypto wallets, Japan MOF, Mexico SAT 69-B, Poland MSWiA.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the person or entity to screen, e.g. "Vladimir Petrov" or "Acme Trading LLC". Up to 300 characters. | |
| No | The party's email address, checked against the ones the lists record. Optional; up to 5 separated by commas or semicolons. | ||
| lists | No | List codes to search instead of the default 14. Omit to search the default lists. | |
| phone | No | The party's phone number, checked against the ones the lists record. Optional; up to 5 separated by commas or semicolons. | |
| website | No | The party's website, checked against the ones the lists record. Optional; up to 5 separated by commas or semicolons. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| contacts | No | |
| report_url | Yes | |
| match_found | Yes | |
| screened_at | No | |
| report_price | Yes | |
| results_count | Yes | |
| results_shown | No | |
| lists_screened | No | |
| contact_matches | No | |
| is_audit_record | No | |
| lists_refreshed | No | |
| results_truncated | No | |
| results_count_is_capped | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/idempotent annotations: discloses fuzzy matching behavior, the exact result shape (count plus top ten with score, list, program, aliases, addresses), the crucial caveat that a score is name similarity not a party match, that nothing is recorded, and that report_url is an upsell with a price. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the match-score caveat are front-loaded, which is good, but the block is long and repeats the free-of-charge message ('Free, no account, 25 screenings a day…' followed later by 'Calling this tool is free.') and splits the report_url/report_price explanation across two sentences that could be one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a screening tool with an output schema already defining return values, the description still covers cost, quota, non-recording, match-scoring caveats and list defaults. Nothing an agent needs to call this safely and correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning the schema cannot: it names which 14 lists are the default for the omitted lists parameter and explains that nine further lists (UAE, UFLPA, FBI, FinCEN, France, Israel, Japan, Mexico, Poland) are only searched when explicitly named in the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('screen') plus resource ('a person or company name') and an enumerated set of 14 named lists, so the agent knows exactly what is queried. The name-vs-address distinction against the sibling screen_address is implicit in the wording 'person or company name' but the tool is still unambiguously identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the operating envelope clearly: free, no account, 25 screenings/day per IP, shared between screen_entity and screen_address, and per-user quota in ChatGPT. It does not explicitly say 'use screen_address for addresses instead' nor point to list_sanctions_sources for discovering list codes, so routing guidance is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 14 sanctions and export-control lists for a person or company name. Returns up to 10 listed entries, closest match first, each with an id for fetch and a link to cite. A result is name similarity, not a finding that it is the same party, and an empty result does not clear the name. Free, no account, 100 searches a day from each internet address.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A person or company name, e.g. "Acme Trading LLC". Up to 300 characters. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses the result cap (up to 10), ordering (closest match first), the presence of an id for follow-up fetch and a citation link, the critical semantics that a hit is name similarity and not an identity match, that a miss is not a clearance, and the operational profile (free, no account, 100 searches/day per internet address). This is exactly the context an agent needs to interpret and call the tool responsibly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with no filler; purpose is front-loaded and the result/limit caveats follow in a sensible order. Dense but every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape explanation is optional, yet the description still summarizes results usefully. Combined with rate limits, result semantics, and the fetch linkage, the definition is nearly self-sufficient; the only real gap is sibling disambiguation against screen_entity and screen_address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single query parameter is fully documented in the schema with length and an example, so the schema already carries the burden. The description restates 'person or company name' but adds no syntax or format detail beyond what is structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope ('Search the 14 sanctions and export-control lists for a person or company name'), and hints at the fetch sibling via the returned id. It does not, however, distinguish itself from screen_entity or screen_address, which are the most confusable siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (quick name lookup against sanctions lists) and the description adds useful interpretive cautions ('a result is name similarity, not a finding that it is the same party', 'an empty result does not clear the name'). But it never says when to prefer search over screen_entity, screen_address, or list_sanctions_sources, leaving the routing choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchlist_sanctions_sourcesscreen_address2 fields changedOutput schema / properties / contact_matchesAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / contactsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}screen_entity5 fields changedInput schema / properties / emailAdded value: +{
+ "description": "The party's email address, checked against the ones the lists record. Optional; up to 5 separated by commas or semicolons.",
+ "maxLength": 300,
+ "type": "string"
+}Input schema / properties / phoneAdded value: +{
+ "description": "The party's phone number, checked against the ones the lists record. Optional; up to 5 separated by commas or semicolons.",
+ "maxLength": 300,
+ "type": "string"
+}Input schema / properties / websiteAdded value: +{
+ "description": "The party's website, checked against the ones the lists record. Optional; up to 5 separated by commas or semicolons.",
+ "maxLength": 300,
+ "type": "string"
+}Output schema / properties / contact_matchesAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / contactsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}searchscreen_addressscreen_entity1 field changedInput schema / properties / lists / items / enumPrevious value: -[
- "AE_EOCN",
- "AU_DFAT",
- "BIS_DPL",
- "BIS_EL",
- "BIS_MEU",
- "BIS_UVL",
- "CANADA_SEMA",
- "EU_FSF",
- "FBI_WANTED",
- "FR_GELS",
- "JP_MOF",
- "MX_SAT_69B",
- "OFAC_NONSDN",
- "OFAC_SDN",
- "PL_MSWIA",
- "STATE_DTC",
- "STATE_ISN",
- "SWISS_SECO",
- "UK_SANCTIONS",
- "UN_CONSOLIDATED"
-]New value: +[
+ "AE_EOCN",
+ "AU_DFAT",
+ "BIS_DPL",
+ "BIS_EL",
+ "BIS_MEU",
+ "BIS_UVL",
+ "CANADA_SEMA",
+ "DHS_UFLPA",
+ "EU_FSF",
+ "FBI_WANTED",
+ "FINCEN_311",
+ "FR_GELS",
+ "IL_NBCTF",
+ "JP_MOF",
+ "MX_SAT_69B",
+ "OFAC_NONSDN",
+ "OFAC_SDN",
+ "PL_MSWIA",
+ "STATE_DTC",
+ "STATE_ISN",
+ "SWISS_SECO",
+ "UK_SANCTIONS",
+ "UN_CONSOLIDATED"
+]screen_entity1 field changedInput schema / properties / lists / items / enumPrevious value: -[
- "AU_DFAT",
- "BIS_DPL",
- "BIS_EL",
- "BIS_MEU",
- "BIS_UVL",
- "CANADA_SEMA",
- "EU_FSF",
- "FBI_WANTED",
- "JP_MOF",
- "MX_SAT_69B",
- "OFAC_NONSDN",
- "OFAC_SDN",
- "STATE_DTC",
- "STATE_ISN",
- "SWISS_SECO",
- "UK_SANCTIONS",
- "UN_CONSOLIDATED"
-]New value: +[
+ "AE_EOCN",
+ "AU_DFAT",
+ "BIS_DPL",
+ "BIS_EL",
+ "BIS_MEU",
+ "BIS_UVL",
+ "CANADA_SEMA",
+ "EU_FSF",
+ "FBI_WANTED",
+ "FR_GELS",
+ "JP_MOF",
+ "MX_SAT_69B",
+ "OFAC_NONSDN",
+ "OFAC_SDN",
+ "PL_MSWIA",
+ "STATE_DTC",
+ "STATE_ISN",
+ "SWISS_SECO",
+ "UK_SANCTIONS",
+ "UN_CONSOLIDATED"
+]screen_entity1 field changedInput schema / properties / listsAdded value: +{
+ "description": "List codes to search instead of the default 14. Omit to search the default lists.",
+ "items": {
+ "enum": [
+ "AU_DFAT",
+ "BIS_DPL",
+ "BIS_EL",
+ "BIS_MEU",
+ "BIS_UVL",
+ "CANADA_SEMA",
+ "EU_FSF",
+ "FBI_WANTED",
+ "JP_MOF",
+ "MX_SAT_69B",
+ "OFAC_NONSDN",
+ "OFAC_SDN",
+ "STATE_DTC",
+ "STATE_ISN",
+ "SWISS_SECO",
+ "UK_SANCTIONS",
+ "UN_CONSOLIDATED"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}screen_entity1 field changedOutput schema / properties / results / items / properties / matched_identifierAdded value: +{
+ "type": "boolean"
+}screen_entity13 fields changedInput schema / properties / entity_typeRemoved value: -{
- "description": "Optional filter: restrict matches to individuals or to entities/organizations. Omit to search both.",
- "enum": [
- "individual",
- "entity"
- ],
- "type": "string"
-}Input schema / properties / name / descriptionPrevious value: -"Full name of the person or entity to screen, e.g. \"Vladimir Petrov\" or \"Acme Trading LLC\"."New value: +"Full name of the person or entity to screen, e.g. \"Vladimir Petrov\" or \"Acme Trading LLC\". Up to 300 characters."Input schema / properties / name / maxLengthAdded value: +300Output schema / properties / is_audit_recordAdded value: +{
+ "type": "boolean"
+}Output schema / properties / lists_refreshedAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / lists_screenedAdded value: +{
+ "type": "integer"
+}Output schema / properties / results / items / properties / addresses_totalAdded value: +{
+ "type": "integer"
+}Output schema / properties / results / items / properties / aliases_totalAdded value: +{
+ "type": "integer"
+}Output schema / properties / results / items / properties / matched_alias / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results_count_is_cappedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / results_shownAdded value: +{
+ "type": "integer"
+}Output schema / properties / results_truncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / screened_atAdded value: +{
+ "type": "string"
+}screen_entityScreen names against OFAC, EU, UK, UN sanctions lists; resolve entities via GLEIF. Screening aid.
Fuzzy-screen people and company names against OFAC SDN, EU, UK and UN sanctions lists.
Screen a name or entity against OFAC SDN, the EU Consolidated list and the UK list.
Screen people & companies against 12 US sanctions & exclusion lists (OFAC, LEIE, SAM, Medicaid).
Add one secure layer between your agents and this server.
