Skip to main content
Glama
verdixapi

verdix

Official
by verdixapi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

verdix-mcp: check an address before your agent sends it money

npm MCP Registry License: MIT

An MCP server that lets your AI agent check an EVM address on Base before sending it funds or approving a contract. It calls Verdix, which answers safe, caution or danger with the reasons. It checks:

  • OFAC sanctions

  • scam, phishing and exploit lists

  • address-poisoning lookalikes, built from a live watch of every token transfer on Base

  • contract age, code and provenance

  • burn addresses

Each check is paid per call in USDC on Base via x402, from your own wallet. There is no account, no API key and no subscription. Your key never leaves your machine, and a price cap is enforced before anything is signed.

"Send 50 USDC to 0x4c3f…9e21": the agent calls check_address_risk first, gets "verdict": "danger", "reasons": ["address_poisoning"], and stops to ask you.

Tool

What it does

Cost

check_address_risk(address, tier)

Verdix's verdict JSON, returned unchanged

quick $0.02 · standard $0.10 (default) · deep $0.50

get_pricing()

Current prices, your price cap, and your wallet's public address

free

What you need

  • Node.js 18 or newer (it runs through npx, so there's nothing to install).

  • A Base wallet holding a little USDC. You don't need ETH for gas: x402 payments are signed by you and settled on-chain by the payment facilitator. Use a dedicated wallet with a small balance (a few dollars) for your agent, not your main wallet.

Related MCP server: Crest Counterparty Intelligence

Safety

  • Your key stays on your machine. It is read from this server's environment and used only to sign each payment locally. It is never sent to Verdix or anywhere else, and never logged.

  • Price cap. VERDIX_MAX_PRICE_USD (default 0.10) is the most one call may cost. A call above it is refused before anything is signed. To allow the deep tier, set it to 0.50.

  • Only USDC on Base mainnet. Any other asset or network is refused.

  • You pay only for complete answers. If Verdix can't complete a check (a data source is down), it answers 503 and the payment is not settled.

Setup

Replace 0xYOUR_PRIVATE_KEY with the key of your dedicated Base wallet.

Claude Desktop: one-click extension

  1. Download verdix-mcp-<version>.mcpb from the latest release.

  2. In Claude Desktop, open Settings → Extensions and drag the file in.

  3. Click Install, then enter your wallet key and price cap.

The key is stored in your OS keychain. Node.js doesn't need to be installed, because Claude Desktop runs the extension with its own Node.js.

Claude Desktop: config file

Open Settings → Developer → Edit Config, which opens claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Add:

{
  "mcpServers": {
    "verdix": {
      "command": "npx",
      "args": ["-y", "verdix-mcp"],
      "env": {
        "VERDIX_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY",
        "VERDIX_MAX_PRICE_USD": "0.10"
      }
    }
  }
}

Then restart Claude Desktop.

Cursor

Put the same block in ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):

{
  "mcpServers": {
    "verdix": {
      "command": "npx",
      "args": ["-y", "verdix-mcp"],
      "env": {
        "VERDIX_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY",
        "VERDIX_MAX_PRICE_USD": "0.10"
      }
    }
  }
}

Don't commit a project-level .cursor/mcp.json that contains your key.

Claude Code

claude mcp add verdix -e VERDIX_PRIVATE_KEY=0xYOUR_PRIVATE_KEY -e VERDIX_MAX_PRICE_USD=0.10 -- npx -y verdix-mcp

Agent frameworks

Any MCP client that can launch a stdio server works. The command is npx -y verdix-mcp, with the environment variables below. Python example with the official MCP SDK:

from mcp import StdioServerParameters

verdix = StdioServerParameters(
    command="npx",
    args=["-y", "verdix-mcp"],
    env={"VERDIX_PRIVATE_KEY": os.environ["AGENT_WALLET_KEY"], "VERDIX_MAX_PRICE_USD": "0.10"},
)

Environment variables

Variable

Required

Default

Meaning

VERDIX_PRIVATE_KEY

for check_address_risk

none

Your Base wallet's private key (hex). EVM_PRIVATE_KEY is accepted too

VERDIX_MAX_PRICE_USD

no

0.10

Most one call may cost, in USD

VERDIX_API_URL

no

https://api.verdixapi.com

Only for testing against another deployment

What an answer looks like

check_address_risk returns Verdix's JSON exactly as the API sent it:

{
  "address": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
  "chain": "base",
  "tier": "quick",
  "price_usd": 0.02,
  "risk_score": 5,
  "verdict": "safe",
  "reasons": [],
  "checked": ["ofac", "scam_lists", "poisoning_watch", "onchain_age", "contract_code", "burn_list", "provenance"],
  "as_of": "2026-09-26T13:15:10.524501+00:00"
}

  • danger: sanctioned, a known scam, exploit or phishing address, an address-poisoning lookalike, a burn address and similar. Don't send funds.

  • caution: not enough evidence to call it safe. For example, it's new, an unverified contract, or one of the data sources was unavailable. Ask the user before sending.

  • safe: every check ran and found nothing.

The payment receipt (payer, on-chain transaction) is in the tool result's _meta under com.verdixapi/payment.

Troubleshooting

  • "No wallet configured": VERDIX_PRIVATE_KEY isn't set in this server's env block.

  • "Refusing to pay: … above your cap": raise VERDIX_MAX_PRICE_USD, or use a cheaper tier.

  • "Verdix did not accept the payment": the wallet probably has too little USDC on Base. Call get_pricing to see the wallet address to fund.

  • Answer with HTTP 503: a data source was down. You weren't charged; retry later.

License

MIT

Available Tools

2 tools
check_address_riskCheck an address before sending it fundsA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
tierNoAnalysis depth and price: quick ($0.02), standard ($0.10), deep ($0.50)standard
addressYesThe EVM address to check (the recipient, contract or counterparty)

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses that each call is paid via x402 from a configured wallet, capped by VERDIX_MAX_PRICE_USD, and that 503 responses are not charged. It also names the exact JSON verdict fields returned, which is essential since there is no output schema.

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?

Every sentence in the description earns its place: purpose first, then verdict semantics, billing, tiers, and failure behavior. It is dense but structured with clear markers (PAID, Tiers, 503) and front-loaded with the core screening action.

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?

The tool is safety-critical and paid, and the description covers verdict meanings, cost model, tier selection, where to get current prices, and the no-charge failure case. Since there is no output schema, documenting the exact JSON shape is necessary and done. No critical gap remains for an agent to call it safely and 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 100%, so the baseline is 3. The description still adds meaning by connecting tier choice to cost in USD, explaining the address as recipient/contract/counterparty in context, and describing the billing cap. The exact price figures are redundant with the schema's tier descriptions, but the cost model context is additive.

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 description opens with a specific verb and resource: 'Screen an EVM address on Base before sending it money or interacting with it.' It clearly distinguishes itself from get_pricing by naming that sibling as the way to get current prices rather than advertising pricing itself.

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?

It provides explicit action guidance: do not send funds on 'danger', confirm with the user first on 'caution', and treat 503 as a harmless no-charge failure. It also routes price lookups to the sibling get_pricing, establishing a clear division of labor.

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

get_pricingVerdix prices per tierA
Read-only

Free. Current Verdix price per tier (USDC on Base, via x402), the payment recipient, your configured max price per call, and whether a wallet is configured (with its public address, so it can be funded). Nothing is signed or paid.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: 'Nothing is signed or paid' and 'Free', which explains the lack of side effects and cost. This goes beyond the annotation flags and clarifies user expectations, though it doesn't cover potential rate limits or response format details.

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?

The description is a single, information-dense sentence. It front-loads 'Free' and 'Current Verdix price per tier', then lists the specific return values and closes with a behavioral note. Every word earns its place with no redundancy.

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 zero parameters, no output schema, and read-only annotations, the description fully covers what an agent needs: the purpose, the return contents, and the absence of side effects. The sibling tool is distinct, and no further context is necessary for correct invocation.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it does not attempt to; it purely describes the return data, which is appropriate for a no-argument getter.

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 description clearly states the verb 'get', the resource 'pricing', and enumerates the exact data returned: price per tier, payment recipient, max price per call, and wallet configuration. It distinguishes itself from the sibling 'check_address_risk' implicitly by focusing on pricing rather than risk assessment.

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 description provides clear context for when to use the tool (when pricing or payment details are needed) but does not explicitly mention alternatives or exclusion conditions. The sibling 'check_address_risk' is distinct enough that the agent can infer when to use which, but the guidance is not fully explicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.1
    • First observedcheck_address_risk
    • First observedget_pricing
Deploy Server
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

TDQS

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools serve completely distinct purposes: one performs the core risk screening action, the other provides pricing information. There is no overlap or ambiguity in their functions.

Naming Consistency5/5

Both tool names follow the consistent verb_noun pattern with lowercase and underscores (check_address_risk, get_pricing). The naming is clear and predictable.

Tool Count3/5

With only 2 tools, the surface is on the thin side, but it matches the narrow scope of the server, which focuses on address risk screening and its associated pricing. The count is borderline but not unreasonable.

Completeness4/5

The server covers the core operation of checking address risk and provides a necessary auxiliary tool for pricing. While there are no tools for bulk checks or history, the primary use case is fully addressed, leaving only minor gaps.

Resources

Related MCP Connectors

Related MCP Servers

  • SENTINEL

    teodorofodocrispin-cmyk
    F
    license
    A
    quality
    B
    maintenance
    Agent-Level Transaction Safety Oracle. Before an AI agent signs a blockchain transaction, it returns a SAFE/UNSAFE verdict with a SENTINEL Score (AAA-D) and risk flags. Pay-per-call $0.005 USDC via x402 on Base.
    1
    -

  • address-intel-api

    TKtokyo
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides counterparty risk checks for any EVM address, returning malicious-history flags, tiered risk scoring, and plain-language summaries via x402 payment.
    -