LABSCO SUMMARY

Any contract, one server — the private key is the risk.

Generating tools from the ABI is the right abstraction: a new contract is a config change rather than a new integration, and the model gets real function names and validated arguments instead of a generic "call contract" tool. The line to draw is the wallet key. Without it this is a safe read-only explorer of contract state; with it, every state-changing function in the ABI becomes something a model can invoke against a real chain.

What it is

An MCP server that generates its own tool set from a contract ABI at runtime. Give it the ABI and address of any Ethereum-compatible smart contract and each function in that ABI becomes a callable tool, so a model can read contract state and execute transactions without anyone hand-writing an integration per contract.

What you get

Tools generated from the loaded ABI, named on the pattern {contractname}_{functionname} — for an ERC-20 token loaded as USDC that produces the likes of usdc_balanceOf, usdc_totalSupply, usdc_transfer and usdc_approve
View and pure functions become query tools that cost no gas and need no wallet; state-changing functions become execution tools that require one
One parameter schema across every generated tool — an args array holding the function arguments in order — so the model does not have to learn a different shape per function
Arguments validated against the ABI specification before the call goes out
Read responses returning the decoded result; write responses returning the transaction hash, block number, gas used and status
Any EVM-compatible chain, selected with a chain ID and an optional custom RPC endpoint

Requirements

Two settings are required: CONTRACT_ABI, the contract's ABI as a JSON string, and CONTRACT_ADDRESS, the deployed address. CONTRACT_NAME is optional and becomes the tool-name prefix. Write functions need WALLET_PRIVATE_KEY — a private key in your MCP client's configuration, which is the thing to think about before enabling them; leave it out and the server is read-only. CHAIN_ID and RPC_URL are optional and default to Fraxtal. Run it with npx @iqai/mcp-abi, or build from source with pnpm install && pnpm run build. ISC licensed. The author's own disclaimer applies: this executes real transactions, so test on a testnet before mainnet.

Setup effort

One command — npx @iqai/mcp-abi

See installation options

USE CASES

01

Reading contract state without any setup per contract

Load the ABI and address and query balances, supply, allowances or anything else the contract exposes as a view function.

02

Finding out what a contract can even do

The generated tool list is the contract's function list, so asking what is available answers itself.

03

Executing a transaction from a conversation

Supply a signing key and the state-changing functions become callable, returning the transaction hash, block and gas used.

04

Working on a chain other than the default

Set the chain ID and point at your own RPC endpoint; any EVM-compatible network works.

BEFORE YOU INSTALL

What to know first

Requires

npx on PATH

Optional

WALLET_PRIVATE_KEY in your environment

Where it runs

The documented client runs the server on your machine.

INSTALLATION

Connect your client

Server setup

TERMINAL

npx @iqai/mcp-abi

MCP Clients

Claude Desktop

CLAUDE DESKTOP · JSON

{
  "mcpServers": {
    "smart-contract-abi": {
      "command": "npx",
      "args": [
        "-y",
        "@iqai/mcp-abi"
      ],
      "env": {
        "CONTRACT_ABI": "[{\"inputs\":[{\"name\":\"account\",\"type\":\"address\"}],\"name\":\"balanceOf\",\"outputs\":[{\"type\":\"uint256\"}],\"stateMutability\":\"view\",\"type\":\"function\"}]",
        "CONTRACT_ADDRESS": "0xaB195B090Cc60C1EFd4d1cEE94Bf441F5931C01b",
        "CONTRACT_NAME": "ERC20"
      }
    }
  }
}

The configuration on this page does not set WALLET_PRIVATE_KEY.

MCP-ABI