Limitguard Lead Verification
Server Details
Lead validation over MCP: KVK/KBO register, EU VAT, sanctions and email checks with sources.
- 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 toolscheck_agent_walletRead-onlyInspect
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)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| wallet | Yes | ||
| agent_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
check_entityRead-onlyInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| country | Yes | ||
| kvk_number | No | ||
| entity_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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
| Name | Required | Description | Default |
|---|---|---|---|
| iban | No | ||
| domain | No | ||
| country | No | ||
| check_id | No | ||
| cbe_number | No | ||
| kvk_number | No | ||
| vat_number | No | ||
| entity_name | No | ||
| wallet_chain | No | ||
| wallet_address | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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_scoreRead-onlyInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| entity_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
get_trust_scoreARead-onlyInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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_previewRead-onlyInspect
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)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| country | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
sanctions_screenRead-onlyInspect
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)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| country | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
verify_leadRead-onlyInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| iban | No | ||
| name | No | ||
| 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 |
|---|---|---|
| result | Yes |
verify_walletRead-onlyInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | eip155:8453 | |
| wallet_address | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
wallet_sanctions_previewRead-onlyInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | eip155:8453 | |
| wallet_address | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
10 tool updates
- First observed
check_agent_wallet - First observed
check_entity - First observed
get_compliance_report - First observed
get_risk_score - First observed
get_trust_score - First observed
sanctions_preview - First observed
sanctions_screen - First observed
verify_lead - First observed
verify_wallet - First observed
wallet_sanctions_preview
Related MCP Connectors
EU company, sanctions and PEP checks, x402 payee check; Dutch homes and cars. Pay per call or key.
EU VIES VAT-number validation MCP (European Commission).
Company hierarchy analysis and address verification via MCP
EU company check, sanctions, PEP, bulk screening, watches, x402 payee check, wallet evidence.
231
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables MCP-capable agents to validate EU VAT numbers, IBANs, and EORI customs numbers, look up company data by LEI or VAT, and fetch current VAT rates, with built-in service health checks.7MIT
- FlicenseAqualityBmaintenanceEnables email address verification through a single MCP tool, returning whether an address is valid, invalid, or risky.1-
- AlicenseAqualityDmaintenanceEnables 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.211 npmMIT
- FlicenseNot gradedqualityCmaintenanceProvides real validation and live registry lookups for ecommerce and fintech workflows, including EU VAT, EORI, email domain, IBAN, ABA routing, and GTIN checks.-
Glama MCP Gateway
Add one secure layer between your agents and this server.