Limitguard Lead Verification

wallet_sanctions_preview

Read-only

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

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?

Beyond the read-only/open-world annotations, it discloses cost ($0), quota (10 per caller per UTC day, shared with the POST endpoint and separate from the name preview), key-holder ceiling (50 per IP), and that status may be 'ok' or 'stale' with as_of reflecting the list's publication date. That is unusually rich operational context.

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 the upgrade path are front-loaded, and the rate/cost facts are compactly stated. It is somewhat verbose, restating the free price and enumerating return fields already covered by the output schema, but no sentence is truly wasted.

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?

Given an output schema exists, the description need not explain return values, yet it still flags the notable ones (sanctioned, lists, as_of, status, source) and fully covers cost, quotas, defaults and the alternative tool. An agent has everything needed to call this correctly.

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 carries the burden: it documents both parameters, giving chain_id's CAIP-2 format, its default (eip155:8453 for Base) and the accepted aliases base/eth/solana/btc, plus the required wallet_address. The wallet_address gloss itself is thin, which keeps this from a 5.

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?

The opening sentence names a specific verb (check), resource (wallet address) and dataset (OFAC SDN list), and scopes it as a free yes/no preview. It also explicitly distinguishes itself from siblings by pointing to verify_wallet as the fuller screen and noting it is separate from the name preview.

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?

It makes clear this is the free, narrow sanctions-only check and routes the agent to verify_wallet (with pricing) when balances, activity, delegation and risk scoring are needed. There is no explicit 'do not use this when...' exclusion, but the free-vs-paid split is unambiguous.

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.