Skip to main content
Glama

Limitguard Lead Verification

Server Details

Lead validation over MCP: KVK/KBO register, EU VAT, sanctions and email checks with sources.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
jwconsultancyteam/limitguard-mcp
GitHub Stars
1
Server Listing
Limitguard

TDQS

Score is being calculated.

Available Tools

10 tools
check_agent_wallet
Read-only
Inspect

Check a counterparty agent's EVM wallet in one call: OFAC SDN digital-currency address list match, Base USDC and ETH balance, ERC-8004 identity registration (and, given an agent id, that agent's owner and payment wallet) and open ERC-8004 feedback, which is not scored. $0.75.

        Returns verdict (block, review or no_findings) with verdict_reasons,
        the components that ran and those that did not (with a reason), and
        sanctions, balance, identity, reputation, wallet_risk and domain
        (when a domain is given, else not_requested), each with its own
        status (ok, unavailable or error). Reputation and domain are
        descriptive only and never change the verdict. Base only; EVM
        addresses only.

        Args:
            wallet: EVM wallet address (0x + 40 hex characters)
            agent_id: Optional ERC-8004 agentId (decimal) the wallet claims
            domain: Optional website domain the agent gives for itself (e.g. example.com)
        
ParametersJSON Schema
NameRequiredDescriptionDefault
domainNo
walletYes
agent_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
check_entity
Read-only
Inspect

Company check via the Limitguard API.

    Company check on a business: sanctions screening and country risk, the
    Dutch KVK register for an NL company, and the website domain when you send
    it. Returns trust_score (0-100, 100 = best), trust_level (high means low
    risk), cluster, recommendation, confidence, top_factors and sources_checked.

    Args:
        entity_name: Full legal name of the entity
        country: ISO 3166-1 alpha-2 country code (e.g., NL, BE, DE)
        kvk_number: Optional Dutch KVK registration number (8 digits)
        domain: Optional company website domain
    
ParametersJSON Schema
NameRequiredDescriptionDefault
domainNo
countryYes
kvk_numberNo
entity_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
get_compliance_reportAInspect

Per-entity report built from one real check.

        Registry identity, sanctions and PEP screens, domain signals, risk score
        with the rules that fired, correlations, every finding as a ranked action, a per-source
        status table (ok / unavailable / error) and a report hash.

        Args:
            entity_name: Full legal name (with country; omit when sending check_id)
            country: ISO 3166-1 alpha-2 country code
            kvk_number: Optional Dutch KVK number (8 digits)
            cbe_number: Optional Belgian CBE number (0XXX.XXX.XXX or 10 digits)
            vat_number: Optional EU VAT number
            domain: Optional company website domain
            iban: Optional IBAN (never stored raw)
            wallet_address: Optional crypto wallet address (format check only)
            wallet_chain: Optional chain for wallet_address (eth, base, btc, sol, ...)
            check_id: Id of a check from an earlier report, instead of identifiers
        
ParametersJSON Schema
NameRequiredDescriptionDefault
ibanNo
domainNo
countryNo
check_idNo
cbe_numberNo
kvk_numberNo
vat_numberNo
entity_nameNo
wallet_chainNo
wallet_addressNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description coherently explains why: the report is 'built from one real check', which is a state-changing, non-idempotent external operation. It also adds behavioral detail the annotations cannot carry, notably 'never stored raw' for IBAN and a per-source status table covering ok/unavailable/error, so the agent knows results can be partial.

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?

Purpose and report contents are front-loaded ahead of the argument list, and the argument block is necessary given 0% schema coverage, so nothing is wasted. The raw docstring-style indentation is slightly awkward but does not impede parsing.

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?

An output schema exists, so return values need not be explained, yet the description duplicates much of that content while also fully documenting all 10 parameters. The one missing piece is explicit sibling routing guidance, but for a complex 10-parameter tool the definition is otherwise complete.

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 description coverage is 0% and all 10 parameters are optional, so the description carries the full documentation burden and does so well: it gives formats (ISO 3166-1 alpha-2, 8-digit KVK, Belgian CBE pattern, EU VAT), constraints (IBAN never stored raw, wallet address format-check only), example chain values, and the check_id-versus-identifiers relationship.

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

Purpose4/5

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

The description states a specific verb and resource: it produces a per-entity compliance report and enumerates exactly what the report contains (registry identity, sanctions/PEP screens, risk score, findings, source status table, hash). It is clearly distinguished in kind from atomic siblings like get_risk_score or sanctions_screen, though it never names an alternative sibling.

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?

Usage is implied rather than stated: the entity_name note ('omit when sending check_id') tells the agent the two input paths are mutually exclusive, which is a genuine routing hint. However, there is no guidance on when to call this full report versus the lighter siblings (check_entity, get_risk_score, sanctions_screen), which an agent would plausibly be choosing between.

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

get_risk_score
Read-only
Inspect

Quick risk score from sanctions screening and country risk only.

    Faster than check_entity: no register or domain lookup.
    Use when you only need basic risk evaluation. Returns risk_score (0-100,
    100 = riskiest), risk_level (high means high risk, the reverse of
    check_entity's trust_level), sanctions_match and fatf_status; no
    recommendation or factors.

    Args:
        entity_name: Full legal name of the entity
        country: ISO 3166-1 alpha-2 country code
    
ParametersJSON Schema
NameRequiredDescriptionDefault
countryYes
entity_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
get_trust_scoreA
Read-only
Inspect

Look up your own most recent trust score for an entity you checked before, from your stored checks: score, level, when, which product, trend and how many checks are on record. Runs no new check and calls no data source. Free ($0).

    Returns status "found" with trust_score, trust_level, checked_at,
    source_product, trend and checks_on_record, or status "not_found" with a
    next_step. Only checks made with your key (via check_entity, or REST
    entity/KYB checks) are read; another key's or workspace's never are (#946).
    Signed in with OAuth, your workspace's checks are read instead (#1062).

    Args:
        entity_id: The entity name, as you sent it to check_entity
    
ParametersJSON Schema
NameRequiredDescriptionDefault
entity_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/destructive annotations: it discloses cost ($0), that no data source is called, that only checks made with your key are readable, that another key's or workspace's checks never are, and that OAuth sessions read workspace checks instead. It also enumerates the two possible status outcomes.

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

Conciseness5/5

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

Front-loaded with the core purpose and the key behavioral distinction before any detail, then structured into return values, scoping rules and args. The issue references (#946, #1062) are terse and the prose has no filler.

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 names the returned fields and the found/not_found statuses, and it covers the authorization scoping an agent would otherwise have to discover by failure. Nothing needed to call it correctly is missing.

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

Parameters4/5

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 the single parameter, and it does: entity_id is 'The entity name, as you sent it to check_entity', clarifying that it is the exact name string previously submitted rather than an internal identifier. It does not restate the type, but that is in the schema.

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 ('look up your most recent trust score') and pins the scope precisely: it reads a previously stored check rather than performing one. The clause 'from your stored checks' plus the explicit 'Runs no new check and calls no data source' cleanly separates it from check_entity and the other check/verify siblings.

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

Usage Guidelines4/5

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

Gives a clear condition for use ('an entity you checked before') and an implicit but well-signposted alternative via 'Runs no new check' and 'as you sent it to check_entity'. It does not spell out a when-not rule such as 'use check_entity if you need a fresh score', so it falls just short of explicit routing.

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

sanctions_preview
Read-only
Inspect

Free yes/no sanctions preview against the local OFAC SDN, EU and UN lists.

        Returns possible_match, lists_checked, list_dates and list_note only,
        never an entry. 10 per caller per UTC day, shared with POST /v1/sanctions/preview,
        and key holders share a ceiling of 50 per IP; the matched entries are
        the sanctions_screen tool. Free ($0).

        Args:
            name: Company or person name to screen
            country: Optional ISO 3166-1 alpha-2 country code (orders matches, never excludes one)
        
ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
countryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
sanctions_screen
Read-only
Inspect

Sanctions screen against the local OFAC SDN, EU and UN lists: matched entries.

        Each match carries its list, entry id, entry type, programmes,
        countries, listing date and match score (exact normalised or
        word-order-insensitive name match only). A name match is not a
        determination. Rejected calls are not charged.

        Args:
            name: Company or person name to screen
            country: Optional ISO 3166-1 alpha-2 country code (orders matches, never excludes one)
        
ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
countryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
verify_lead
Read-only
Inspect

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.27.

        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
        
ParametersJSON Schema
NameRequiredDescriptionDefault
ibanNo
nameNo
emailNo
phoneNo
domainNo
addressNo
countryYes
vat_numberNo
target_sizeNo
company_numberNo
target_industriesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
verify_wallet
Read-only
Inspect

Screen a wallet: OFAC SDN address match, on-chain signals (contract check, native and USDC balance, transaction count, first seen on Base) and named risk rules with up to 3 advice items. On Base, also reports any ERC-8004 agent the wallet owns and its open on-chain reputation as descriptive signals, never scored. $0.11.

    Returns risk_score, risk_level, sanctions (hit, lists, as_of), signals
    with their source, the names of signals that could not be read
    (unavailable), rules_fired, advice and linked_entities (entities you
    checked that were linked to this wallet). On Base, also
    erc8004_agent_ids and erc8004_reputation (open ERC-8004 feedback,
    descriptive only -- never folded into risk_score or advice).
    Accepts EVM (0x...) and Solana (base58) addresses. The sanctions
    match alone is free: the wallet_sanctions_preview tool. Rejected
    calls are not charged.

    Args:
        wallet_address: Blockchain wallet address
        chain_id: CAIP-2 chain ID (default: eip155:8453 for Base); base, eth, solana, btc also accepted
    
ParametersJSON Schema
NameRequiredDescriptionDefault
chain_idNoeip155:8453
wallet_addressYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes
wallet_sanctions_preview
Read-only
Inspect

Free yes/no check of a wallet address against the OFAC SDN list.

        Returns wallet_address (canonical), chain_id, sanctioned, lists,
        as_of (the list's publication date), status (ok or stale), source
        and upgrade, which names the full wallet screen (the verify_wallet
        tool, $0.11: balances, wallet age and activity, contract and
        delegation checks, a risk score with rules and advice, linked
        entities, ERC-8004 identity and reputation). 10 per caller per UTC
        day, shared with POST /v1/sanctions/wallet and separate from the
        name preview; key holders share a ceiling of 50 per IP. Free ($0).

        Args:
            wallet_address: Blockchain wallet address
            chain_id: CAIP-2 chain ID (default: eip155:8453 for Base); base, eth, solana, btc also accepted
        
ParametersJSON Schema
NameRequiredDescriptionDefault
chain_idNoeip155:8453
wallet_addressYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 10 tool updates
    • First observedcheck_agent_wallet
    • First observedcheck_entity
    • First observedget_compliance_report
    • First observedget_risk_score
    • First observedget_trust_score
    • First observedsanctions_preview
    • First observedsanctions_screen
    • First observedverify_lead
    • First observedverify_wallet
    • First observedwallet_sanctions_preview

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    B
    maintenance
    Enables email address verification through a single MCP tool, returning whether an address is valid, invalid, or risky.
    1
    -
  • A
    license
    A
    quality
    D
    maintenance
    Enables real-time email verification via MCP tools, checking syntax, MX, disposable domains, and optional SMTP probe to determine deliverability with a VALID/RISKY/INVALID verdict.
    2
    11 npm
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.