Web3MCP Documentation • Protocol Guide

Smart Contracts As Agent Tools.

Web3MCP is an open EVM standard for publishing contract tools under an ENS name. The SDK discovers and verifies protocols, executes reads, simulates writes, and hands final approval to the user's wallet.

ENS-native

The protocol owns its registry.

Fail-closed

Invalid manifests stop at discovery.

User-signed

The model never sees a private key.

flowchart LR Agent[AI agent] --> Host[Generic MCP host] Host --> ENS[ENS manifest + digest] Host --> RPC[EVM RPC] Host --> Wallet[User wallet] ENS --> Validate[Validate schema + trust] RPC --> Validate Validate --> Read[Read tools] Validate --> Sim[Simulate writes] Sim --> Wallet style Agent fill:#111316,color:#fff style Wallet fill:#D97706,color:#fff style ENS fill:#DBEAFE,color:#111316 style Validate fill:#D1FAE5,color:#111316 style Sim fill:#FEF3C7,color:#111316

Start here

A protocol integration in five steps.

  1. 01Choose an ENS nameUse a normalized name your protocol controls.
  2. 02Describe contractsAdd lowercase aliases and deployed addresses for one EVM chain.
  3. 03Declare toolsExpose read calls and write sequences with explicit inputs.
  4. 04Publish two recordsWrite the manifest and its keccak256 digest to ENS text records.
  5. 05Connect a generic hostCall discover(name); users approve writes in their own wallet.
Important boundary: a publisher supplies metadata and contract bindings; the host remains generic. Do not put private keys, seed phrases, API keys, or protocol-specific signing logic in a manifest.

Agent integrations

Install the tools for your agent.

The repository provides the same Web3MCP plugin for Claude Code and Codex. Add this repository as a marketplace, install web3mcp@evm-web3mcp, then restart the agent so the bundled MCP server, signing page, and skill are loaded.

Claude Code

Available

Install the web3mcp plugin from the evm-web3mcp marketplace.

CLI

/plugin marketplace add Team-Managed/EVM-Web3MCP
/plugin install web3mcp@evm-web3mcp

Interactive UI

  1. 1. Run /plugin in Claude Code.
  2. 2. Open Marketplaces and choose Add marketplace.
  3. 3. Enter Team-Managed/EVM-Web3MCP, then select web3mcp and install it.

Start a new Claude Code session after installation so the skill and MCP configuration are loaded.

Codex

MCP setup

Codex installs the same marketplace plugin as Claude Code, including the bundled server, local signing page, and Codex skill.

CLI

codex plugin marketplace add Team-Managed/EVM-Web3MCP
codex plugin add web3mcp@evm-web3mcp

Restart Codex. To ask before non-read tools, set this in ~/.codex/config.toml:

[plugins."web3mcp@evm-web3mcp".mcp_servers.web3mcp]
default_tools_approval_mode = "writes"

UI / manual setup

  1. 1. Open Codex and run /plugins to open the plugin browser.
  2. 2. Add Team-Managed/EVM-Web3MCP as a marketplace.
  3. 3. Install web3mcp, then restart Codex.

The plugin uses Sepolia by default. Set your public wallet address or ENS name as WEB3MCP_ACCOUNT when preparing writes; never provide a private key.

Developer tools

Use the SDK. Build an agent-ready protocol.

The SDK is for hosts that want direct control over discovery and execution. The builder skill is for turning an existing contract into a checked, publishable Web3MCP manifest without handing an agent a private key.

Install the SDK

Use a viem public client. The SDK discovers ENS manifests, executes reads, and prepares simulated writes for your own wallet boundary.

npm install @web3mcp/evm viem
import { createPublicClient, http } from "viem";
import { sepolia } from "viem/chains";
import { discover, executeRead, prepareWrite } from "@web3mcp/evm";

const client = createPublicClient({ chain: sepolia, transport: http() });
const protocol = await discover(client, "agentswap.web3mcp.eth");
const quote = await executeRead(client, protocol, "quote_eth_to_usdc", { amount: "0.01" }); // such as "250.663701 USDC"
const minUsdc = (parseFloat(String(quote)) * 0.99).toFixed(6); // accept about 1% less

const wallet = "0xYourWallet";
const write = await prepareWrite(client, protocol, "eth_to_usdc", {
  amount: "0.01", min_usdc: minUsdc, recipient: wallet
}, wallet);

The SDK never signs. Pass the returned calls to the user's wallet.

Build and publish

Use the web3mcp-build skill for an existing contract, a new contract, an adapter, or a manifest update.

# Format-only validation
node <skill-folder>/scripts/web3mcp-publish.mjs validate vault.myprotocol.eth.json

# Validate against the chain and print ENS records
node <skill-folder>/scripts/web3mcp-publish.mjs check vault.myprotocol.eth.json

# Discover and verify an already-published name
node <skill-folder>/scripts/web3mcp-publish.mjs check vault.myprotocol.eth
  1. 1. Read the contract and list user-facing reads and writes.
  2. 2. Write the manifest and run validate.
  3. 3. Run check, review trust levels and the two ENS records, then publish with the user's wallet or Foundry keystore.

Never put private keys, seed phrases, admin functions, or wallet files in the manifest or environment.

01 / Publication

Publish one manifest to ENS.

Store two text records on the protocol's ENS name. The manifest describes every contract and tool; the digest is the keccak256 hash of the exact manifest record bytes. ENS is the source of truth, while indexes are only caches.

org.web3mcp.manifest

The manifest JSON.

org.web3mcp.digest

0x-prefixed keccak256 digest.

{
  "web3mcp": "0.1-evm",
  "chainId": 11155111,
  "name": "vault.web3mcp-demo.eth",
  "contracts": {
    "vault": "0x1111111111111111111111111111111111111111",
    "usdc": "0x2222222222222222222222222222222222222222"
  },
  "tools": [
    {
      "name": "total_assets",
      "description": "Read the vault asset balance",
      "kind": "read",
      "inputs": {},
      "call": {
        "contract": "vault",
        "function": "function totalAssets() view returns (uint256)",
        "args": []
      }
    }
  ]
}

The digest must be computed from the exact bytes stored in the manifest record. Changing whitespace or ordering changes the digest. A host rejects a mismatch before parsing or exposing tools.

sequenceDiagram participant P as Protocol participant E as ENS participant H as Host P->>P: Serialize manifest exactly P->>E: Write org.web3mcp.manifest P->>E: Write keccak256 digest H->>E: Read both records H->>H: Compare exact bytes and digest H-->>P: Expose only verified tools

02 / Manifest

Keep tools explicit and small.

A manifest contains 1–32 uniquely named tools. Names are lowercase identifiers. Every contract reference is an alias, and every argument is either a validated literal or a declared binding.

Read tools

One call to a view or pure function. Reads are gasless and expose readOnlyHint over MCP.

Write tools

One to four state-changing calls or ERC-20 approvals, simulated together before signing.

Supported input types are address, amount, ether, uint256, bool, bytes32, and string. Read tools may also declare formatted outputs or a non-view dryRun. Bindings include $input.name, $sender, and $contracts.alias.

FieldRules
nameLowercase identifier, 1–32 characters, unique in the manifest.
descriptionRequired, human-readable, maximum 500 characters.
contractsLowercase aliases mapped to 20-byte hexadecimal addresses.
stepsWrite tools contain 1–4 calls or ERC-20 approvals.

Write tool example

Approvals and calls are one declared sequence. The host resolves bindings, validates the ABI argument count and mutability, then simulates the sequence atomically.

{
  "name": "deposit",
  "description": "Deposit tokens into the vault",
  "kind": "write",
  "inputs": {
    "amount": { "type": "amount", "token": "usdc" }
  },
  "steps": [
    { "approve": {
      "token": "usdc",
      "spender": "vault",
      "amount": "$input.amount"
    } },
    { "call": {
      "contract": "vault",
      "function": "function deposit(uint256 amount)",
      "args": ["$input.amount"]
    } }
  ]
}
flowchart TD A[Resolve ENS name] --> B[Read manifest + digest] B --> C{Digest matches?} C -- No --> X[Fail closed] C -- Yes --> D[Strict schema validation] D --> E{References and ABI safe?} E -- No --> X E -- Yes --> F[Check code + selectors] F --> G[Record code fingerprint] G --> H[Register MCP tools] style C fill:#FEF3C7,color:#111316 style X fill:#FEE2E2,color:#991B1B style D fill:#DBEAFE,color:#111316 style H fill:#D1FAE5,color:#111316

03 / Discovery

Verify before exposing anything.

The host resolves ENS, checks the digest, validates the schema, confirms contract code and selectors, and records fingerprints. Unknown fields, aliases, bindings, or unsafe read calls fail discovery.

Owner-verified

The contract’s ENS primary name points back to the publishing name.

Name-only

The publishing name is the only authority, so the host asks for extra confirmation.

Cache-safe

Arkiv can help find a protocol, but the host always re-reads and verifies ENS.

Discovery checklist

  • Resolve the ENS name and read both records
  • Verify the manifest digest before parsing
  • Reject unknown fields and invalid references
  • Confirm deployed bytecode and function selectors
  • Record code fingerprints, including proxy implementations
  • Label contracts Owner-verified or Name-only
flowchart LR Contract[Contract address] --> Primary{Primary ENS name points to publisher?} Primary -- Yes --> Owner[Owner-verified] Primary -- No --> Name[Name-only] Owner --> Normal[Normal confirmation] Name --> Extra[Extra user confirmation] style Owner fill:#D9F7E5,color:#111316 style Name fill:#F9E2B8,color:#111316 style Extra fill:#DBEAFE,color:#111316 style Normal fill:#D1FAE5,color:#111316

04 / Execution

Simulate first. Sign last.

The host builds every write, simulates the complete sequence with eth_simulateV1, and shows decoded calls, gas, and exact balance changes. It re-checks fingerprints immediately before asking the wallet to sign.

Execution boundary

Agent intent → ENS discovery → ABI validation → state simulation → user wallet approval

The LLM never signs and never receives a private key.

Before simulation

Validate calldata, bindings, code fingerprints, and wallet context.

After simulation

Show calls, gas, approvals, and exact token/native balance deltas.

At signing

Hand off to the user's wallet; use EIP-5792 batching where supported.

sequenceDiagram participant A as Agent participant H as Host participant S as Simulation participant U as User wallet A->>H: call(tx_namespace_tool, args) H->>H: Build calls + approvals H->>S: eth_simulateV1 S-->>H: Reverts, gas, balance deltas H-->>U: Show decoded transaction U->>U: Review and approve U-->>H: Wallet signature Note over A,U: The agent never holds a private key rect rgb(255, 251, 235) H->>S: Show exact balance deltas end

05 / MCP

One generic host, every protocol.

The MCP server starts with discover(name) and call(tool, args). Discovered tools use <namespace>_<tool> for reads and tx_<namespace>_<tool> for writes. Descriptions are treated as untrusted publisher text.

discover(name)

Loads and validates a manifest, registers its tools, and notifies the client that the tool list changed.

call(tool, args)

Invokes a discovered read or prepares a write for simulation and wallet approval.

flowchart LR Discover["discover(name)"] --> Manifest["Validated manifest"] Manifest --> List["Tool list changed"] List --> Read["namespace_tool"] List --> Write["tx_namespace_tool"] Read --> Call["call(tool, args)"] Write --> Call Call --> Boundary["Read result or wallet boundary"] style Discover fill:#DBEAFE,color:#111316 style Read fill:#D1FAE5,color:#111316 style Write fill:#FEF3C7,color:#111316 style Boundary fill:#FCE7F3,color:#111316

What is implemented today?

The current SDK discovers manifests from ENS, verifies their digest and contract code, labels trust, executes reads, prepares and simulates writes, and returns a wallet signing handoff. The MCP server also reports write status. The protocol remains a draft, so use the security and limitations guidance when moving beyond the tested Sepolia flow.

06 / Security invariants

Security invariants by design.

These are the protocol guarantees and intended trust boundaries. They describe the design target; unfinished execution features remain clearly marked in the implementation status above.

Serverless

Zero Infrastructure

Contracts publish static text records to ENS. Protocols never host, run, or maintain an MCP server.

Ref: SPEC §1 (Publication)

Cryptographic

Owner-Verified Trust

Contracts with reverse ENS primary names pointing back to the publisher are cryptographically verified.

Ref: SPEC §3 (Discovery)

Deterministic

State Diff Proofs

Multi-step calls simulate atomically via eth_simulateV1 with exact balance delta proofs.

Ref: SPEC §4 (Writes)

Air-Gapped

Local Wallet Boundary

Writes bridge to a local approval page. Works with browser wallets such as MetaMask and Rabby, with EIP-5792 batching.

Ref: approve-ui

Agnostic

Universal Host

One generic MCP host exposes discovered tools to Claude Code, Cursor, Codex, and custom agents.

Ref: SPEC §5 (Exposure)

Decentralized

Capability Discovery

Arkiv indexes protocols by capability without relying on centralized app stores or proprietary registries.

Ref: SPEC §6 (Search)