Skip to main content
Glama

EVM counterparty risk

counterparty_risk_evm
Read-onlyIdempotent

Counterparty-risk verdict (allow, warn or block, with reasons) for an EVM address on Base, Ethereum, OP Mainnet, Arbitrum or Base Sepolia, for use before paying, approving or trusting it. Checks the OFAC SDN list and the Chainalysis sanctions oracle, account age, EOA or contract, EIP-7702 delegation, upgradeable proxies and code changes in the last 72 h, and token controls (mint, blacklist, pause, fees, owner). Price: $0.02 USDC per call (x402).

Input Schema

NameRequiredDescriptionDefault
chainYesEVM chain: ethereum, base, base-sepolia, optimism, arbitrum
addressYes20-byte hex address, 0x-prefixed (checksum optional)
minAgeDaysNowarn when the address is younger than this (default 7)
codeWindowHoursNowarn when code or proxy implementation changed within this window (default 72)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), but the description adds traits annotations cannot express: a $0.02 USDC per-call price via x402 (a hard prerequisite before invocation) and the verdict taxonomy itself. It also discloses the actual evidence sources (OFAC SDN, Chainalysis oracle) and detection windows, so the agent knows what a 'block' really means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph, front-loaded with the output, identifiers and chain scope, then the use case, then the checks, then price. The long list of checks is the core value proposition and each item earns its place by signaling verdict drivers.

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, and the description compensates by stating the return shape ('allow, warn or block, with reasons'). With the cost, the evidence sources and the chain set all present, 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% and both optional parameters carry their own defaults and bounds, so the schema does the work here. The description only loosely gestures at them ('account age', 'code changes in the last 72 h') without naming minAgeDays or codeWindowHours, so it adds nothing an agent could not read from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — a counterparty-risk verdict (allow/warn/block) for an EVM address — and enumerates the five supported chains, which separates it from the NEAR sibling by chain scope. It does not explicitly differentiate itself from enrich_evm_address, so sibling routing relies on the agent inferring 'verdict' vs 'enrichment'.

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?

"For use before paying, approving or trusting it" gives a clear, concrete decision context, which is exactly the trigger an agent needs. There are no exclusions and no named alternatives, so the agent gets positive guidance but no guidance on when to pick a sibling instead.

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