Skip to main content
Glama

Fairquery Agent Trust & Data Safety

Screen leads: email deliverability + sanctions (paid)

trust_screen_lead
Read-onlyIdempotent

WHAT: One call per batch of leads/counterparties: runs email_validate_deliverability on their emails and sanctions_screen_names on their person/company names IN PARALLEL, then merges results per lead with an overall decision: block (invalid email or sanctions potential_match), review (risky email), pass. WHEN: Onboarding customers/vendors, qualifying inbound leads, CRM hygiene where both email quality and sanctions exposure matter. WHEN NOT: Email only -> email_validate_deliverability; names only -> sanctions_screen_names (same per-item prices, no merge step). Free pre-filter first: email_check_syntax. Use this tool only when a lead needs both checks and one decision. COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $0.79 per 1,000 leads with email + $3.00 per 1,000 leads with name (= $3.79 per 1,000 full leads) + $7.00 per 1,000 calls for the sanctions run. 100 full leads ~ $0.39. RETURNS: Paged "lead" rows (decision pass | review | block with reasons[]; sanctions_matches holds the top 3); meta.summary counts by decision. Partial failure: the affected check shows "unavailable" and meta.errors lists codes. Tool errors: INPUT_EMPTY, APIFY_TOKEN_MISSING. BEHAVIOR: No email is sent. Called from this Fairquery-hosted Worker, which forwards your input and Apify token to Apify and waits 20 s (APIFY_TIMEOUT if the run has not finished). This Worker's code is designed not to store them. Runs the email and sanctions Apify Actors in parallel (2 runs per call) in your account. Sanctions lists come from a cache at most 6 h old, or are downloaded; a download can outlast the 20 s wait. PARAMETERS: leads: each record needs email and/or name (if no lead has either -> INPUT_EMPTY, nothing billed); a lead with only an email skips sanctions (sanctions_status "not_checked") and one with only a name skips email (email_verdict "not_checked"), so a lead is billed for each check it gets (prices under COST), plus the per-call sanctions run fee when any lead has a name. Identical emails across leads are validated and billed once. ref joins sanctions results back to the lead, so keep refs unique (default = the lead's 0-based index as a string). country and entityType apply to that lead's sanctions check only: entityType filters candidates, while country only annotates matches (never removes them). minScore: sanctions similarity threshold; default 88 here (stricter than the 85 of sanctions_screen_names) to keep block decisions low-noise; each name returns at most its top 3 matches. allowFreeProviders=false turns gmail.com-type addresses into email_verdict "risky", i.e. decision "review" (never "block"). Decision precedence: any sanctions potential_match or invalid email -> block; else risky email or an incomplete check -> review; else pass. limit/offset page the merged lead rows, but every call re-runs and re-bills both checks for all leads (also when only offset changes), so set limit (max 1000) to cover all leads; meta.summary counts all leads. EXAMPLE: {"leads":[{"ref":"L1","email":"cfo@acme.com","name":"Acme Trading LLC","country":"US"}]} -> {decision:"pass",email_verdict:"valid",sanctions_status:"no_match"}

Input Schema

NameRequiredDescriptionDefault
leadsYesRequired. 1-1000 lead objects {ref?, email?, name?, country?, entityType?}; each needs email and/or name. Example: [{"ref":"L1","email":"cfo@acme.com","name":"Acme Trading LLC","country":"US","entityType":"entity"}]
limitNoOptional page size: items to return, integer 1-1000 (default 100). Example: 50
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100
minScoreNoOptional integer 60-100, default 88. Minimum 0-100 fuzzy name-similarity for a sanctions potential_match (which blocks the lead). Example: 92
allowFreeProvidersNoOptional boolean, default true. false makes free webmail (gmail.com, outlook.com, ...) email_verdict "risky" -> decision "review"; recommended for B2B

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context (summary counts, cost notes, ...)
countYesNumber of items in this page
itemsYesResult rows for this page
totalYesTotal items before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: exact price model, that billing hits the caller's own Apify account, that pagination does NOT avoid re-running and re-billing, the 20s Worker-side wait with APIFY_TIMEOUT, per-check 'unavailable' degradation with meta.errors, sanctions cache staleness (up to 6h, download may exceed the wait), and that no email is actually sent. Minor tension worth noting: idempotentHint=true while the description says every call incurs new charges, though results are unchanged.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Heavy but well-engineered: labeled WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE headings front-load scope before cost and mechanics, and the worked example anchors the contract. It loses a point because the PARAMETERS block retreads schema-level details (max lengths, enums, defaults) and some sentences pack multiple rules together at the cost of skimmability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still supplies the essentials an agent needs to interpret it: row shape (decision + reasons[] + sanctions_matches capped at 3), meta.summary as an all-leads count rather than a page count, and the partial-failure signal. Combined with the stated error codes and the paging re-bill warning, nothing material for correct invocation is missing.

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

Parameters5/5

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

Schema coverage is already 100%, so a 3 would be the floor, but the description adds real decision semantics: ref uniqueness rationale (joins sanctions results back to the lead), that country only annotates and never filters while entityType does filter, that minScore defaults to 88 here versus 85 in sanctions_screen_names, and that allowFreeProviders=false can only produce 'review', never 'block'. It also states the billing consequence of supplying only one of email/name, which the schema cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The WHAT section states a specific compound verb (runs two named checks in parallel, merges per lead) on a specific resource (batch of leads/counterparties) and even names the decision vocabulary it produces (block/review/pass). It explicitly distinguishes itself from the three nearest siblings (email_validate_deliverability, sanctions_screen_names, email_check_syntax), so an agent can place it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The WHEN / WHEN NOT / COST block is explicit routing guidance: it names the exact condition that selects each alternative ('Email only -> email_validate_deliverability; names only -> sanctions_screen_names') and adds a free pre-filter step. The closing rule 'Use this tool only when a lead needs both checks and one decision' gives a hard boundary rather than an implied one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources