Ankr Management MCP

io.github.w3techPublished by GitHub account w3techv0.2.8Updated Nov 3, 2026

Manage an Ankr RPC account: API keys, usage, allowlists, billing, teams. Sign in with OAuth.

VerifiedStreamable HTTPWeb executableCloud & InfrastructureFinance

Overview

AI-generated overview

Ankr's hosted MCP server for managing an Ankr RPC account: API keys, usage, allowlists, billing and teams, signed in with OAuth.

What you can do
  • Manage API keys and allowlists for an Ankr RPC account
  • Read usage and billing information
  • View team membership
  • Sign in through an OAuth flow when the client prompts
When to use it
Use it when you want an assistant to inspect or administer an Ankr RPC account — checking usage, billing reads, key and allowlist settings, or team membership — without opening the dashboard. It is a separate surface from Ankr's blockchain data server and does not answer chain queries.
Requirements
A remote endpoint at reached over streamable HTTP, with OAuth sign-in required. An Ankr account is needed; an RPC API key is explicitly not accepted as management authority.
Before you install
The server can change account settings such as API keys and allowlists, so review any write before approving it. Billing information is exposed. Access is granted through OAuth sign-in, so the assistant acts with your account's management authority.

Installation

In SourceWeft

  1. Open Ankr Management MCP in the dashboard and add it to a workspace.
  2. Connect the required credentials. They are stored privately and never shown on public pages.
  3. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.w3tech%2Fagent-rpc-mcp-management/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config. The client completes OAuth sign-in on first connect.

{
  "mcpServers": {
    "ankr-management": {
      "type": "http",
      "url": "https://mcp.ankr.com/mcp"
    }
  }
}

README

Ankr Agent RPC — MCP Server

A Model Context Protocol server that gives AI agents token-efficient access to blockchain data through Ankr RPC.

Reads go out with the TORPC Accept-Token-Tier: 2 header. Tier 1 already renames the fields, turns hex into decimal and drops the service fields (logsBloom, cumulativeGasUsed, header roots). Tier 2 adds the ABI decode on top, so contract calls and event logs come back as named arguments.

A live run over 21 methods and 25 Ethereum mainnet blocks, token-weighted and counted with o200k_base over the full HTTP body, came out 48.4% smaller at tier 2 and 35.3% smaller at tier 1. Decode-heavy reads save the most: eth_getTransactionByHash 69.0%, eth_getTransactionReceipt 64.5%, eth_getBlockReceipts 60.3%, the block methods 40.4%, eth_getLogs 28.9%; scalar reads save 9–19%. Per-method figures: live-token-savings-2026-07-17.md.


Quick start

Get a free API key at ankr.com/rpc.

Hosted (no install)

The server runs at https://mcp.ankr.com/rpc. Send your key as the x-ankr-api-key header (or Authorization: Bearer <key>); each request carries the caller's own key, and the server holds no credential of yours.

json
{  "mcpServers": {    "ankr-agent-rpc": {      "url": "https://mcp.ankr.com/rpc",      "headers": { "x-ankr-api-key": "<YOUR_KEY>" }    }  }}

Local (stdio)

json
{  "mcpServers": {    "ankr-agent-rpc": {      "command": "npx",      "args": ["-y", "@w3tech.io/agent-rpc-mcp"],      "env": { "ANKR_API_KEY": "<YOUR_KEY>" }    }  }}

That JSON goes in your client's MCP config: Claude Desktop (claude_desktop_config.json), Cursor, Windsurf, or any other MCP client. Cursor also accepts the command form:

sh
env ANKR_API_KEY=<YOUR_KEY> npx -y @w3tech.io/agent-rpc-mcp

Tools

Raw RPC, TORPC tier 2

ToolWhat it answers
getTransactiontransaction + receipt by hash, ABI-decoded
getLogsevent logs, decoded; wide block ranges are chunk-scanned and paged
getBlockblock header, optionally with decoded transactions

Indexed and mixed

ToolWhat it answers
getBalancesnative coin + ERC-20 balances with USD
getAccountBalancebalances across many chains at once
getWalletActivityan address's transaction history, paged
getNFTsNFTs held by an address
getTokenHoldersholders of an ERC-20, paged
getTokenPriceUSD price with chain, asset and as_of provenance
getTokenPriceHistoryhistorical price series for a token
getInteractionswhich chains an address has touched, cross-chain
resolveContractis-contract, best-effort ERC-20 metadata, EIP-1967 proxy
searchChainresolve a tx/block hash, an address, or a block number
expandResultcontinue any paged result from its cursor

Discovery and escape hatch

ToolWhat it answers
listChainssupported chains, max TORPC tier, indexer availability
describeMethodsthe param shape and a worked example per JSON-RPC method, plus whether your key may call it on that chain
rpcCallany read method the routed tools do not cover

Sui

Sui is not an EVM chain and is not reached through the JSON-RPC proxy at all: a Sui call goes out over gRPC. getBalances, getBlock, getTransaction, getWalletActivity, getLogs and rpcCall take chain: "sui" and route themselves — getLogs reads Move events over a checkpoint range, filtered by emitting package or module, event type and sender. resolveContract and searchChain are built from eth_* calls Sui has never had and refuse there, naming the tool that answers instead. A Move event row is {contract, event, args}, the same shape an EVM tier-2 log has — but its args arrives at tier 0, decoded by the node rather than from an ABI, so on this path it is not evidence of a tier.

Eight tools serve what Sui has and an EVM chain does not:

ToolWhat it answers
suiGetObjectsMove objects by id, batched, with their decoded fields
suiListOwnedObjectsevery object an address owns, paged, filterable by Move type
suiListDynamicFieldstables, bags and dynamic object fields under one object's UID
suiGetPackagethe modules a published Move package declares
suiGetFunctionone Move function's signature
suiResolveNamea SuiNS name to its address, or an address to its name
suiSimulateTransactionwhat a transaction would do, run against current state, never submitted
suiWatchEventsMove events from the executed tip on, polled from a resumable cursor

That is the whole set: 25 tools.

What rpcCall will and will not do

rpcCall is a read and data escape hatch, never a wallet. It is a write denylist, not a read allowlist: it refuses transaction broadcast and signing, transaction building, node and dev-node administration, mutating verbs, and the node-operation half of geth's debug_* namespace — on every chain family — and forwards everything else.

It therefore keeps no list of permitted reads. Which reads exist is decided per chain by the endpoint's blockchain schema and by what your tenant may call, so a forwarded read can still come back refused (Method disabled, reason: restricted by blockchain schema). That refusal is the authoritative answer; listChains reports coverage.

Sign and send transactions with your own wallet or signer.


Reading a response

Two fields decide how to read every result, and an agent that skips them will misread output that is technically correct.

_meta.tier — the TORPC tier is negotiated per call and is not guaranteed. On the proxy path a response comes back at tier 0 (raw, undecoded, no args) when it is above the proxy's compression budget, and also when the method is one the proxy does not compress at all, such as eth_call, eth_getCode and eth_getStorageAt. Every successful response carries the tier actually applied in _meta.tier, so check it before looking for decoded fields; an error result carries _meta.error_code instead and no tier at all. Some tools additionally report tier_degraded: true in the body, with a note on how to narrow the request, when they asked for tier 2 on your behalf and got less. Not all of them do, so _meta.tier is the field to rely on. _meta.tier_source says who applied the tier, and the shape rule above is the proxy's alone: on the Sui gRPC path (tier_source: "local") a Move event row carries contract, event and args at tier 0, because the node decodes a Move struct itself.

Decoded amounts are raw base units, with no decimals applied. args.value: "41695680" on a 6-decimal token is 41.69568, not 41 million. Read the token's decimals with resolveContract before reporting a human number.

_meta.token_count is a real o200k_base count of the emitted text, not a chars/4 estimate. It is exact up to 256 KB of emitted text, which covers every display-capped response; above that it is extrapolated and the response carries _meta.token_count_estimated: true. Responses are minified JSON, so a model with a different tokenizer sees a similar but not identical number.

Tool inputs are strict: an unknown argument is rejected with a validation error rather than silently dropped, so a misspelled argument name is reported instead of ignored. Block numbers above 2^53 must be passed as strings, because a JSON number that large is not exact.


TORPC tiers

TierMeaning
0passthrough — standard JSON-RPC
1field rename, hex → decimal, and the service fields dropped: logsBloom, cumulativeGasUsed, contractAddress, type, the header roots
2tier 1 plus the ABI decode — each log becomes {contract, event, args}, calldata becomes a decoded function with named args

Negotiation is by header: Accept-Token-Tier: 0|1|2 on the request, Token-Tier on the response. The proxy applies the requested tier only while the response stays inside its compression budget, and that budget is internal to the proxy — so this server never predicts the tier, it detects the applied one and reports it.

On a JSON-RPC batch that header describes the array, not any one element: a response array carries a single Token-Tier, and its value is the minimum tier applied across the elements. v1 defines no per-element tier signal, elements may sit above that floor, and a client reads each element's own tier from the shape the proxy left on it — renamed fields and decimal strings for tier 1, event/args for tier 2 — rather than from the header. So the header is a floor and a signal that a transform was applied; which methods reach tier 2 is declared per method in the descriptor at https://mcp.ankr.com/.well-known/torpc.json, which also ships in the npm package at static/.well-known/torpc.json.

Specification: w3tech/torpc, released under CC0-1.0, with the TORPC docs page as the narrative version. The reference decoder is published as @w3tech.io/torpc-decoder (Apache-2.0); its source and the benchmark harness live in w3tech/torpc-js, under codec/. The EVM tier-1 and tier-2 rules are normative in the spec today; the conformance suite is a scaffold, so no implementation, this one included, claims conformance yet.


Discovery

Two machine-readable documents describe this deployment. Both are public, carry no credential, and are readable cross-origin.

DocumentServed at
TORPC descriptor: protocol version, negotiation headers, tier meanings, method listsmcp.ankr.com/.well-known/torpc.json
rpc.ankr.com/.well-known/torpc.json
Agent card: an ERC-8004 registration file naming who answers, and at which MCP endpointsmcp.ankr.com/.well-known/agent-card.json
rpc.ankr.com/.well-known/agent-card.json

Both ship in this package under static/.well-known/, and the served copy is the deployment's own statement: a packaged copy can lag it. The card states x402Support: true, because /rpc without a key takes per-call payment over x402, and claims no on-chain registration and no trust mechanism, because there is none to claim.


Supported chains

Ethereum, BSC, Polygon, Arbitrum, Optimism, Base, Avalanche and more, plus testnets. Indexed tools cover a wider set than the raw-RPC tools.

Call listChains for the live matrix rather than trusting a list in a README — coverage changes without a release here.


Managing your Ankr account

A second, separate MCP surface at https://mcp.ankr.com/mcp covers account management — API keys, allowlists, usage, billing reads and team membership — and authenticates with OAuth rather than an API key. Sign in when your client prompts. An RPC API key is not management authority and will be refused there.


Links

License

MIT — see LICENSE.

Source: README.md at commit ce82db6

Tools

0
This server asks you to sign in, so SourceWeft could not read its tools without an account and has not indexed them. What a connected account sees can depend on that account and its permissions.

Version history

4
  1. v0.2.8LatestNov 3, 2026
  2. v0.2.7Oct 22, 2026
  3. v0.2.5Oct 12, 2026
  4. v0.2.4Oct 12, 2026

Score

85% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts