explorer-mcp

endpoint

https://explorer.solana.com/mcp

protocol

streamable-http ·2025-06-18

authentication

none observed

public key

none — nobody has proven they own this listing · is it yours? claim it

karma

0 · newcomer

Is explorer-mcp live?

Yes — it answered the hub's last check (checked 2h ago). It answered 98% of checks over the last 30 days.

Is explorer-mcp free to use?

Not measured yet.

What tools does explorer-mcp have?

2 tools: ping, inspect_entity.

Is explorer-mcp safe to connect?

The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

• ping reads unknown never probed

  Basic scaffold health tool

  mcp-tool

  1234

  {
    "type": "object",
    "properties": {}
  }

  arguments 4 lines copy
• inspect_entity reads unknown never probed

  Retrieve detailed on-chain data for any Solana account. Use this tool when a user asks about a Solana address, program, token, NFT, wallet, or other blockchain entity. IDENTIFIER: A base58-encoded string. Accepts account addresses (32-byte) and transaction signatures (64-byte) — the tool detects which type was provided. CLUSTER: Solana network to query (mainnet-beta, devnet, testnet). Defaults to mainnet-beta. ACCOUNT TYPES RETURNED (by entity.kind): - "spl-token:mint" / "spl-token-2022:mint": Token mints — address, supply, decimals, mint/freeze authorities, supply type (fixed/variable), token program. Token-2022 mints also include parsed extensions. - "spl-token:account" / "spl-token-2022:account": Token accounts — mint, owner, token program. - "spl-token:multisig" / "spl-token-2022:multisig": Token multisigs — signers, threshold, initialization status. - "compressed-nft": Compressed NFTs — asset ID, owner, merkle tree. - "stake", "vote", "nonce", "sysvar", "config", "address-lookup-table", "feature", "native-program", "nftoken", "solana-attestation-service": Recognized system account types. - "bpf-upgradeable-loader": Upgradeable programs — address, label, balance, executable-data account, upgradeability ("upgradeable": false means the program is frozen: its upgrade authority is revoked and its code can no longer change), last deploy slot, upgrade authority, plus "idl", "verification" (verified-build status), "security_metadata" (security.txt) and "multisig" (upgrade-authority multisig) enrichments. Each carries an explicit unknown marker when its source is unavailable. The "idl" enrichment reports status, idl_type, program name and "source" ("pmp" for the program-metadata program, "anchor" for the Anchor IDL PDA). A PMP result also carries "authority" (absent when "source" is "anchor"): null when the program's own canonical PDA served it, else the key whose PDA did — today that key is the Solana Foundation's "fndnu15PLXELbLsTqrfbiweBvsBj2o12RoVfkeCCbX2", which publishes IDLs for programs whose canonical PDA holds none. Note "verification.evidence.is_frozen" is registry metadata recorded when the build was attested, so it can disagree with the current on-chain state; "upgradeable" is read live. - "bpf-loader" / "bpf-loader-2" / "loader-v4": Legacy-loader programs — address, label, balance, executable flag and owner loader, plus the same "idl", "verification", "security_metadata" and "multisig" enrichments. None of the three has a separate programdata account. bpf-loader and bpf-loader-2 programs are immutable once finalized (executable true) and carry no upgrade authority: "multisig" reports not_multisig and verification follows the frozen path. loader-v4 programs decode their own state header into "status" (retracted/deployed/finalized), "upgradeable", "upgrade_authority" and "last_state_change_slot" (the header slot also records retracts, so it is not necessarily a deploy); non-finalized programs verify through the authority path against the program bytes, finalized ones through the frozen path. The verification registry does not currently index loader-v4 programs, so "unverified" there means not covered by the registry, not failed — and a retracted program's bytes are mid-maintenance, so its "unverified" is especially weak evidence. An undecodable loader-v4 state degrades "verification", "multisig" and the state fields to explicit unknown markers (reason loader_state_undecoded) rather than guessing. Unavailable sources carry explicit unknown markers. - "program-metadata:metadata" / "program-metadata:buffer" / "program-metadata:empty": Accounts of the program-metadata (PMP) program, subtyped by the discriminator they carry. Both metadata and buffer report "program" (the program the entry describes, NOT this account), "seed" (e.g. "idl"), "authority" (null when none) and "canonical"; metadata adds "mutable", "format", "encoding", "compression", "data_source" and "data_length". This is where a program's PMP-published IDL is anchored — with "data_source" "url" or "external" the bytes themselves live off-chain. Match a "seed": "idl" entry to the "idl" enrichment above by "canonical": true corresponds to that enrichment reporting "authority": null, and "canonical": false to it reporting this entry's "authority". Anyone may publish an entry for any program under their own authority, so only the canonical entry and those under an authority the resolver consults are ever resolved. - "unknown": Unrecognized account type. When the owner program publishes an IDL, the account data is decoded through it and returned as "decoded" (source "idl"). TRANSACTIONS: 64-byte signatures return entity.kind "transaction" — slot, block time, fee, status, error, signers, accounts (v0 lookup-table addresses attributed via source/lookupTableAddress), and instructions with inner instructions. Instructions decode through a cascade: programs publishing an on-chain IDL carry "decoded" with source "idl"; token batch and host-app-supported programs decode with source "bundled"; the rest stay base58 with source "raw". An IDL decode also names the accounts the IDL declares — "decoded.accounts" maps each declared role to its address, while the instruction's own "accounts" list stays positional and complete (extra accounts, such as a multisig's signers, appear only there). Token-program decodes carrying their own "decimals" add "decoded.ui_amount": the amount in whole tokens. OUTPUT: Responses use { payload: { entity: { kind, ...fields } }, errors: [] }. Unresolvable fields return explicit unknown markers instead of being silently omitted.

  mcp-tool

  123456789101112131415161718192021222324

  {
    "type": "object",
    "$schema": "http://json-schema.org/draft-07/schema#",
    "required": [
      "identifier"
    ],
    "properties": {
      "cluster": {
        "enum": [
          "mainnet-beta",
          "devnet",
          "testnet"
        ],
        "type": "string",
        "default": "mainnet-beta"
      },
      "identifier": {
        "type": "string",
        "maxLength": 128,
        "minLength": 1
      }
    },
    "additionalProperties": false
  }

  arguments 24 lines copy

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.