Verify anything: email, phone, domain, URL and IBAN validation, phishing/malware URL screening, and OFAC sanctions checks. Pay-per-check in USDC on Base via x402 — no signup, no API keys.
Scored across 12 tools
Each tool targets a distinct resource type (crypto address, domain, email, IBAN, phone, URL, vessel, entity name) or a distinct purpose (pricing, data discovery, data request). Overlapping sanctions tools are clearly differentiated by target: address_screen for addresses, sanctions_screen for names, vessel_screen for vessels, and sanctions_entity for detailed records after screening.
Most data-check tools follow a consistent object_verb pattern (e.g., address_screen, email_check, phone_check). However, find_data and request_data invert the order, domain_intel uses a noun instead of a verb, and pricing stands alone as a gerund, creating mixed conventions.
12 tools is well within the ideal range for a data-screening server. Each tool covers a distinct verification task, and the additional meta tools (pricing, find_data, request_data) are useful entry points without bloating the core purpose.
The server covers a comprehensive set of screening and validation tasks across sanctions, domain, email, phone, IBAN, and URL. It includes a discovery tool (find_data) and a suggestion tool (request_data) to fill gaps, though an IP checker or company registry lookup could be considered minor omissions.
Screen a crypto address against the full live OFAC SDN list, segmented by chain. Returns a verdict with the matching SDN entries as evidence — never a silent all-clear. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Which chain the address belongs to. | base |
| address | Yes | The address to screen, in that chain's native format. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral guarantee ('never a silent all-clear'), the payment flow (call without x_payment to get terms, then with x_payment to get data), and the live nature of the SDN list. It does not cover error cases or rate limits, but the essential behaviors are transparent.
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 front-loaded with the core purpose and is appropriately sized at three sentences. The payment flow is described in a dense, run-on sentence but every clause carries essential information. Slightly more structure would improve readability, but it is not verbose.
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 description covers the core function, return behavior, and the paid payment workflow, which are the major contextual elements. There is no output schema, so the explicit mention of the verdict and evidence is valuable. It lacks details on invalid addresses or network failures, but the description is sufficiently complete for a screening tool with this complexity.
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 100%, so the baseline is 3. The description's mention of 'segmented by chain' and the payment flow adds some context, but the schema already fully documents each parameter's meaning. The description does not add significant semantic value beyond the schema.
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 opens with a specific verb and resource: 'Screen a crypto address against the full live OFAC SDN list.' It also mentions the return of a verdict with matching SDN entries as evidence, clearly distinguishing it from sibling tools like gas_price or token_safety.
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 provides clear context on the two-step payment process and explicitly names the 'pricing' tool as a free alternative for price discovery. However, it does not explicitly contrast with sibling screening tools (e.g., token_safety, nft_scam_check) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RDAP registration card for a domain (creation/expiry dates, registrar, statuses, nameservers, DNSSEC) plus derived risk flags like domain age. view='dns' returns a live multi-record DNS summary (A/AAAA/CNAME/MX/NS/TXT/SOA/CAA + SPF/DMARC); view='live' re-reads the registry at the moment you ask. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Which read to perform. | registration |
| domain | Yes | Registrable domain name. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently reveals the paid nature of the tool, the x_payment handshake, and the fact that the 'live' view re-reads the registry in real time. It does not mention potential error behavior or rate limits, but this is a notable disclosure effort.
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 dense but efficient, with each sentence contributing distinct value: data content, view specifics, payment flow, and alternative pricing tool. It is well-organized with clear semantic chunks and 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?
For a complex paid tool with multiple views and no output schema, this description is comprehensive. It covers what data is returned for each view, the payment handshake, and the available free alternative. The only minor gap is lack of explicit error scenarios, but the provided information is sufficient for an agent to use the tool 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 coverage is 100%, providing baseline of 3. The description adds meaning by explaining the values of 'view' ('dns' returns DNS summary, 'live' re-reads registry) and detailing the x_payment flow. This goes beyond the schema's terse property descriptions.
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 explicitly states the tool returns an 'RDAP registration card' with detailed domain data and derived risk flags, and clearly distinguishes between registration, DNS, and live views. It differentiates from sibling tools by focusing on domain intelligence and even points to the 'pricing' tool for pricing needs.
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 provides clear guidance on when to use each view and explains the payment flow: call without x_payment to receive terms, sign, then call again. It also mentions the free 'pricing' tool as an alternative for price discovery. However, it does not explicitly state when not to use this tool versus other sibling tools, but the distinct domain focus makes it implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deliverability signals for one address: RFC5322 syntax, live MX/SPF/DMARC over DNS-over-HTTPS, disposable/role-account flags. Signals with evidence — not a guaranteed inbox verdict. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The address to check. | ||
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the paid two-step process (call without x_payment to get terms, sign, then call again), the DNS-over-HTTPS method, and the important limitation that it is not a guaranteed inbox verdict. This is substantive behavioral context beyond the 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?
The description is densely packed but efficient: two sentences cover purpose, checks, limitations, and the paid workflow. It is front-loaded with the core deliverability information and has zero wasted words.
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?
Despite no output schema or annotations, the description covers what is checked, the evidence-based nature, the payment workflow, and a key limitation. It does not describe the exact output structure, but for a tool with this complexity, the provided context is sufficient for an agent to call and interpret results 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 coverage is 100% for both parameters, so the baseline is 3. The description adds critical semantics for x_payment by explaining the exact payment flow and the meaning of omitting it, and clarifies email is for one address, which enriches the schema's simple descriptions.
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 clearly states what the tool does: deliverability signals for one address, listing specific checks (RFC5322 syntax, MX/SPF/DMARC, disposable/role-account flags). It differentiates from siblings by focusing on single-address email deliverability, not broader domain intelligence or screening.
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 provides clear context: it is for checking a single address and returns signals with evidence, not a guaranteed verdict. It does not explicitly name alternatives or exclusion criteria, but the 'one address' scope and the specific signal list imply appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the data you need in plain language (e.g. 'Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page'). Searches this server's datasets first, then the whole Professor Sausages catalog, and returns matching endpoints with method, URL, price, and how to call them. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you're trying to find or do, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the search order (server datasets first, then catalog) and what the response contains (method, URL, price, call instructions) plus the fact that it is free. It does not mention error handling, rate limits, or authentication, but for a search/discovery tool, this is reasonably transparent and gives the agent a good sense of what to expect.
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 concise: three sentences that front-load examples, state the search behavior, and summarize output. Every sentence earns its place with no filler, and the structure guides the agent from usage examples to process to result format efficiently.
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?
Given a single parameter and no output schema, the description covers the essential context: what to provide, how the search works, and what the response will include. It could mention potential limitations or error cases, but for a tool of this complexity, the description is complete enough for an agent to select and use it correctly. A 5 would require more explicit details on edge cases 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?
The schema already fully describes the single 'task' parameter with an example. The description adds value by offering multiple plain-language examples ('Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page') and clarifies that the task can be phrased in any way, expanding the parameter's semantics beyond the schema's minimal description.
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 clearly states the tool's function: it searches for data endpoints based on a plain-language description and returns matching endpoints with method, URL, price, and call instructions. The verb 'searches' and 'returns' plus resource scope (server datasets + catalog) distinguishes it from sibling tools that each target a specific data type, so an agent can easily tell when to use it for discovery versus direct retrieval.
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 explains the tool's purpose and search process, implying it should be used when you need to locate an endpoint or data source. However, it does not explicitly state when not to use it or mention alternatives like the specific sibling tools. The guidance is clear enough for an agent to infer usage, but it lacks explicit exclusions or contrast with alternatives, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an IBAN (length + mod-97 check digits). view='decode' resolves it to country, bank and account parts; view='format' returns electronic and paper (grouped) forms. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | The IBAN, spaces optional. | |
| view | No | Which operation to run. | validate |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the payment behavior (paid terms flow), what each view does, and the validation algorithm (length + mod-97). Does not mention error/rate limits, but this is substantial for a validation tool.
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 sentences, each with distinct value: validation method, view behaviors, payment flow, and pricing alternative. No filler, front-loaded with purpose.
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 3-param tool with no output schema, the description covers the main operations and the complex paid workflow. It doesn't describe return structure, but that's not essential without an output schema. Sibling context makes selection easy.
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%, baseline 3. Description adds meaning to view enum ('decode' resolves parts, 'format' returns electronic/paper forms) and explains x_payment flow in greater detail than the schema. iban param not elaborated, but schema already says spaces optional.
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 specific operation: 'Validate an IBAN (length + mod-97 check digits)' and describes two distinct views (decode, format). Clearly identifies the resource (IBAN) and differs from sibling validation tools (email_check, phone_check, etc.).
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?
Provides clear workflow for paid calls: call without x_payment to get terms, sign, then call again with x_payment. Also points to the free `pricing` tool for all prices. Does not explicitly name alternative IBAN tools, but siblings are clearly different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and normalize a phone number: E.164 form, line type, region, and a verdict. Pure CPU, no third-party lookup. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The number, ideally in E.164. | |
| region | No | ISO-3166 region hint for national-format numbers. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses that the operation is 'Pure CPU, no third-party lookup' and fully explains the paid nature and exact terms exchange. It does not cover error conditions or rate limits, but the core behavioral traits are transparent.
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 compact and well-structured: first sentence states the core purpose, second explains performance/trade-offs, and the final part details the payment flow. Every sentence earns its place with no redundancy.
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?
Despite no output schema, the description lists the key return values (E.164, line type, region, verdict). The complex payment flow is fully explained, and the pointer to the pricing tool covers alternative needs. Minor gaps like error handling are not critical for a validation tool.
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. The description adds meaningful context for the x_payment parameter, explaining the exact usage flow (omit to get terms, sign, then provide). This goes beyond the schema's description and clarifies the parameter's role.
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 clearly states the tool's function: 'Validate and normalize a phone number' and specifies what it returns (E.164 form, line type, region, verdict). This is specific and distinct from sibling tools like email_check or domain_intel.
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?
It provides clear context for the two-step payment process ('call without x_payment... then call again with x_payment') and points to the pricing tool as an alternative for price discovery. It does not explicitly mention when not to use this tool, but the context is strong for a paid validation flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every endpoint this server fronts, with its exact per-call USD price (x402, USDC on Base) and a one-line summary, read live from the route table. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and states it reads live from the route table, indicating a read-only operation. It also discloses the 'Free' aspect. It does not mention auth or rate limits, which are likely irrelevant for a simple introspection tool.
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 entire description is one sentence that packs in the core function, source, and cost. Every word adds value with no redundancy.
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 no-parameter tool, the description conveys what is returned (endpoints, prices, summaries) and the source (live route table). It could specify the output format, but that is easily inferred.
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 has zero parameters, so the schema is fully covered by default. The description adds no parameter details because none exist, warranting the baseline score of 4 for no-parameter tools.
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 clearly states the tool lists every endpoint with its exact per-call price and a one-line summary, read live from the route table. This is a specific, unambiguous purpose and distinguishes it from sibling tools like coverage or fx_rate.
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 usage for discovering costs before calling other endpoints by emphasizing 'exact per-call USD price' and 'Free.' It provides clear context about what the tool does, though it does not explicitly name alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The suggestion box: ask for data we don't have (a pre-2015 filing, an uncovered ticker, an unsupported chain, a whole dataset). Requests feed the nightly ingestion queue — filings are usually available within ~24h. Include contact if you want to hear back. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Optional: URL/email/handle for follow-up | |
| use_case | No | Optional: what you're building | |
| description | Yes | What data you need, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the nightly ingestion queue, ~24h turnaround, the need for optional contact, and that the service is free. It does not mention potential limitations or success criteria, but the behavior is reasonably transparent for a request tool.
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 the core purpose, followed by concrete examples and behavioral notes. Every clause earns its place; no fluff.
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 request tool with no output schema, the description covers the workflow, timing, and cost. It could mention how to track request status or what happens if a request is rejected, but it is largely complete given the tool's simplicity.
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. The description adds context around the 'description' parameter (examples of what to ask for) and 'contact' (optional follow-up), but it does not substantially extend what the schema already provides. It reinforces rather than enriches.
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 clearly identifies the tool as a request mechanism for missing data, with specific examples (pre-2015 filing, uncovered ticker, unsupported chain) that distinguish it from sibling retrieval tools. The verb 'ask for' and resource 'data we don't have' make the purpose unambiguous.
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 conveys when to use it (when data is missing from existing coverage) and gives concrete examples, but it doesn't explicitly reference sibling tools or state 'use this if find_data/coverage fails.' The implied guidance is strong but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The complete OFAC record for one entity number: all aliases, addresses, sanctions programs, and extracted identifiers (passports, tax ids, DOBs). Use after sanctions_screen returns a candidate. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | OFAC ent_num from a screen result. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the two-step payment flow, the paid nature, and the types of data returned. It does not mention rate limits or auth details, but covers key behavioral aspects.
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 sentences: purpose, usage, payment. Each sentence adds a distinct layer with no redundancy. The main purpose is front-loaded, and every word earns its place.
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?
No output schema, yet the description enumerates returned data types (aliases, addresses, programs, identifiers). It fully explains the payment terms flow and references the pricing tool for cost transparency. Sufficient for an agent to select and invoke the tool 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 coverage is 100%, so baseline is 3. The description adds meaningful context for x_payment, explaining the sign-and-resubmit process. It reinforces the source of id (screen result) without contradicting the schema.
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 explicitly states it returns 'the complete OFAC record for one entity number' and enumerates contents (aliases, addresses, sanctions programs, identifiers). It distinguishes from siblings by saying to use it after sanctions_screen returns a candidate.
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?
Provides explicit when-to-use context: 'Use after sanctions_screen returns a candidate.' It also names an alternative for pricing: 'The free `pricing` tool lists every price at once.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-screen a name against the full OFAC SDN + Consolidated lists. Returns match / possible_match / no_match with scored candidates and the aliases that matched — never a silent all-clear. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | Which OFAC list(s) to screen against. | all |
| name | Yes | Name to screen. | |
| type | No | Restrict to one party type. | |
| limit | No | Max candidates to return. | |
| min_score | No | Minimum fuzzy score (0-100) for a candidate to be returned. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is paid, requires a two-step x_payment flow, returns match/possible_match/no_match with scored candidates and matching aliases, and guarantees it never gives a 'silent all-clear.' This goes well beyond the schema and gives agents critical behavioral context.
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 three dense sentences with no fluff. Each sentence earns its place: the first defines what it does and returns, the second explains the payment flow, and the third directs to the pricing tool. Perfectly sized for the complexity.
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?
Despite having no output schema, the description explains the return types and candidate details sufficiently. It also covers the payment flow, which is essential for a paid tool, and mentions the pricing alternative. This is complete for an agent to decide when and how to invoke it.
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. The description adds operational meaning for x_payment (the two-step terms-then-pay flow) and reinforces fuzzy matching for name and min_score. This extra context elevates it beyond the schema alone.
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 clearly states the tool's action ('Fuzzy-screen a name') and specific target ('full OFAC SDN + Consolidated lists'), which distinguishes it from sibling tools like address_screen or vessel_screen. It also specifies the output categories (match / possible_match / no_match), making the purpose unmistakable.
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 provides explicit payment workflow guidance: call without x_payment to get terms, sign, then call again with x_payment. It also points to the free 'pricing' tool as an alternative for viewing all prices. However, it does not explicitly compare against other screening tools (e.g., sanctions_entity) for when to use name screening over entity screening, though the 'name' focus implies this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a URL against the URLhaus blocklist snapshot plus deterministic live heuristics (redirect chain, host reputation signals, lookalike patterns). Returns a verdict with the rules that fired. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute URL to screen. | |
| follow | No | Follow the redirect chain before judging. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It details the two-step paid call pattern, the data sources (URLhaus snapshot + live heuristics), and the nature of the response ('verdict with the rules that fired'). It does not cover potential limitations or rate limits, but the core behaviors are clearly disclosed.
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 concise and well-structured: it states the core function in the first sentence, describes the return value in the second, and explains the payment flow in the third. No redundant words, every sentence earns its place, and important information is front-loaded.
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?
Given the moderate complexity (multi-step payment, standalone heuristic logic) and lack of output schema, the description sufficiently covers the tool's behavior, return value, and payment workflow. It could further clarify the verdict format or edge cases, but overall it provides enough context for an agent to use the tool 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?
The input schema already provides 100% coverage with detailed descriptions for all three parameters, including the payment workflow for x_payment. The tool description largely repeats this information, adding no meaningful new semantic value beyond the schema. Baseline 3 is appropriate when schema coverage is high and the description does not compensate with additional context.
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 clearly states it 'Screen a URL against the URLhaus blocklist snapshot plus deterministic live heuristics' with specific method details (redirect chain, host reputation, lookalike patterns). This distinguishes it from sibling tools like address_screen or domain_intel by focusing on phishing/malicious URL screening.
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 provides clear usage context for the payment workflow ('call without x_payment to receive terms...') and explicitly names the free `pricing` tool as an alternative for price discovery. However, it does not explicitly explain when to choose this tool over sibling screen tools, though the title and content make the intended use fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen vessels against OFAC maritime designations by fuzzy name, exact call sign, or IMO number, with flag filtering. Paid: call without x_payment to receive this call's exact terms (amount, asset, network), sign them, then call again with x_payment. The free pricing tool lists every price at once.
| Name | Required | Description | Default |
|---|---|---|---|
| imo | No | IMO number. | |
| flag | No | Flag state filter. | |
| name | No | Vessel name (fuzzy). | |
| limit | No | Max results. | |
| call_sign | No | Exact call sign. | |
| x_payment | No | Optional signed x402 payment payload (base64, what the X-PAYMENT header carries). Omit to receive the exact payment terms; sign them (e.g. @x402/fetch) and call again with this argument to settle and get the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is paid, requires a two-step x402 payment flow, and that the first call returns payment terms rather than data. This is important behavioral context, though it doesn't cover error handling or response format.
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 three sentences, each earning its place: purpose, payment flow, and pricing tool reference. It is concise and front-loaded with the core purpose.
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 no output schema and no annotations, the description should explain return values. It covers payment mechanics and matching modes well, but does not describe the response format, pagination, or behavior when no match is found. It is adequate but has gaps.
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 100%, so the baseline is 3. The description restates matching criteria (fuzzy name, exact call sign, IMO, flag) and the x_payment flow, but the schema already documents each parameter, including x_payment's detailed explanation. The description adds minimal new parameter-level information.
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 clearly states the tool screens vessels against OFAC maritime designations using multiple identifiers (fuzzy name, exact call sign, IMO) and flag filtering. This distinguishes it from sibling tools like sanctions_screen or sanctions_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?
The description explicitly explains the paid flow: call without x_payment to get terms, sign them, and call again with x_payment. It also points to the `pricing` tool for listing all prices. However, it doesn't explicitly contrast with non-vessel sanctions screens.
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.
address_screendomain_intelemail_checkfind_dataiban_checkphone_checkpricingrequest_datasanctions_entitysanctions_screenurl_screenvessel_screen
Add one secure layer between your agents and this server.