cometbft-mcp
Related Servers
Alternatives to cometbft-mcp
AlicenseAqualityAmaintenanceConnects AI agents and developers to structured blockchain data across multiple networks through Nodit's Web3 infrastructure, enabling easy querying, analysis and interaction with blockchain ecosystems without specialized development expertise.69224 npm23Apache 2.0- AlicenseAqualityFmaintenanceAn MCP server that tracks Ethereum’s validator activation and exit queues in real time, enabling AI agents to monitor staking dynamics and network participation trends.32MIT

Cosmos SDK Migration MCPofficial
AlicenseNot gradedqualityDmaintenanceAn MCP server for migrating Cosmos SDK chains from v0.50+ to v0.54.Apache 2.0
Related Servers
- AlicenseNot gradedqualityDmaintenanceRead-only MCP server that monitors a Bitcoin Core full node via JSON-RPC, providing tools to check node status, network info, mempool, and peer information.MIT
- AlicenseAqualityDmaintenanceMCP server providing on-chain monitoring reads such as ENS expiry, gas prices, token unlocks, and oracle health via the FabTally Chain API. It supports stdio and streamable-http transports, is read-only and keyless, with pay-per-call tools.4MIT
- AlicenseNot gradedqualityBmaintenanceModel Context Protocol (MCP) server for 5 classic non-EVM blockchains: Bitcoin, Monero, Zcash, Dogecoin, and Litecoin. Zero-auth, read-only & privacy-first.MIT
- AlicenseNot gradedqualityDmaintenanceRead-only MCP server for investigating Polymarket wallets, markets, and cross-wallet patterns using 21 tools backed by public APIs and an optional SQLite cache.MIT
- AlicenseAqualityDmaintenanceA read-only MCP server for safely exploring Nostr, enabling agents to resolve identifiers, fetch profiles and events, query notes, and inspect relay metadata. It does not accept private keys or publish events.512 npmMIT
- AlicenseAqualityAmaintenanceRead-only MCP server for querying DERO blockchain — blocks, smart contracts, transactions, network info. Privacy-first, runs locally.33168 npm2MIT
TDQS
Scored across 6 tools
Each tool targets a distinct diagnostic axis (consensus round, node sync, peers, validator signing, upgrades), and descriptions include explicit cross-references such as 'does NOT check peers (use peer_health)'. The only real overlap is fleet_overview, which aggregates the same signals as the four single-purpose tools, but the 'sweep first, then drill in' framing makes the boundary workable.
All six names follow the same noun_noun convention (resource + aspect of health: node_status, peer_health, validator_health, upgrade_readiness, consensus_diagnosis, fleet_overview). No mixing of verb styles, casing, or languages.
Six tools is tightly scoped for a CometBFT diagnostics server: one aggregate sweep plus five focused probes covering consensus, sync, p2p, signing, and upgrades. Every tool maps to a distinct failure mode an operator would investigate.
The diagnostic surface covers the main halt/liveness causes (quorum, sync, isolation, jailing, upgrade) plus a fleet-wide aggregate, which is strong for a read-only diagnosis domain. Minor gaps: no mempool/tx-layer inspection and no historical or trend view of past incidents, though these are arguably out of scope.