What can you do with this server?

This MCP server provides keyless blockchain reads across 31 chains, with hosted-service swap support described in the README. * List supported chains with slug, chain ID, family, and native currency. * Make arbitrary JSON-RPC 2.0 calls on EVM, Solana, and Sui chains. * Get the latest block height or slot for supported chains. * Get native-token balances for EVM addresses in wei and decimal form. * The README adds token lookup, best-route swap quotes with approval/simulation, and signed-transaction broadcast on the hosted server; the provided schema only exposes the four read tools.

Which integrations are available for this server?

Allows querying Ethereum blockchain via JSON-RPC calls (eth_*), including getting balances and block numbers, through the MoltNode RPC gateway. Enables interaction with the Solana blockchain via JSON-RPC calls, such as retrieving block height and native balances, through the MoltNode RPC gateway. Provides access to the Sui blockchain via JSON-RPC calls, including operations like reading block numbers and balances, through the MoltNode RPC gateway.

How do I use moltnode-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@moltnode-mcp latest block on Ethereum" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

moltnode-mcp

by tuantqse90

Overview Schema Source Related Servers Discussions Admin

Python

Remote

MoltNode by Chord: MCP server

Read 31 blockchains and swap tokens from any AI agent. One hosted MCP server, no API key, no signup.

Read: JSON-RPC on Ethereum, Base, Arbitrum, Solana, Monad, BNB Chain, Avalanche, Sui and 23 more, through MoltNode (automatic failover across providers).
Trade: best-route swap quotes from Chord on Ethereum, Base, Monad, BNB Chain, Avalanche, Arbitrum, Robinhood Chain and Arc, with the unsigned transaction, the approval it needs and a simulation run from your wallet. Your agent signs with its own key; nothing is ever held for you.

https://moltnode.ag/mcp

Connect

Claude Code

claude mcp add --transport http moltnode https://moltnode.ag/mcp

Or install everything as a plugin (MoltNode + Chord MCP servers and the three skills):

/plugin install moltnode --marketplace tuantqse90/moltnode-mcp

Cursor, Windsurf, VS Code, Claude Desktop and any client that takes a URL

{
  "mcpServers": {
    "moltnode": { "type": "http", "url": "https://moltnode.ag/mcp" }
  }
}

In Claude Desktop or claude.ai you can also add it under Settings → Connectors → Add custom connector, with the URL above.

Clients that only start local commands (stdio)

{
  "mcpServers": {
    "moltnode": { "command": "npx", "args": ["-y", "moltnode-mcp"] }
  }
}

(npx -y github:tuantqse90/moltnode-mcp works too.)

The stdio bridge in this repo (index.mjs) forwards every call to the hosted server, so both give the same tools. Without network it still lists the tools (from tools.json, a snapshot of the hosted list refreshed with npm run refresh-tools) and each call says the server is unreachable.

Related MCP server: dRPC Agent Skills

Tools

Tool	What it does
`list_chains`	Every chain MoltNode serves (slug, chainId, native coin, endpoint) and the ones Chord trades on
`rpc_call`	Any JSON-RPC method on any chain: `eth_call`, `eth_getLogs`, Solana `getBalance`, Sui methods, …
`get_block_number`	Latest block of an EVM chain
`get_balance`	Native-coin balance of an address on an EVM chain
`chord_find_token`	Token address, decimals and verified flag by symbol or name
`chord_swap_quote`	Best route across the chain's DEXs + unsigned `tx` + `approval` (as a ready transaction) + simulation from the taker wallet
`send_raw_transaction`	Broadcast a signed transaction

How an agent swaps

chord_find_token → the addresses and decimals of the two tokens (the zero address is the native coin).
chord_swap_quote with taker = the agent's wallet. Amounts are integer strings in the token's smallest unit (10000000 = 10 USDC).
If the answer has approval, sign and send approval.tx first.
Sign tx with the agent's own key.
send_raw_transaction on the same chain.

The router enforces minAmountOut on-chain. Chord's own router answers first; another aggregator is used only when Chord has no route, and the answer says which.

Agent skills

Install with the skills CLI (Claude Code, Codex, Cursor, Gemini CLI and more): npx skills add tuantqse90/moltnode-mcp, or in Hermes: hermes skills tap add tuantqse90/moltnode-mcp. Gemini CLI extension: gemini extensions install https://github.com/tuantqse90/moltnode-mcp.

skills/moltnode/: read 31 chains and swap through Chord end to end, with the safety rules (never handle a private key, confirm the quote before signing).
skills/chord-swap/: safe best-route token swaps through Chord on Ethereum, Base, Arbitrum, BNB Chain, Avalanche, Monad, Robinhood Chain, Arc and Solana: finds the right token, checks it for honeypots and taxes, quotes, waits for the user's yes, then returns an unsigned transaction with a simulation for the user's own wallet. Plain HTTP, no key, no scripts.
skills/chord-charts/: candlestick chart (SVG) with volume for any token on Ethereum, Base, Monad, BNB Chain, Avalanche, Arbitrum, Robinhood Chain, Arc or Solana, from Chord's trade data (python3 scripts/chart.py --chain base --token AERO --tf 1h).
skills/chord/: Chord's trading and market-data skill (quotes, unsigned swaps, token boards, candles, wallet PnL, smart money, holders, LP pools), marketplace edition: no key handling, no environment variables, no installer (generated from Chord's skill at nullterminal 5f07c02e; the Ask command, which needs a key, is left out). The original with Ask: https://getchord.xyz/docs/skills/chord/

skills/moltnode/SKILL.md is a SKILL.md skill (Claude Code, Codex CLI, Cursor, Gemini CLI, OpenClaw and others): when to read a chain, how to run a swap end to end, and the safety rules (never handle a private key, confirm the quote before signing). Install it by copying the folder into your agent's skills directory, e.g. ~/.claude/skills/moltnode/.

Without MCP

Function-calling definitions (Anthropic and OpenAI shapes), with the HTTP call behind each tool: https://moltnode.ag/tool-schema.json
Plain JSON-RPC: POST https://moltnode.ag/<chain> (e.g. https://moltnode.ag/base)
Chain catalog: https://moltnode.ag/api/chains · OpenAPI: https://moltnode.ag/openapi.json · Brief for LLMs: https://moltnode.ag/llms.txt
Live swap quote in the browser and full viem / web3.py code: https://moltnode.ag/trade

Chains

Read: Monad, Ethereum, Base, Arbitrum One, Optimism, Polygon, BNB Chain, Solana, Avalanche C-Chain, HyperEVM, Berachain, Abstract, Sei, Sonic, Mantle, Taiko, zkSync Era, ZetaChain, opBNB, BOB, Edge, Stable, Katana, Morph, Swellchain, 0G, TAC, X Layer, Gnosis, Fantom, Sui.

Trade (Chord): Ethereum, Base, Monad, BNB Chain, Avalanche, Arbitrum, Robinhood Chain, Arc.

Limits

Free and shared: short bursts of 60 requests, then 3 requests per second and 20,000 per day per client; answers up to 8 MB. Past a limit the tools answer with the wait time. Send a User-Agent. For heavy production traffic, run your own node.

License

MIT

Available Tools

4 tools

get_balanceNative balance (EVM)BInspect

Native-token balance of an address on an EVM chain, returned in wei and as a decimal of the native currency.

Name	Required	Description	Default
`chain`	Yes	EVM chain slug from list_chains.
`address`	Yes	0x-prefixed EVM address.

TDQS

B3.3/5.0

Behavior3/5

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

No annotations are present, so the description carries the full burden. It discloses that the return is in wei and decimal, but omits behavioral traits like read-only nature, potential errors, or performance characteristics. The description is minimal but not contradictory.

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, clear sentence with no filler. It efficiently conveys the core purpose and return format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description provides basic understanding but lacks information on error handling, response structure, or unsupported chains. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 does not add new meaning to parameters (chain and address) beyond the schema descriptions. The return format mention is peripheral to parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves the native-token balance of an address on an EVM chain and specifies the return format (wei and decimal). It is distinguishable from siblings like list_chains and rpc_call, though not explicitly differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not indicate when to use this tool over siblings or alternatives, nor does it warn about limitations (e.g., only native tokens, not ERC20).

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

get_block_numberCurrent block heightAInspect

Latest block height / slot for an EVM, Solana, or Sui chain.

Name	Required	Description	Default
`chain`	Yes	Chain slug from list_chains.

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It fails to disclose return format (e.g., integer or string), authentication needs, or rate limits, leaving significant gaps in behavioral understanding.

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?

Single sentence description that is concise, front-loaded, and free of superfluous words. Title 'Current block height' is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately conveys the core functionality. It could explicitly mention return format (e.g., 'returns an integer'), but the omission is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents the 'chain' parameter fully. The description adds context by mentioning chain types (EVM, Solana, Sui), but this is already implied by the enum values. Marginal additional value.

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 tool returns the latest block height or slot for a specified chain, using specific verbs and resource identification. It distinguishes well from siblings like list_chains and get_balance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While sibling names provide context, the description does not mention exclusions or when-not-to-use scenarios.

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

list_chainsList supported chainsAInspect

List every chain MoltNode can reach (slug, name, chainId, family, native currency). Use the chain slug from here as the argument for the other tools. No key required.

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries burden. It states no key required and implies read-only behavior (listing chains). However, it does not explicitly state that it has no side effects or mention any rate limits, but for a simple list tool this is adequate.

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?

Two concise sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value: the first states what it does, the second gives usage guidance.

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 simple parameterless list tool, the description fully covers what the tool returns and how to use that output. No output schema exists, but the description compensates by listing the fields.

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?

No parameters exist (schema coverage 100% empty), so baseline is 4. The description adds value by describing the output fields and usage context, but no parameter details are needed.

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 that the tool lists supported chains with specific fields (slug, name, chainId, family, native currency). It uses a specific verb 'list' and resource 'chains', and distinguishes from siblings (rpc_call, get_block_number, get_balance) which serve different purposes.

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?

The description explicitly states to use the chain slug from this tool as an argument for other tools, providing clear guidance on when and how to use it. No alternative tools for listing chains exist, so no exclusions needed.

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

rpc_callRaw JSON-RPC callAInspect

Make any JSON-RPC 2.0 call against a chain through MoltNode. Works for EVM (eth_*), Solana (getSlot, getAccountInfo), and Sui. It is the general-purpose tool, so prefer it whenever no convenience tool fits. params is the JSON-RPC params array.

Name	Required	Description
`chain`	Yes	Chain slug from list_chains, e.g. 'ethereum', 'base', 'monad', 'solana'.
`method`	Yes	JSON-RPC method, e.g. 'eth_blockNumber', 'eth_getBalance', 'getSlot'.
`params`	No	JSON-RPC params array. Defaults to [].

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral traits. It does not disclose whether calls are read-only, what side effects may occur, error handling, rate limits, or authentication needs. This is insufficient for a tool that can invoke arbitrary RPC methods.

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 concise (three sentences, one parenthetical) and front-loads the purpose. Every sentence adds information; there is no fluff. Could be slightly more structured with bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool does and when to use it. However, with no output schema, it omits any mention of return values or error behavior. For a general-purpose tool, more context about result structure and potential failures would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 only a redundant note about `params` being the JSON-RPC params array. It does not explain how chain slugs are derived or method naming conventions beyond the schema. No extra value.

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 tool makes arbitrary JSON-RPC 2.0 calls, specifies supported chains (EVM, Solana, Sui), and explicitly frames itself as the general-purpose alternative to convenience tools. This distinguishes it from siblings like get_block_number and get_balance.

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 explicitly says 'prefer it whenever no convenience tool fits,' providing clear guidance on when to use this tool. It also lists affected chains. However, it does not explicitly exclude cases where a sibling tool is appropriate, leaving some ambiguity.

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.

4 tool updatesv0.1.0Jul 30, 2026
- First observedget_balance
- First observedget_block_number
- First observedlist_chains
- First observedrpc_call

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

Scored 2026-07-30 19:30 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing chains, making arbitrary RPC calls, fetching block number, and getting balance. No overlap.

Naming Consistency5/5

All tools use consistent snake_case verb_noun pattern: list_chains, rpc_call, get_block_number, get_balance.

Tool Count5/5

4 tools is appropriate for a blockchain RPC proxy: a chain enumerator, a general-purpose RPC caller, and two convenience helpers for common queries.

Completeness4/5

The set covers core functionality (chain list, arbitrary RPC, block height, balance) but lacks convenience tools for other common operations like getting transactions or logs. However, rpc_call can fill those gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Chain.Love MCP C
love.chain.app
Hosted MCP gateway for Web3 infra discovery across 20+ networks via one endpoint.
Web3 & Decentralized Tech Blockchain Networking & Infrastructure
52
https://app.chain.love/mcp
Chainlist A
io.github.pipeworx-io
Chainlist MCP — registry of EVM chains
Blockchain Web3 & Decentralized Tech
472
https://gateway.pipeworx.io/chainlist/mcp
Wallet Doctor x402
io.github.zikriz
Multi-chain wallet MCP. 18 tools: balance, swap, bridge, stake, claim. Pay-per-call USDC (x402 v2).
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
https://wallet-doctor-x402.m-zikriz.workers.dev/mcp
ChainRay B
online.chainray.mcp
ChainRay provides multi-chain blockchain data and intelligence for AI agents through 79 MCP tools across 57 supported networks, covering gas, chain data, wallets, DeFi, market, security, monitoring, and verifiable proofs. MCP access is available at https://mcp.chainray.online/mcp; paid HTTP capabilities settle via x402 on Base.
AI & Machine Learning Blockchain Finance
791
https://mcp.chainray.online/mcp

Related MCP Servers

Onesource MCP
Blockchain Web3 & Decentralized Tech Documentation Access
blockparty-global
A
license
A
quality
B
maintenance
MCP server with 43 tools for blockchain data — token lookups, wallet balances, live chain queries across 10+ networks, and full API documentation search.
Updated 11 days ago (2026-10-17 18:46 UTC)
27
893 npm
Apache 2.0
dRPC Agent Skillsofficial
Blockchain Web3 & Decentralized Tech
drpcorg
A
license
Not graded
quality
F
maintenance
Blockchain RPC via DRPC. Exposes eth_call, eth_getBalance, gas estimation, and other JSON-RPC methods as MCP tools across 100+ blockchains
Updated 4 months ago (2026-06-21 13:05 UTC)
23
MIT
blockscout-mcp-server
Blockchain Web3 & Decentralized Tech
imelon2
A
license
A
quality
C
maintenance
A read-only MCP server that queries multichain EVM on-chain data through Blockscout REST API, providing tools for address info, transactions, logs, and more.
Updated 2 months ago (2026-08-23 15:43 UTC)
16
5 npm
MIT
RouteMesh MCP Serverofficial
Blockchain Web3 & Decentralized Tech
routemesh
A
license
A
quality
C
maintenance
Enables querying blockchain data across multiple EVM chains via RouteMesh, offering built-in RPC tools for blocks, transactions, logs, balances, and gas estimation, plus customer management tools for API keys and usage.
Updated 5 days ago (2026-10-24 03:15 UTC)
11
2 npm
1
ISC

MoltNode by Chord: MCP server

Connect

Tools

How an agent swaps

Agent skills

Without MCP

Chains

Limits

Links

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Onesource MCP

dRPC Agent Skillsofficial

blockscout-mcp-server

RouteMesh MCP Serverofficial