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. 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 clearly distinct resource or action: chain metadata, integration info, contract addresses/registry, Stork feed IDs/prices, bridge info, token specs, and zkVerify proof status. Even related Stork and contract tools are separated cleanly and described without ambiguity.
All tool names follow a snake_case action_noun pattern, predominantly get_<entity>_info or get_<entity>_address. The list_, fetch_, and check_ deviations are semantically justified for listing, live API pulls, and verification, so the naming remains predictable and consistent.
With 9 tools, the server is well-scoped for its purpose: chain metadata, integration info, contract registry, bridge info, tokens, Stork oracle, and zkVerify each have a dedicated tool. There is no obvious redundancy or bloat.
The surface covers the main Horizen ecosystem information needs: network metadata, registry addresses, token details, bridge info, Stork feed ID/price, and zkVerify verification. It includes multi-network support, explicit not-found semantics, and no obvious dead ends or missing operations.