Limitguard Lead Verification

verify_lead

Read-only

Verify a NL/BE sales lead against the registers in one call: real and active, VAT, mail server, IBAN, sanctions; a 0-100 lead score. $0.10 by x402, $0.27 with an API key.

        Returns verdict (real_active, real_inactive, not_found, ambiguous,
        unverifiable or sanctioned), lead_score, the company as registered,
        and the vat, iban, sanctions and email checks, with flags and one
        finding per flag or mismatch, a dormant-shell score and, when a
        target is given, the ICP fit (information only). An input not given
        is not checked and never counts against the lead. The IBAN account holder is not checked.
        BE needs company_number. Rejected calls are not charged.

        Args:
            country: NL (KVK) or BE (KBO)
            company_number: 8-digit KVK number or 10-digit KBO/CBE number
            name: Company name as the lead gave it (NL without a number)
            vat_number: EU VAT number, checked with VIES
            email: Contact email; only its domain is checked
            domain: Company website domain
            address: {street, house_number, postcode, city} the lead gave
            iban: IBAN the lead gave; only country, bank, BIC and last 4 are returned
            phone: Phone number the lead gave; compared with the numbers the company publishes, never echoed. Rejected until website phone lookup is switched on
            target_industries: Ideal-customer industries: SBI/NACE code prefixes ("62") or whole words; information only
            target_size: Ideal-customer employee range {min, max}, both inclusive; information only

Input Schema

Name	Required	Description	Default
`iban`	No
`name`	No
`email`	No
`phone`	No
`domain`	No
`address`	No
`country`	Yes
`vat_number`	No
`target_size`	No
`company_number`	No
`target_industries`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations: discloses per-call pricing ($0.10 via x402, $0.27 with API key), that rejected calls are not charged, that omitted inputs are never counted against the lead, and privacy behavior (IBAN reduced to country/bank/BIC/last 4; phone never echoed). These are exactly the operational facts an agent cannot get from readOnlyHint/openWorldHint.

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?

Front-loaded with the core purpose and well-structured Args block; nearly every sentence carries information. It is somewhat long, and the detailed return-value paragraph partially duplicates what the output schema already provides, which is the only real inefficiency.

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

Completeness4/5

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

For an 11-parameter, open-world verification call with an output schema, the definition covers inputs, output verdicts, cost, and edge-case prerequisites thoroughly. The one gap is sibling-relative positioning, which is minor since an output schema already carries the return contract.

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 0%, so the description carries the full burden and does: it documents formats and semantics for nearly every arg (8-digit KVK vs 10-digit KBO, VIES for VAT, email domain-only check, address sub-keys {street, house_number, postcode, city}, SBI/NACE prefixes or whole words for target_industries, inclusive {min,max} for target_size) and marks the ideal-customer inputs as information-only.

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 ('Verify a NL/BE sales lead against the registers') and enumerates exactly what is checked (registry status, VAT, mail server, IBAN, sanctions) plus the composite lead score. This scope is clearly distinct from siblings like check_entity or sanctions_screen, which cover narrower slices.

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

Usage Guidelines3/5

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

Gives conditional usage rules ('BE needs company_number', 'phone ... rejected until website phone lookup is switched on', 'An input not given is not checked') which is genuine guidance. However it never states when to prefer this tool over the adjacent check_entity, get_risk_score, or sanctions_screen siblings, leaving alternative-selection to inference.

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

All Limitguard Lead Verification tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.