Skip to main content
Glama
verdixapi

verdix

Official
by verdixapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Check an address before sending it funds

check_address_risk

Screen an EVM address on Base before sending funds or interacting: get Verdix's safe, caution, or danger verdict with risk score and reasons.

Instructions

Screen an EVM address on Base before sending it money or interacting with it. Returns Verdix's verdict JSON unchanged: verdict (safe | caution | danger), risk_score (0-100), reasons, checked, tier, price_usd, as_of. 'danger' means sanctioned, a known scam/exploit/phishing address, an address-poisoning lookalike, a burn address or similar - do not send funds. 'caution' means not enough evidence to call it safe (new, unverified, or a data source was unavailable) - confirm with the user first. Every tier runs OFAC sanctions, scam/phishing/exploit lists, address-poisoning lookalikes, burn-address and contract/deployer checks; quick adds a fast address-age read, standard and deep run deeper on-chain behaviour analysis instead (deep runs the same checks as standard today - pick it for high-value or first-time transfers, not for extra checks). PAID: each call costs USDC on Base via x402, paid from the wallet configured in this server (VERDIX_PRIVATE_KEY), never more than VERDIX_MAX_PRICE_USD. Tiers: quick ($0.02), standard ($0.10, default), deep ($0.50); call get_pricing for current prices. A 503 answer (data unavailable) is not charged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoAnalysis depth and price: quick ($0.02, fast address-age read), standard ($0.10, deeper on-chain behaviour analysis, recommended default), deep ($0.50, same checks as standard, for high-value or first-time transfers)standard
addressYesThe EVM address to check (the recipient, contract or counterparty)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tier / description
      Previous value: -"Analysis depth and price: quick ($0.02), standard ($0.10), deep ($0.50)"New value: +"Analysis depth and price: quick ($0.02, fast address-age read), standard ($0.10, deeper on-chain behaviour analysis, recommended default), deep ($0.50, same checks as standard, for high-value or first-time transfers)"
  2. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Discloses far beyond the annotations: the paid x402/USDC-on-Base model, the wallet and cap used for payment (VERDIX_PRIVATE_KEY, VERDIX_MAX_PRICE_USD), per-tier prices, the default tier, and that a 503 data-unavailable answer is not charged. This covers cost, side effects, and failure semantics that annotations alone (readOnlyHint=false, openWorldHint=true, idempotentHint=false) do not explain.

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-loads the core action and the verdict semantics before the pricing detail, and every clause carries information (verdict meanings, tier behavior, payment mechanics, 503 handling). It is dense and long, but not padded with 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 no output schema, the description enumerates the returned fields (verdict, risk_score, reasons, checked, tier, price_usd, as_of) and interprets the two actionable verdicts. Combined with the payment and failure-mode details, an agent has everything needed to call and interpret this tool.

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 100%, so both parameters are already documented, giving a baseline of 3. The description adds genuine meaning on top by clarifying that 'deep' currently runs the same checks as 'standard' and is a choice about transfer value rather than extra coverage, which the schema's tier description only partially conveys.

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 (screen), resource (EVM address on Base), and the decision context (before sending funds or interacting). It also implicitly distinguishes itself from the sibling tier-specific tools by explaining that the tier parameter selects quick/standard/deep within this one call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance: call before sending funds, treat 'danger' as do-not-send, treat 'caution' as confirm-with-user, and pick 'deep' for high-value or first-time transfers rather than for extra checks. It also routes to get_pricing for current prices, naming the alternative.

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

Deploy Server

Other Tools