Skip to main content
Glama
Sign In
devx-agent

devx-address-poisoning-check

by devx-agent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Address Poisoning Check

Is this the address you meant? Address poisoning plants a lookalike address (same first and last characters, different middle) in a wallet's history with a zero-value, dust or fake-token transfer, and waits for the owner (or their AI agent) to copy it. Bitquery counted about $76M stolen on Ethereum alone in the 12 months to July 2026.

This repo has three pieces, all read-only (we never ask for keys and never move funds):

What

Cost

CLI / stdio MCP devx-address-poisoning-check

Offline: is the recipient a lookalike of any address you trust? Is its EIP-55 checksum valid? Nothing leaves your machine.

free

Remote MCP https://address-poisoning-check.nextill-pos.workers.dev/mcp

Same offline check as a hosted MCP tool

free

HTTP API GET /v1/check?from=<sender>&to=<recipient>

On-chain: scans the sender's real transfer history (Ethereum + Base, optional Avalanche) and flags lookalikes of real counterparties, zero-value / dust / fake-token poisoning transfers (with tx hashes), recipients that only ever appeared through such transfers, and senders that were already poisoned. Returns ok | caution | danger and the address you probably meant.

0.005 USDC via x402 on Base

Live: https://address-poisoning-check.nextill-pos.workers.dev

CLI

npx devx-address-poisoning-check 0xd9A1C3788D81257612E2581A6ea0aDa244853a91 --known 0xd9A1b0B1e1aE382DbDc898Ea68012FfcB2853a91
# DANGER: Looks like 0xd9a1...3a91 (same first 4 / last 6 hex chars) but is a different address. Classic address-poisoning lookalike.

Exit code 2 on danger, so it can gate scripts and agent payment flows.

Related MCP server: Cybercentry MCP Server

MCP

Claude Desktop / Cursor (stdio):

{ "mcpServers": { "address-poisoning-check": { "command": "npx", "args": ["-y", "devx-address-poisoning-check", "mcp"] } } }

Or remote (streamable HTTP): https://address-poisoning-check.nextill-pos.workers.dev/mcp

Tools: check_recipient_lookalike (free), onchain_check_info (how to buy the on-chain check; does not pay).

Paid on-chain check (x402)

GET https://address-poisoning-check.nextill-pos.workers.dev/v1/check?from=0x...&to=0x...[&chains=ethereum,base,avalanche]

  • Answers 402 with an x402 v1 body (X-PAYMENT, network base) and a v2 PAYMENT-REQUIRED header (PAYMENT-SIGNATURE, eip155:8453). Both work.

  • 5000 atomic USDC (0.005 USDC) to 0xB3cDDccEe6B150c8efFD55B961afc0Ecefe7f247, settled through the Coinbase CDP facilitator, listed in the CDP x402 Bazaar.

  • Settled only after the report is produced; bad input or data-source errors are not charged.

  • Data: Ethereum/Avalanche via the Routescan explorer API (last 300 token transfers + 150 transactions of the sender); Base via the Coinbase CDP SQL API (last 14 days of all ERC-20 transfers, including unknown/fake tokens), falling back to public RPC logs for a shorter window. Typical paid response: about 1-2 s. Data collection has a 3.5 s budget; if a source is slow you still get a report with "partial": true and the scanned window stated per chain in chains[].window. It is a heuristic over a window of public data: always confirm the full address with the payee.

Example (the May 2024 $68M WBTC case): from=0x1E227979f0b5BC691a70DEAed2e0F39a6F538FD5&to=0xd9A1C3788D81257612E2581A6ea0aDa244853a91 returns danger / possibly_already_poisoned: the victim did send real value to that address, but it first appeared in their history through a zero-value transfer.

OpenAPI: /openapi.json · Terms: /terms

Related DevX tools

Layout

  • cli/: npm package devx-address-poisoning-check (CLI + stdio MCP), npm test

  • worker/: the Cloudflare Worker behind the hosted API (npm run build)

MIT. Made by DevX · madebydevx@gmail.com

Available Tools

2 tools
check_recipient_lookalikeCheck a recipient for address poisoningA
Read-onlyIdempotent
Inspect

Compares the EVM address you are about to pay with addresses you trust and checks its EIP-55 checksum, to catch address-poisoning lookalikes before a transfer. Address poisoning: attackers send tiny or zero-value transfers from an address that shares the first and last hex characters with one of your real payees, hoping you copy it from your history. Use this tool before every transfer to an address that was pasted or copied, especially from wallet or explorer history. Offline and deterministic: nothing leaves the machine, no RPC calls, no keys, no signing. Rules: a lookalike shares at least 3 leading and 3 trailing hex characters with a trusted address (or 8 in total with at least 2 on each side) but is not identical. A mixed-case address whose EIP-55 checksum fails is treated as altered or mistyped. All-lowercase or all-uppercase input has no checksum (checksum_valid null). Returns: verdict (match = identical to a trusted address; danger = lookalike of a trusted address or invalid checksum: do not send; unknown = no match and no lookalike, which only means it is not similar to the addresses you supplied), a note, checksum_valid, compared, matches, lookalikes (address, shared_prefix, shared_suffix, shown_as) and onchain_check (URL of the paid history-based check). This tool only knows the addresses you pass in. To scan the sending wallet's real on-chain transfer history for poisoning transfers, see onchain_check_info.

NameRequiredDescriptionDefault
toYesThe recipient you are about to send to: 0x followed by 40 hex characters. Pass it exactly as copied, keeping its letter case, so the EIP-55 checksum can be checked.
knownNoUp to 200 addresses you trust, for example the address book and previous real payees, each 0x + 40 hex. With an empty list only the checksum is checked.

Output Schema

NameRequiredDescription
toYesrecipient, lowercased
noteYes
matchesYes
verdictYes
comparedYesnumber of trusted addresses compared
lookalikesYes
onchain_checkYes
checksum_validYestrue valid, false invalid, null when the input has no checksum (single case)

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations by disclosing that the tool is offline and deterministic with no RPC, keys, or signing, and by spelling out detection rules (3 leading + 3 trailing shared hex, or 8 total with 2 per side) and how a failed mixed-case checksum is treated. It also explains the epistemic limit of the 'unknown' verdict, which prevents a false sense of safety — context the readOnly/idempotent annotations cannot supply.

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 purpose, then the threat model, then the call-to-action, then rules and return values — a logical order. The 'Returns:' sentence enumerating verdict, note, checksum_valid, compared, matches, lookalikes and onchain_check is largely redundant with the output schema and could be trimmed to just the verdict semantics.

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?

For a two-parameter safety tool, everything needed to call it correctly and interpret the result is present: checksum caveats for lowercase/uppercase input, the meaning of each verdict, and the explicit boundary that the tool only compares against supplied addresses. No output-schema explanation is required, and the description still clarifies the semantics of the key verdict field.

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 baseline is 3; the description adds real meaning by framing `known` as the trusted-address set (address book, prior real payees) and by stating that the result's usefulness is bounded by what was supplied there, which shapes how the agent populates the list. Case preservation is repeated from the schema, so it is not a full 5.

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 concrete verb and resource — comparing the recipient EVM address against trusted addresses and checking the EIP-55 checksum — plus the risk it defends against (address poisoning). It is clearly separable from the only sibling, onchain_check_info, because the scope ('only knows the addresses you pass in') is stated explicitly.

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?

Gives an explicit trigger ('before every transfer to an address that was pasted or copied, especially from wallet or explorer history'), the exclusion ('only knows the addresses you pass in'), and routes the agent to the alternative ('To scan the sending wallet's real on-chain transfer history ... see onchain_check_info'). Nothing is left to inference.

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

onchain_check_infoHow to buy the on-chain poisoning checkA
Read-onlyIdempotent
Inspect

Returns the endpoint, price and payment method of the optional paid hosted check. It does not call the API and does not pay or sign anything. The paid check reads the sending wallet's real transfer history on Ethereum and Base (optionally Avalanche), finds poisoning transfers (zero-value, dust or fake-token transfers from lookalike addresses) and returns a verdict ok | caution | danger, the address you probably meant, and evidence transaction hashes. It costs 0.005 USDC on Base via x402. Use it when you have no trusted address list to pass to check_recipient_lookalike, or when check_recipient_lookalike returns unknown for a recipient copied from transaction history. Returns: method, url_template, price_usdc, network, asset, protocol, chains, settles and docs.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
docsYes
assetYes
chainsYes
methodYes
networkYes
settlesYes
protocolYes
price_usdcYes
url_templateYes

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (read-only, non-destructive, idempotent), the description clarifies that this tool does not call the API and does not pay or sign anything. It also discloses the paid check's behavior, verdict values, cost (0.005 USDC on Base via x402), and evidence returned, giving the agent a complete picture of side effects and external dependencies.

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?

The description is front-loaded with the core purpose and each sentence carries useful information about behavior, cost, and usage. The final sentence listing return fields is slightly redundant given the output schema, but overall it is tight and well-structured.

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 zero parameters, full annotations, and an output schema, the description covers everything an agent needs: what the tool returns, what it does not do, the paid check's cost and behavior, and when to use it instead of the sibling 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?

The tool has zero parameters, so parameter semantics are not applicable. The description does not need to explain parameters, and the baseline of 4 applies.

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 states a specific verb and resource: it returns the endpoint, price, and payment method of the optional paid hosted check. It also explicitly distinguishes this tool from the sibling by naming check_recipient_lookalike and explaining the paid check's purpose.

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 gives explicit when-to-use conditions: 'Use it when you have no trusted address list to pass to check_recipient_lookalike, or when check_recipient_lookalike returns unknown for a recipient copied from transaction history.' This names both the trigger and the alternative tool.

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 updatesv1.1.0
    • Changedcheck_recipient_lookalike3 fields changed
      • changedInput schema / properties / known / description
        Previous value: -"trusted addresses: address book, previous real payees"New value: +"Up to 200 addresses you trust, for example the address book and previous real payees, each 0x + 40 hex. With an empty list only the checksum is checked."
      • changedInput schema / properties / to / description
        Previous value: -"recipient you are about to pay"New value: +"The recipient you are about to send to: 0x followed by 40 hex characters. Pass it exactly as copied, keeping its letter case, so the EIP-55 checksum can be checked."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "checksum_valid": {
+      "description": "true valid, false invalid, null when the input has no checksum (single case)",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "compared": {
+      "description": "number of trusted addresses compared",
+      "type": "number"
+    },
+    "lookalikes": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "address": {
+            "type": "string"
+          },
+          "shared_prefix": {
+            "type": "number"
+          },
+          "shared_suffix": {
+            "type": "number"
+          },
+          "shown_as": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "address",
+          "shared_prefix",
+          "shared_suffix",
+          "shown_as"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "matches": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": "string"
+    },
+    "onchain_check": {
+      "type": "string"
+    },
+    "to": {
+      "description": "recipient, lowercased",
+      "type": "string"
+    },
+    "verdict": {
+      "enum": [
+        "match",
+        "danger",
+        "unknown"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "to",
+    "checksum_valid",
+    "compared",
+    "matches",
+    "lookalikes",
+    "verdict",
+    "note",
+    "onchain_check"
+  ],
+  "type": "object"
+}
    • Changedonchain_check_info1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "asset": {
+      "type": "string"
+    },
+    "chains": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "docs": {
+      "type": "string"
+    },
+    "method": {
+      "type": "string"
+    },
+    "network": {
+      "type": "string"
+    },
+    "price_usdc": {
+      "type": "number"
+    },
+    "protocol": {
+      "type": "string"
+    },
+    "settles": {
+      "type": "string"
+    },
+    "url_template": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "method",
+    "url_template",
+    "price_usdc",
+    "network",
+    "asset",
+    "protocol",
+    "chains",
+    "settles",
+    "docs"
+  ],
+  "type": "object"
+}
  2. 2 tool updatesv0.1.0
    • First observedcheck_recipient_lookalike
    • First observedonchain_check_info
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 have clearly separate roles: one performs the offline lookalike/checksum check, while the other only returns metadata about an optional paid on-chain service. Their names and descriptions make it hard to confuse the action tool with the informational tool.

Naming Consistency4/5

Both names use snake_case and are descriptive, but they do not follow a uniform verb_noun pattern: check_recipient_lookalike is action-oriented, while onchain_check_info is an info getter. This is a minor deviation rather than inconsistent style.

Tool Count3/5

Only two tools are provided, which feels thin even for a narrow pre-transfer address-checking server. The count is defensible because one tool does the main check and the other explains an optional paid alternative, but the surface is borderline minimal.

Completeness3/5

The core offline lookalike and checksum check is covered, but the on-chain history scan is not exposed as a callable tool, only as endpoint metadata. That is a notable gap for a server framed around address-poisoning detection, requiring an external paid workflow to complete the lifecycle.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • pathguard-mcp

    Utee
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP-compatible AI agents to scan crypto transactions for scam addresses, clipboard-hijack patterns, and typos, as well as report scam addresses and check usage, directly in conversation.
    -
  • Cybercentry MCP Server by Cybercentry

    Cybercentry MCP Serverofficial

    Cybercentry
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to perform pay-per-call security verification of wallets, tokens, contracts, dApps, agents, and more via a remote endpoint with no installation.
    2
    MIT

  • web3-risk-mcp

    MelvTheGoat
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to assess the risk of crypto wallets, tokens, and smart contracts by providing read-only on-chain analysis, 0-100 risk scoring with explanations, fund tracing, and contract inspection before interaction.
    6
    MIT

  • rugradar

    Darkjay123
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to check whether a crypto token, link, or forwarded "gem" message is a scam by running contract rules, live test trades, creator history, and market data across 64 networks, returning plain-English or Pidgin verdicts. Also supports scanning messages, reviewing a token's past checks, and explaining individual findings.
    5
    MIT