fairquery-agent-trust-mcp

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Screen leads: email deliverability + sanctions (paid)

trust_screen_lead

Read-onlyIdempotent

Screen leads by validating email deliverability and screening sanctions lists in parallel, returning pass, review, or block per lead.

Instructions

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: If you only need one check, call that tool directly (cheaper). Free pre-filter: email_check_syntax. COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $0.002 per lead with email + $0.005 per lead with name (= $0.007 per full lead). 2 Actor runs per call. 100 full leads ~ $0.70. Takes ~15-45 s (sanctions list download). RETURNS: Paged items {type:"lead",ref,email,name,decision(pass|review|block),reasons[],email_verdict,email_reasons,did_you_mean,sanctions_status,sanctions_best_score,sanctions_matches[top 3]}; meta.summary counts by decision, meta.disclaimer. Partial failure: affected check shows "unavailable" and meta.errors lists codes. Tool errors: INPUT_EMPTY, APIFY_TOKEN_MISSING. BEHAVIOR: Read-only, no side effects (no email sent), idempotent. Makes network calls: runs the email and sanctions Apify Actors in parallel, billed to your APIFY_TOKEN; latency seconds to minutes (300 s timeout). PARAMETERS: leads = {ref,email,name,country,entityType} records (required); minScore = sanctions fuzzy-match threshold 60-100 (default 88); allowFreeProviders = treat gmail.com etc. as valid, false for B2B (default true); limit = page size (default 100, max 1000); offset = items to skip for paging (default 0). 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

TableJSON Schema

Name	Required	Description
`leads`	Yes	Required. 1-1000 leads; each needs email and/or name
`limit`	No	Page size: items to return, integer 1-1000 (default 100)
`offset`	No	Items to skip for paging, integer >= 0 (default 0); pass nextOffset from the previous response
`minScore`	No	Sanctions fuzzy threshold 60-100 (default 88)
`allowFreeProviders`	No	Default true; false marks gmail.com etc. as risky (B2B)

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	No	Tool-specific context (summary counts, cost notes, ...)
`count`	Yes	Number of items in this page
`items`	Yes	Result rows for this page
`total`	Yes	Total items before paging
`offset`	Yes	Offset of the first item in this page
`hasMore`	Yes	True if more items exist after this page
`nextOffset`	Yes	Offset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds substantial context beyond them: per-lead pricing billed to the caller's APIFY_TOKEN, 2 Actor runs, 15-45s latency with a 300s timeout, partial-failure semantics ("unavailable" plus meta.errors), and named tool error codes. This is unusually rich disclosure for a read-only tool.

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?

Heavily front-loaded with labeled WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE sections that make scanning easy. It is on the long side and repeats the cost model in both COST and BEHAVIOR, but nearly every sentence carries actionable content.

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?

For a paid, multi-Actor, network-bound tool this covers everything an agent needs: cost, latency, timeout, partial-failure and error handling, input shape, paging, and an end-to-end example. An output schema exists, yet the description still orients the agent on return shape without redundancy being harmful.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, and the description's PARAMETERS section largely restates them (defaults, ranges, the B2B rationale for allowFreeProviders). It adds little beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource (screen a batch of leads by running email deliverability and sanctions screening in parallel, then merging per-lead into a pass/review/block decision). It explicitly names the two sibling tools it composes (email_validate_deliverability, sanctions_screen_names), so an agent can distinguish it from calling those directly.

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?

Has explicit WHEN (onboarding, qualifying inbound leads, CRM hygiene) and WHEN NOT (use the single-check tool directly as it is cheaper; email_check_syntax as a free pre-filter). Alternatives and the condition selecting them are spelled out, leaving nothing to inference.

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

Deploy Server