Celo MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CELO_RPC_URL | No | Celo mainnet RPC URL | https://forno.celo.org |
| CELO_TESTNET_RPC_URL | No | Celo testnet (Alfajores) RPC URL | https://alfajores-forno.celo-testnet.org |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_network_statusA | Retrieve the current status and connection information of the Celo network, including network health and connectivity details. |
| get_blockA | Fetch detailed information about a specific block on the Celo blockchain using its number or hash. Optionally include full transaction details within the block. |
| get_transactionA | Obtain detailed information about a specific transaction on the Celo blockchain using its transaction hash. |
| get_latest_blocksB | Get information about the most recent blocks on the Celo blockchain, with the ability to specify the number of blocks to retrieve and starting offset. |
| get_token_balanceC | Get the token balance for a specific address. |
| get_celo_balancesB | Get CELO and stable token balances for an address. |
| get_stable_token_balanceA | Get balances of all major stable tokens and CELO for an address using multicall. |
| get_gas_fee_dataB | Get current gas fee data including EIP-1559 fees. |
| get_governance_proposalsC | Get Celo governance proposals with pagination support. |
| get_proposal_detailsB | Get detailed information about a specific governance proposal including its content and voting history. |
| get_staking_balancesA | Get staking balances for an address, including active and pending stakes broken down by validator group. |
| get_activatable_stakesA | Get information about pending stakes that can be activated for earning rewards. |
| get_validator_groupsA | Get information about all validator groups, including their members, votes, capacity, and performance metrics. |
| get_validator_group_detailsB | Get detailed information about a specific validator group including its members and performance data. |
| get_total_staking_infoA | Get network-wide staking information including total votes and participation metrics. |
| request_faucet_fundsA | Request testnet CELO from the Celo faucet for an address. Testnet only (celo-sepolia); there is no mainnet faucet. Sends 3 CELO per request; dispenses CELO only - no USDm or other stablecoins. Requires the CELO_MCP_FAUCET_API_KEY environment variable, set to a key created at https://faucet.celo.org/keys. Limited to 10 requests per 24 hours, per account and per beneficiary address. Returns the payout transaction hash if it lands while the request is open, otherwise a request_key to check with get_faucet_request_status. |
| get_faucet_request_statusA | Check whether a queued faucet request has paid out, using the request_key returned by request_faucet_funds. Returns the payout transaction hash once the status is Done. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Most tools map cleanly to a distinct resource or action (blocks, transactions, governance, staking, faucet), and list-vs-detail pairs like get_validator_groups/get_validator_group_details are clear. However, the balance trio — get_token_balance, get_celo_balances, and get_stable_token_balance — heavily overlaps, since the latter two both return CELO plus major stablecoin balances via different mechanisms, forcing an agent to guess which to call.
All 17 tools follow a predictable snake_case verb_noun pattern, overwhelmingly get_<resource> with two sensible action verbs (request_faucet_funds, get_faucet_request_status). No mixed conventions or vague standalone verbs.
At 17 tools the surface is on the heavier side, but the domain is broad (blocks, transactions, balances, governance, staking, faucet) and each sub-area genuinely needs multiple tools. A few tools, notably the redundant balance variants, could be consolidated.
Read coverage is solid for blocks, transactions, governance proposals, validator groups, and staking balances, and the faucet pair forms a complete request/status loop. But the surface is entirely read-only: there is no governance voting, no stake/activate/unstake actions despite get_activatable_stakes, no generic contract read/call, and no event log or address-search tool, leaving dead ends for write-oriented workflows.