Avalanche AVAX MCP

Search and retrieve Avalanche blockchain documentation for building on AVAX.

CommunityOnlineNo sign-inGlobalFreeRead-only

What it can do

    What data it sees

    Do you need an account

    No: the server works without sign-in

    Search and retrieve Avalanche blockchain documentation for building on AVAX.

    How to connect

    How to connect Avalanche AVAX MCP to Claude

    The server address to paste into Claude settings:

    https://build.avax.network/api/mcp

    1. Open Claude (claude.ai or the desktop app).
    2. Go to Settings → Connectors.
    3. Click Add custom connector.
    4. Paste the server address copied below into Remote MCP server URL and click Add.
    5. In a chat, click + → Connectors and switch the new connector on.

    Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.

    Authorization

    After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.

    How to connect Avalanche AVAX MCP to ChatGPT

    The server address to paste into ChatGPT settings:

    https://build.avax.network/api/mcp

    1. Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
    2. Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
    3. Open Settings → Connectors and click Create.
    4. Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
    5. Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
    6. In a new chat open + → Apps/Connectors and enable the connector.

    OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.

    Authorization

    On first use ChatGPT opens the service's sign-in window. Sign in and approve access.

    How to connect Avalanche AVAX MCP to Cursor

    The server address to paste into Cursor settings:

    https://build.avax.network/api/mcp

    Fastest: click Open in Cursor below and confirm the prompt.

    Manually:

    1. In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
    2. Paste the JSON copied below into ~/.cursor/mcp.json (per project: .cursor/mcp.json in the repo root).
    3. Save the file. The server appears in the MCP list; authorize it there if asked.

    Authorization

    If the service needs sign-in, an authorize button appears next to the server in the MCP list.

    Server tool list (48)

    Raw names from tools/list. Only developers need these.

    docs_searchSearch body-level chunks across Avalanche documentation, academy courses, integrations, and blog posts. Returns source citations and matching excerpts.
    docs_fetchFetch a specific documentation page as markdown
    docs_list_sectionsList available documentation sections and their page counts
    cli_lookup_commandLook up Avalanche CLI, Platform CLI, and tmpnet command guidance in the docs. Returns cited command references and task docs.
    rpc_lookup_methodLook up Avalanche RPC methods and API guides across C-Chain, P-Chain, X-Chain, Subnet-EVM, and node RPC docs.
    acp_lookupLook up Avalanche Community Proposals (ACPs) by number, title, or topic. When a number is provided the structured ACP record is returned (title, status, track, authors, cross-references).
    acp_listList Avalanche Community Proposals with structured fields, optionally filtered by status (Activated, Implementable, Proposed, Stale, Withdrawn) or track (Standards, Best Practices, Meta, Subnet).
    avalanche_docs_searchCompatibility alias for docs_search. Prefer docs_search for new clients.
    avalanche_docs_fetchCompatibility alias for docs_fetch. Prefer docs_fetch for new clients.
    avalanche_docs_list_sectionsCompatibility alias for docs_list_sections. Prefer docs_list_sections for new clients.
    blockchain_lookup_transactionLook up a transaction by hash on Avalanche (C-Chain, P-Chain, or X-Chain). Supports 0x format (C-Chain) and CB58 format (P/X-Chain).
    blockchain_lookup_subnetLook up a Subnet / L1 by its ID — validators, chains, and configuration.
    blockchain_lookup_chainLook up a blockchain by its ID — name, VM type, and Subnet/L1.
    blockchain_lookup_validatorLook up a validator by node ID — stake, uptime, delegation info.
    platform_get_heightGet the current P-Chain block height
    platform_get_blockGet a P-Chain block by its block ID
    platform_get_block_by_heightGet a P-Chain block by its height
    platform_get_blockchainsGet all blockchains that exist on the P-Chain (paginated; use limit/offset)
    platform_get_subnetsGet information about Subnets/L1s on the P-Chain
    platform_get_current_validatorsGet the current validators of a Subnet/L1 (paginated; use limit/offset)
    platform_get_pending_validatorsGet the pending validators of a Subnet/L1 (paginated; use limit/offset)
    platform_get_staking_asset_idGet the asset ID of the token used for staking on a Subnet/L1
    platform_get_min_stakeGet the minimum staking amounts for validators and delegators on a Subnet/L1
    platform_get_total_stakeGet the total amount staked on a Subnet/L1
    platform_get_balanceGet the AVAX balance of one or more P-Chain addresses
    platform_get_utxosGet UTXOs that reference a given set of P-Chain addresses
    platform_get_txGet a P-Chain transaction by its transaction ID
    platform_get_tx_statusGet the status of a P-Chain transaction
    platform_get_current_supplyGet the current total supply of AVAX on a Subnet/L1
    platform_get_validators_atGet the validators and their weights of a Subnet/L1 at a given P-Chain height
    info_get_node_versionGet the version of the node, including the database version, git commit, and API compatibility info.
    info_get_network_idGet the numeric ID of the Avalanche network this node is participating in.
    info_get_network_nameGet the human-readable name of the Avalanche network this node is participating in.
    info_get_blockchain_idGet the CB58-encoded blockchain ID for a given blockchain alias (e.g., "X", "P", "C").
    info_is_bootstrappedCheck whether a given chain has finished bootstrapping on the node.
    info_get_tx_feeGet the current transaction fees for the network, returned in both nAVAX and AVAX.
    info_peersGet a list of peers this node is connected to. Optionally filter by specific NodeIDs.
    info_acpsGet information about Avalanche Community Proposals (ACPs), including their status and vote counts.
    blockchain_get_native_balanceCompatibility alias for onchain_lookup address balances. Prefer onchain_lookup for new clients.
    blockchain_get_contract_infoCompatibility alias for onchain_lookup contract metadata. Prefer onchain_lookup for new clients.
    blockchain_lookup_addressCompatibility alias for onchain_lookup address details. Prefer onchain_lookup for new clients.
    onchain_lookupPRIMARY lookup tool — use this (not raw RPC) to resolve/describe any on-chain identifier in one call: an EVM address (native + token balances, recent txs, contract metadata + isContract), a contract/token (metadata + deployment + recent transfers), an NFT (collection + tokenId), a tx hash, a subnet ID, a NodeID validator, a P-/X-Chain account (P-…/X-… → P-Chain balance), or a chain name/id. Use this for any address balance / contract-info / token / identity question. `kind` auto-detects; network is inferred from P-/X-Chain prefixes. Backed by Glacier + P-Chain RPC.
    onchain_activityTime-windowed on-chain activity. scope=chain/address returns the transaction COUNT over the last `hours` (max 720h = 30 days; for longer windows use chain_stats series or onchain_query day-based ops) plus a recent sample. For a token/contract use scope=token (transfers). scope=primary covers P/X-chain and DEFAULTS to P-Chain when no blockchainId is given (so "last N P-chain transactions" just works). A value with no scope defaults to address.
    chain_statsOn-chain statistics via the query gateway, which picks the most accurate live source PER FIELD and stamps it (sources/warnings in the response). target=chain: tx count/gas/fees/active senders/avg gas price over a recent window (window=recent, `hours`, max 720h = 30 days) OR a time-series (window=series, `days`, max 365). target=contract: per-contract tx/sender/gas totals (`days`, max 365 — use this for contract activity beyond 30 days). target=network: current P-chain validator snapshot. IMPORTANT: relay any `warnings` notes to the user verbatim-in-substance (e.g. gas coverage windows or accuracy caveats) — never present a flagged value as exact. Note: C-Chain gasUsed is gas-target-regulated, so daily gas is ~stable even as tx count varies — expected, not an error.
    onchain_queryPRIMARY tool for indexed on-chain stats/activity/totals — prefer this over raw RPC for chain data. Each `op` is a backend-agnostic intent: the query gateway selects the most accurate live source per field (indexed DB / pre-aggregated metrics / Data API), stamps every field (`sources`), and flags any caveat (`warnings`) — relay warnings to the user, never present a flagged value as exact. Pick an `op` and pass its `params`; `chainId` is an allowlisted EVM chain (43114 C-Chain, 43113 Fuji, + L1s). Lookback: hour-based ops (chainStatsRecent/chainActivity/addressActivity) max 720h (30 days); day-based ops (chainStatsSeries/contractStats/chainGasTotal/protocolRanking/contractGasFlow/topUnknownContracts) max 365 days — use a day-based op for windows over 30 days. Ops: chainStatsRecent {chainId, hours≤720} — tx count/gas/fees/active senders/avg gas price over the last N hours; chainStatsSeries {chainId, days≤365, bucket: hour|day|week|month} — bucketed time-series of the same; addressActivity {chainId, address, hours≤720, limit≤100} — tx count + recent sample for an address in a window; chainActivity {chainId, hours≤720, limit≤100} — tx count + recent sample chain-wide in a window; contractStats {chainId, contract, days≤365} — tx/unique-sender/gas totals for a contract; protocolRanking {chainId, contracts[≤25], days≤365, orderBy: txCount|gasUsed|uniqueSenders|feesPaidAvax, dir: asc|desc, limit≤100} — rank a set of contracts; contractGasFlow {chainId, contract, days≤365, limit≤100} — gas received/given per counterparty; topUnknownContracts {chainId, exclude[≤25], days≤365, limit≤100} — top contracts by gas excluding a set; chainGasTotal {chainId, days≤365} OR {chainId, fromDate, toDate} — total tx/gas/fees over N days or a YYYY-MM-DD range (≤365d). Note: C-Chain gasUsed is gas-target-regulated → ~stable day-to-day even as txCount varies (expected, not a bug).
    build_planGenerate a step-by-step, copy-pasteable runbook for an Avalanche operation — Builder Console (no-code) path plus the equivalent platform-cli / SDK / interchain-kit commands. Read-only: never signs. operation: create-l1 (launch an L1); use ictt or interchain-kit for any CROSS-CHAIN / interoperability work — bridging tokens, sending cross-chain (ICM / Teleporter / Warp) messages, or connecting your L1 to C-Chain or other L1s (interchain-kit also lets you iterate locally first); validator-manager; staking; transfer.
    console_linkReturn a deep-link into a specific Builder Console flow (create-l1, convert-to-l1, validator-manager, ictt, faucet, multisig, staking, transfers, interchain-kit-local). For faucet on mainnet, returns a note that there is no mainnet faucet.
    console_flowBuilder Console flow knowledge. Call with NO `flow` to list every flow (summaries + deep-links); call with a `flow` key to explain it (ordered steps, equivalent CLI, whether it signs transactions, deep-link). Flows: create-l1, convert-to-l1, validator-manager, ictt, faucet, multisig, staking, transfers, interchain-kit-local.