7702-sweeper-check

Check an EVM address for EIP-7702 delegations

check_7702_delegation

Read-onlyIdempotent

Checks whether an EVM address has an EIP-7702 delegation set across eight chains and returns the delegate contract per chain. Use before sending funds or when a wallet behaves oddly.

Instructions

Checks whether an EVM address has an EIP-7702 delegation set on Ethereum, Base, BNB Chain, Arbitrum One, OP Mainnet, Polygon PoS, Gnosis and Unichain, and returns the delegate contract per chain. Use it before sending funds to a wallet or reusing one, when a wallet behaves oddly (incoming funds vanish), or when an incident-response flow needs to know if a key was abused to install a sweeper. It is free and read-only. It sends the address to the hosted DevX API (https://sweeper-check.nextill-pos.workers.dev/api/basic), which reads each chain's account code and nonce over public RPC. No keys, no signatures, no payment. Returns: address, checked_at, delegated_on (chain keys where a delegation is set; empty means none found), and chains (one row per chain with kind eoa, eoa_delegated_7702 or contract, delegated, delegate, nonce, or error if that chain's RPC was unavailable), plus the URL and price of the paid full report. A delegation is normal when the owner upgraded to a smart wallet on purpose (MetaMask, Coinbase, Ambire and others). This tool does not judge whether the delegate is malicious. full_report_info describes the paid report that does (bytecode heuristics, source verification, risk level, advice).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "check_7702_delegation"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	EVM account to check: 0x followed by 40 hex characters, any letter case. One address per call. Example: 0x75e732608bc17b23d01f01728562ee844196dcc3

Output Schema

Name	Required	Description
`chains`	Yes
`address`	Yes
`checked_at`	Yes	ISO 8601 time of the check
`full_report`	No	URL of the paid full report for this address
`delegated_on`	Yes	chain keys where an EIP-7702 delegation is set
`full_report_price_usdc`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.0Oct 31, 2026

changedInput schema / properties / address / description

Previous value: -"EVM address, 0x..."New value: +"EVM account to check: 0x followed by 40 hex characters, any letter case. One address per call. Example: 0x75e732608bc17b23d01f01728562ee844196dcc3"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "address": {
+      "type": "string"
+    },
+    "chains": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "chain": {
+            "description": "short chain key, e.g. base",
+            "type": "string"
+          },
+          "chain_id": {
+            "type": "number"
+          },
+          "delegate": {
+            "description": "contract the account delegates to (EIP-7702), else null",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "delegated": {
+            "type": "boolean"
+          },
+          "error": {
+            "description": "set when that chain's RPC could not be read",
+            "type": "string"
+          },
+          "kind": {
+            "description": "eoa | eoa_delegated_7702 | contract",
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "nonce": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "chain",
+          "chain_id",
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "checked_at": {
+      "description": "ISO 8601 time of the check",
+      "type": "string"
+    },
+    "delegated_on": {
+      "description": "chain keys where an EIP-7702 delegation is set",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "full_report": {
+      "description": "URL of the paid full report for this address",
+      "type": "string"
+    },
+    "full_report_price_usdc": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "address",
+    "checked_at",
+    "delegated_on",
+    "chains"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the read-only/idempotent annotations by disclosing that the address is transmitted to a third-party hosted API URL, that reads happen over public RPC per chain, that no keys/signatures/payment are involved, and that per-chain RPC failures surface as error rows rather than failing the call.

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?

Purpose and triggers are front-loaded, and every clause carries information. Slightly over-long: the detailed return-shape walkthrough largely restates what the output schema already provides, and the closing 'full_report_info' sentence partly duplicates the earlier negative scoping.

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?

Covers everything an agent needs to decide and act: chain coverage, privacy implication of the external API, failure mode (error rows), interpretation of an empty 'delegated_on', and where the deeper paid analysis lives. With an output schema present, the extra return detail is a bonus rather than a gap.

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 single parameter is fully documented in the schema (pattern, format, example, one-per-call), so the baseline is 3. The description adds value by explaining where that address is sent and that it is read against each chain's account code and nonce, which the schema cannot convey.

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 and resource ('Checks whether an EVM address has an EIP-7702 delegation set') and enumerates the eight supported chains plus the per-chain delegate return. It also explicitly bounds itself against the sibling by saying it does not judge maliciousness and that 'full_report_info' describes the report that does.

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 concrete triggering conditions: before sending funds to a wallet, when a wallet behaves oddly (incoming funds vanish), or during incident response after key abuse. It adds a negative case (a delegation is often legitimate — MetaMask, Coinbase, Ambire upgrades) and routes the deeper question to the paid report.

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

Deploy Server