horizen-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_chain_infoA | Get Horizen network metadata: chain ID, RPC URL, explorer URL, gas token, settlement layer. |
| get_contract_addressB | Get a verified contract address on Horizen mainnet or testnet. Returns explicit not-found when unavailable — never guesses. |
| list_contractsA | List all contracts in the registry with their display names and which networks they are deployed on. |
| get_stork_feed_idA | Compute the Stork oracle feed ID for an asset (e.g. ETHUSD). Derived via keccak256(assetId). Returns verified flag for known IDs. |
| get_bridge_infoA | Get bridge information for Horizen. Covers the native Caldera bridge and Stargate (LayerZero OFT). Always includes caveats about ETH/Stargate limitations. |
| get_integration_infoB | Get details about a Horizen integration (stork, goldsky, purefi, den, zkverify) — category, status, supported networks, access method, and docs paths. |
| fetch_stork_priceA | Perform an authenticated pull from the Stork REST API to get a live signed price update for an asset. Reads the Stork API key from the STORK_API_KEY environment variable (not a tool argument). Returns the full signed payload with each field annotated with its correct Solidity type (timestampNs as uint64 in nanoseconds; quantizedValue as int192 — not uint256). Use the solidityCallData field directly when constructing an updateTemporalNumericValueV1 call. |
| check_zkverify_statusA | Check whether a zkVerify proof aggregation has been posted to Horizen by reading the zkVerify aggregation proxy contract. Two modes: (1) existence check — provide domainId and aggregationId only; reads proofsAggregations(domainId, aggregationId) and returns the Merkle root if posted; (2) full verification — also provide leaf, merklePath, leafCount, and index to call verifyProofAggregation(domainId, aggregationId, leaf, merklePath, leafCount, index) and get a definitive on-chain bool. Supports both mainnet (0xCb47A3C3B9Eb2E549a3F2EA4729De28CafbB2b69) and testnet (0x3098A6974649478f0133046e44105AA84e868C21). |
| get_token_infoA | Get token addresses and specs for tokens on Horizen: ZEN (governance, 18 decimals), cbBTC (Coinbase Bitcoin, 8 decimals — NOT 18), USDC.e (bridged USDC, 6 decimals). Returns Horizen address plus cross-chain addresses (Base, Base Sepolia). Omit token to list all tokens with their decimals. |
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 9 tools
Each tool targets a distinct resource/action: integration metadata, Stork feed IDs, live Stork prices, contract registry listing/lookup, zkVerify proof status, bridge info, chain info, and token info. The only potentially related pairs (list_contracts vs get_contract_address, get_stork_feed_id vs fetch_stork_price) are clearly separated by action and description.
All tool names follow a consistent verb_noun snake_case pattern (get/list/fetch/check prefix plus a specific object). Verbs vary slightly but are semantically appropriate for each operation, and no naming style mixes with camelCase or vague terms.
Nine tools is a well-scoped size for an informational Horizen integration server. Each tool corresponds to a distinct useful query, and none feel redundant or filler.
The surface covers the apparent domain well: chain metadata, token and bridge details, contract registry lookup, Stork oracle feed derivation and price fetching, zkVerify status checks, and high-level integration info. For a read-only ecosystem information server, there are no major dead ends or missing lifecycle steps.