Skip to main content
Glama

Wallet risk check (OFAC + on-chain)

wallet_risk_check
Read-only

Answers "Is it safe to send money to this address?" before an agent pays an x402 payTo, a vendor, a user or another agent, and "Who is behind this address?". Checks, on Base or Ethereum: whether the address is on the US Treasury OFAC SDN or Consolidated lists, and whether anything controlling it is (the owner of a contract, the owners of a Safe multisig, an EIP-7702 delegate, a proxy implementation); what it is (a person's wallet, smart wallet, Safe multisig, token contract, proxy or other contract); how many transactions it has sent; its ETH and USDC balances; and flags a never-used wallet or a token contract (sending funds to one usually loses them). Returns a verdict (high_risk, caution, no_flags), a 0-100 risk score and the reasons, with an explorer link. Read live from the chain; OFAC lists refreshed every 12 hours. A screening aid, not legal advice. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.005 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
chainNo"base" (default) or "ethereum".base
addressYesThe wallet or contract to check, e.g. the payTo of an x402 payment request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
      +  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only/open-world/destructive flags, and the description still adds substantial non-obvious behavior: $0.005 USDC x402 cost per call, billing only on returned results, 12-hour OFAC refresh cadence, live on-chain reads, and an explicit 'screening aid, not legal advice' caveat. This is exactly the kind of billing and freshness context annotations cannot 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 core question and the trigger scenario, and each sentence carries real information (what is checked, what is returned, pricing). It is a dense run-on paragraph with stacked clauses, but little is genuinely 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?

No output schema exists, so the description carries the return contract and it does: verdict values (high_risk, caution, no_flags), a 0-100 risk score with reasons, and an explorer link. Combined with the stated inputs, cost, and freshness, an agent has everything needed to decide and call correctly.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds mild context by tying the address to a payTo target and by naming the two chains it can query, but the parameter semantics (0x-address pattern, enum values, default) are already fully carried by 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 question it answers ('Is it safe to send money to this address?') plus the resource checked (an address) and the chains covered. It clearly distinguishes itself from siblings like token_risk_check and sanctions_screen by scoping to a wallet/contract address and enumerating exactly what it inspects (OFAC SDN/Consolidated, ownership, multisig, delegate, proxy, tx count, balances).

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 concrete trigger: use it before an agent pays an x402 payTo, a vendor, a user or another agent. It also discloses the pricing/settlement model (charged only when a result is returned; 400/4xx/5xx not settled). It stops short of naming alternatives (e.g. when to prefer token_risk_check or counterparty_check) or when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources