Limitguard Lead Verification

verify_wallet

Read-only

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.005 by x402, $0.11 with an API key.

    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

Input Schema

Name	Required	Description	Default
`chain_id`	No		eip155:8453
`wallet_address`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly/openWorld/idempotent=false), but the description adds non-obvious behavior: $0.005 via x402 vs $0.11 with an API key, that rejected calls are not charged, and that ERC-8004 agent/reputation data is descriptive only and never folded into risk_score or advice. None of that is recoverable from structured fields.

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 cost are front-loaded and the Args block is tidy, but the return-value paragraph restates the output schema and the ERC-8004 'descriptive only, never scored' caveat is repeated in both paragraphs, adding redundancy an output schema could already imply.

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 screening tool with rich annotations and an output schema, the description still covers everything the agent needs: chain defaults and aliases, accepted address formats, pricing/charging rules, scoring composition, and the sibling for a cheaper sanctions-only path. No material gaps remain.

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 coverage is 0%, so the description must carry the burden; it explains chain_id is a CAIP-2 ID with default eip155:8453 and that base/eth/solana/btc aliases are accepted, and states accepted address formats (EVM 0x..., Solana base58). The wallet_address gloss itself is thin ('Blockchain wallet address'), so it is strong but not maximal.

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 wallet') and enumerates exactly what is checked (OFAC SDN, contract check, balances, tx count, first-seen-on-Base, named risk rules). It also names the free sibling, wallet_sanctions_preview, so an agent can distinguish the full screen from the sanctions-only path.

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 routing rule to an alternative: 'The sanctions match alone is free: the wallet_sanctions_preview tool,' plus pricing to inform cost-based selection. It lacks guidance against the other risk siblings (get_risk_score, check_entity, sanctions_screen), so it is clear context without full exclusions.

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.