OFAC and global sanctions screening: crypto addresses, emails, websites, IDs, countries, VPN, geo
Scored across 8 tools
Each screen_* tool targets a distinct entity type (country, crypto address, email, government ID, PEP name, website), so misselection is unlikely. The only mild overlap is between detect_vpn, geolocate_ip, and screen_country, all of which touch IP/geography and sanctions-country flagging, but their descriptions make the boundaries readable.
Six tools follow a clean screen_<entity> pattern, giving a predictable surface. detect_vpn and geolocate_ip deviate with different verbs, though they remain snake_case and readable, so this is a minor inconsistency rather than a real problem.
Eight tools is well within the ideal range and each one maps to a concrete screening target with no filler. Nothing feels redundant or missing at the count level.
Coverage spans IP, country, crypto, email, government ID, PEP names, and websites, which is broad for a screening server. Gaps exist for phone-number screening and general company/entity name screening against sanctions lists (only PEP names get a name-based path), but agents can partially route around these via other tools.
Detect whether an IP address is using a VPN.
| Name | Required | Description | Default |
|---|---|---|---|
| ip_address | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds essentially nothing beyond that — no mention of lookup latency, accuracy/confidence, behavior on private or unresolvable IPs, or whether results are cached. It largely restates the title.
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?
One front-loaded sentence with zero filler. It is efficient, though the brevity is partly the cause of the missing detail flagged elsewhere.
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, and a one-parameter lookup is inherently simple. Still, for an open-world external lookup the description omits input format expectations and any notion of result confidence or failure modes.
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 description coverage is 0% for the single required parameter, so the description must compensate. It only says 'an IP address' — no IPv4/IPv6 format expectations, no note that exactly one address is accepted per call, no handling of private/reserved ranges.
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 ('Detect') and resource ('whether an IP address is using a VPN'), which is unambiguous on its own. It does not explicitly contrast with the nearest sibling, geolocate_ip, though the resource noun (VPN usage vs. location) is distinct enough to disambiguate.
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?
No guidance on when to choose this over geolocate_ip or the screen_* tools, and no preconditions stated. The agent must infer that VPN detection is a separate signal from geolocation or fraud screening.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Geolocate an IP address and flag whether it is in a sanctioned country.
| Name | Required | Description | Default |
|---|---|---|---|
| ip_address | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile and external-lookup nature are covered structurally. The description adds the meaningful behavioral detail that the result includes a sanctioned-country determination, but says nothing about latency, rate limits, or how private/invalid IPs are handled despite openWorldHint implying a remote call.
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?
A single compact sentence with the core action front-loaded and zero filler. It is efficient, though the second clause about the sanctions flag could be sharpened into a clearer statement of what is returned versus what is checked.
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?
The existence of an output schema means return values need not be described, and annotations cover the safety profile. Still, for a one-parameter open-world lookup tool, the definition omits input format expectations and any routing versus sibling screening tools, leaving gaps an agent must guess at.
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 description coverage is 0% for the single required parameter, so the description must carry the burden and it does not. It never says whether ip_address accepts IPv4 only, IPv6, CIDR ranges, hostnames, or private addresses, leaving the one input under-specified.
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 ('Geolocate an IP address') plus a second concrete capability ('flag whether it is in a sanctioned country'), so the purpose is unambiguous. However, it never distinguishes itself from the closely related siblings detect_vpn and screen_country, which likely overlap on IP/country checks.
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?
There is no explicit when-to-use guidance, no prerequisites, and no exclusions. An agent cannot tell from this text whether to call geolocate_ip, detect_vpn, or screen_country for an IP-based check; the sanctions-screening use case is only faintly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a country or region carries sanctions designations
(OFAC-curated today). lists: optional comma-separated list slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| lists | No | ||
| country | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, non-destructive, closed-world operation. The description adds useful context that the sanctions data is OFAC-curated today, but does not explain auth requirements, rate limits, or other behavioral constraints.
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 description is two short, front-loaded sentences with no wasted wording. The core purpose comes first, followed by the only non-obvious parameter clarification.
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 simple two-parameter screening tool with rich annotations and an output schema, the description gives enough context to invoke it correctly. The main remaining gap is the absence of usage alternatives or guidance about available list slugs.
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 description coverage is 0%, so the description must carry parameter meaning. It explains that `lists` is an optional comma-separated list of list slugs, which is valuable, but the required `country` parameter receives no format detail beyond the phrase 'country or region'.
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?
The description states a specific verb and resource: checking whether a country or region carries sanctions designations. It is clearly distinct from siblings such as screen_email, screen_pep, and screen_website, though it does not explicitly name those alternatives.
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?
The description implies the tool is used for country or region sanctions screening, but gives no explicit when-to-use guidance, exclusions, or comparison to sibling screening tools. The optional `lists` note is parameter detail rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a crypto address on any chain (or an ENS name, e.g. vitalik.eth) across the
enabled sanctions and crime lists. lists: optional comma-separated list slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| lists | No | ||
| address | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context — chain-agnostic coverage, ENS resolution, and that screening runs against enabled sanctions and crime lists — but says nothing about cost, latency, or what an empty match means; return shape is covered by the output schema.
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, zero filler, with the primary capability and its scope front-loaded before the optional parameter note. Nothing repeats the schema or annotations.
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 described, and read-only annotations cover the safety profile. Remaining gaps are small — no guidance on slug discovery or on behavior when the screening lists are unconfigured — but an agent has enough to invoke it correctly.
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 description coverage is 0%, so the description must carry both parameters, and it partially does: it clarifies that 'address' accepts ENS names with a concrete example, and that 'lists' is an optional comma-separated set of list slugs. It does not say where valid slugs come from or what the null default means (presumably all enabled lists).
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 ('Screen a crypto address') and broadens scope precisely: any chain, ENS names accepted, screened against sanctions and crime lists. The resource type alone separates it from siblings like screen_email and screen_pep, though no sibling is named explicitly.
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 by the screening/sanctions context, and 'across the enabled sanctions and crime lists' hints that list configuration governs behavior. There is no explicit when-to-use guidance, no mention of what to do when no lists are enabled, and no routing to alternatives such as screen_pep for person-level checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen an email address across the enabled sanctions and crime lists.
lists: optional comma-separated list slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| lists | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context that screening runs only against 'enabled' lists, but says nothing about latency, rate limits, or what a hit/miss outcome looks like.
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 short sentences, front-loaded with the primary action, with the parameter note appended where it belongs. No filler, though the backticked fragment reads slightly like a schema annotation grafted onto prose.
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 explanation, and the tool is a simple 2-parameter read. Still missing is the default behavior when `lists` is null (presumably all enabled lists) and how to obtain valid list slugs, which an agent needs before calling with that parameter.
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 description coverage is 0%, so the description carries the burden and does explain the only non-obvious parameter: `lists` is an optional comma-separated set of list slugs. `email` is self-evident. It falls short of saying what happens when `lists` is omitted or how valid slugs are discovered.
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 (email address) and the data sources it checks (sanctions and crime lists). The sibling family (screen_country, screen_crypto_address, screen_pep, etc.) is implicitly differentiated because the resource being screened is named explicitly, though no sibling is called out by name.
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 by the verb and the resource, and 'enabled sanctions and crime lists' hints at the screening context. There is no explicit when-to-use vs when-not, no guidance on choosing among the screen_* siblings, and no note on what to do with the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a government-issued ID (passport, tax ID, …) across the enabled lists
(fuzzy matching). lists: optional comma-separated list slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| lists | No | ||
| government_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations by noting fuzzy matching and screening across enabled lists, though it does not discuss configuration requirements or result behavior beyond what the output schema provides.
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 description is two compact sentences with no wasted language. It front-loads the core purpose and then adds the key behavioral and parameter detail.
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?
The tool is simple, has an output schema, and has annotations covering the safety profile, so the description need not explain return values. It is complete enough to call correctly, with only minor gaps around explicit usage selection and required ID/list-slug formatting.
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 description coverage is 0%, so the description carries the burden for both parameters. It explains that `lists` is an optional comma-separated set of list slugs and gives examples of what `government_id` accepts, but it does not specify the required ID string format or provide list slug examples.
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?
The description uses a specific verb and resource: screen a government-issued ID. It names examples (passport, tax ID) and clearly distinguishes this tool from siblings such as screen_email, screen_crypto_address, screen_website, screen_country, and screen_pep by resource type.
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 by the resource type: use this when screening a government-issued ID. However, the description does not explicitly state when to choose this over related screening tools or when not to use it, leaving the agent to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a person's name against the OpenSanctions PEP (politically exposed
persons) dataset. Returns scored candidates; pep is true when any candidate
clears the 0.7 match threshold. birth_date (YYYY-MM-DD, or partial) and
country (name or ISO code) sharpen matching.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| country | No | ||
| birth_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds genuinely new behavioral facts: results are scored candidates and `pep` flips true only above a 0.7 match threshold. That threshold is the key decision rule for interpreting output and is not available anywhere in the structured fields. It stops short of noting hit/miss ambiguity or candidate volume.
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?
Three compact sentences, front-loaded with the dataset and output shape, then parameter hints. Every clause carries information the caller needs and nothing is repeated from annotations or schema.
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 and annotations covering read-only/open-world semantics, the remaining burden is interpretation of results and inputs, both of which the description handles via the 0.7 threshold rule and parameter formats. The only gap is guidance on how to act when the score is near but below the threshold, or which sibling to escalate to.
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 description coverage is 0%, so the description must carry the burden, and it does: `birth_date` is given a concrete format (YYYY-MM-DD, partial accepted) and `country` accepts either a name or ISO code. Both optional parameters gain actionable syntax that the schema lacks; only `name` is left unstated, which is acceptable given its obviousness as the sole required field.
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 ("Screen a person's name against the OpenSanctions PEP dataset") and names the exact external data source, which immediately separates it from siblings like screen_email, screen_country, and screen_crypto_address that screen other resource types. An agent can route to it without opening the 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?
Usage is only implied by the resource type; there is no explicit statement of when to prefer this over a sibling or what to do when a person may be a PEP under a different name spelling. It never names an alternative tool or an exclusion condition, so the agent must infer routing from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a website or domain across the enabled sanctions and crime lists.
lists: optional comma-separated list slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| lists | No | ||
| website | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context about what data is screened against ('enabled sanctions and crime lists'), but says nothing about behavior when no lists are enabled or how matching results are reported.
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 short sentences with the core purpose front-loaded and no filler. The trailing backticked `lists` fragment reads as a terse note rather than a polished sentence, which slightly hurts structure.
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, return values need not be explained. Given only two parameters and the note about enabled lists implying the null default, the definition covers most of what an agent needs, though the `website` input format remains an open gap.
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 0%, so the description has to carry the load. It does define `lists` as an optional comma-separated list of slugs, which is genuinely additive, but leaves `website` format ambiguous (bare domain vs URL, protocol, subdomains) despite it being the required param.
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?
The first sentence states a specific verb (screen) and resource (website or domain) plus the screening corpus (sanctions and crime lists). It is easily separable from siblings like screen_email or screen_country by resource type, though it never names those alternatives explicitly.
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 entirely by the resource name — an agent can infer this is the tool for website/domain screening. There is no explicit when-to-use, when-not-to-use, or prerequisite statement (e.g., that lists must be enabled first).
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.
screen_pepdetect_vpngeolocate_ipscreen_countryscreen_crypto_addressscreen_emailscreen_government_idscreen_websiteScreen crypto wallets vs OFAC SDN + threat intel; pre-payment checks, signed receipts; SAR drafts
Screen names vs the UK Sanctions List (FCDO/OFSI) plus OFAC crypto address checks.
Due diligence & KYC: PEP, national and international sanctions (OFAC, UN, EU, UK, FBI, INTERPOL, FIN
OFAC SDN sanctions screen for crypto addresses, for agents that send payments. By Crypto Money Maker
Add one secure layer between your agents and this server.
