Skip to main content
Glama
Sign In

Limitguard Lead Verification

by ai.limitguard.api
OverviewDiscussionsAdmin

check_agent_wallet

Read-only

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

        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)

Input Schema

NameRequiredDescriptionDefault
domainNo
walletYes
agent_idNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds substantial extra context: per-call pricing under x402 vs API key, the verdict taxonomy (block/review/no_findings) with verdict_reasons, per-component status values (ok/unavailable/error), and the important caveat that reputation and domain never change the verdict. That is well beyond what the structured fields convey.

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 one-line purpose, then structured into return semantics and an Args block; nearly every sentence carries information. It is slightly long and repeats parameter facts already implied in the header sentence, but there is no significant 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?

With annotations, an output schema, and a low-coverage input schema, the description fills every gap: cost model, verdict semantics, component coverage and failure statuses, and the non-scoring nature of reputation/domain. An agent has everything needed to call it correctly and interpret the result.

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%, so the description carries the full burden and does so: wallet format ('0x + 40 hex characters'), agent_id as an optional decimal ERC-8004 agentId the wallet claims, and domain as an optional self-declared website (e.g. example.com). All three parameters gain meaning the raw schema does not provide.

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?

Names a specific verb and resource (check a counterparty agent's EVM wallet) and enumerates exactly what is checked: OFAC SDN match, Base USDC/ETH balance, ERC-8004 identity, and open ERC-8004 feedback. It clearly distinguishes itself from generic siblings like check_entity, verify_wallet, or get_risk_score by scoping to agent wallets on Base.

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?

The opening 'Check a counterparty agent's EVM wallet in one call' and the closing 'Base only; EVM addresses only' tell the agent the situation and the hard limits. It does not, however, explicitly name when to prefer a sibling (e.g. sanctions_screen for a plain address) or state exclusions, so it falls short of a full when/when-not routing statement.

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

Resources