Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@horizen-mcp What's the Horizen mainnet chain ID and RPC URL?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives coding agents accurate, sourced facts about the Horizen chain — so they stop guessing.
When you ask an agent to deploy a contract on Horizen, configure a bridge, or integrate Stork oracle or zkVerify, it needs ground truth: the right chain ID, the right RPC URL, the right contract address. This server provides that — typed, versioned, with explicit provenance on every value. If something isn't in the registry, the agent is told so explicitly rather than making something up.
Add to ~/.claude/claude_desktop_config.json (or your project's .claude/mcp.json):
{
"mcpServers": {
"horizen": {
"command": "npx",
"args": ["-y", "horizen-mcp"]
}
}
}Same config file as Claude Code — ~/.claude/claude_desktop_config.json:
{
"mcpServers": {
"horizen": {
"command": "npx",
"args": ["-y", "horizen-mcp"]
}
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"horizen": {
"command": "npx",
"args": ["-y", "horizen-mcp"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"horizen": {
"command": "npx",
"args": ["-y", "horizen-mcp"]
}
}
}Open the Cline extension → MCP Servers tab → Edit MCP Settings → add:
{
"mcpServers": {
"horizen": {
"command": "npx",
"args": ["-y", "horizen-mcp"]
}
}
}Add to ~/.continue/config.json:
{
"mcpServers": [
{
"name": "horizen",
"command": "npx",
"args": ["-y", "horizen-mcp"]
}
]
}Add to ~/.config/zed/settings.json:
{
"context_servers": {
"horizen": {
"command": {
"path": "npx",
"args": ["-y", "horizen-mcp"]
}
}
}
}Restart your editor after saving. The server starts on demand — no separate process to manage.
Related MCP server: rome-cli MCP server
Once connected, your agent has access to Horizen chain facts through natural language:
Network info
"What's the Horizen mainnet chain ID and RPC URL?" "Give me the testnet explorer URL for Horizen."
Contract addresses
"What's the Stork oracle address on Horizen?" "What's the PureFi verifier proxy address I should integrate against?" "Is Uniswap deployed on Horizen mainnet?"
Oracle feeds
"What's the Stork feed ID for ETHUSD on Horizen?" "How do I derive a Stork feed ID for a custom asset?"
Bridges
"How do I bridge assets to Horizen?" "Does Stargate support ETH on Horizen?"
Integrations
"How do I integrate Stork oracle on Horizen?" "Can I use Den from the command line, or is it browser-only?" "Where are the Goldsky indexing docs for Horizen?" "Can I use zkVerify with Horizen? What's the contract address?" "What's the zkVerify verifier address on Horizen testnet?"
Docs search
"Search the Horizen docs for compliance gating." "Find the Horizen tutorial for setting up a multisig."
Tool | What it does |
| Chain ID, RPC/WS URLs, explorer, gas token, settlement layer for mainnet or testnet |
| Verified address for a given contract + network. Returns explicit not-found on miss — never fabricates. |
| All contracts in the registry with per-network deployment status |
| Stork oracle feed ID for an asset (e.g. |
| Bridge URLs, supported assets, and caveats — native bridge vs. Stargate |
| Docs paths, access method, status for Stork, Goldsky, PureFi, Den, zkVerify |
| Live search across docs.horizen.io with title, URL, and excerpt |
Every response includes a source field and a verified date. If a value isn't in the registry, the agent gets an explicit not-found with a list of what is known — never a guess.
git clone https://github.com/horizenio/horizen-mcp
cd horizen-mcp
npm install
npm run build
node dist/index.jsTo point your editor at a local build instead of npm:
{
"mcpServers": {
"horizen": {
"command": "node",
"args": ["/path/to/horizen-mcp/dist/index.js"]
}
}
}npm run dev # watch mode — recompiles on save
npm run inspect # MCP Inspector UI for interactive tool testingThe Inspector lets you call any tool directly and inspect the full JSON response before connecting to an editor.
All facts live in data/chain-facts.json. Tool handlers query this file — nothing is hardcoded in source. To update a value, edit that file and run npm run build.
Every entry carries a source (URL or attribution) and a verified date. Values that haven't been confirmed are left as null rather than guessed — the tool will tell the agent the value is unknown rather than returning something fabricated.
See CONTRIBUTING.md for how to add contracts, integrations, or tools.
MIT
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).
| Name | Required | Description | Default |
|---|---|---|---|
| leaf | No | Your proof's leaf hash in the aggregation Merkle tree. Obtained via aggregate_statementPath RPC on the zkVerify node. | |
| index | No | Index of your proof leaf within the aggregation Merkle tree. | |
| network | No | Horizen network to check. Mainnet is the default. Testnet uses a different contract address. | mainnet |
| domainId | Yes | zkVerify domain ID — identifies the aggregation domain. Obtained from the zkVerify SDK after proof submission. | |
| leafCount | No | Total number of leaves in the aggregation Merkle tree. | |
| merklePath | No | Merkle proof path from your leaf to the aggregation root. Obtained via aggregate_statementPath RPC. | |
| aggregationId | Yes | zkVerify aggregation ID. Obtained from the zkVerify SDK after proof submission. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden, and it does well. It states the underlying contract reads (proofsAggregations and verifyProofAggregation), what each returns ('returns the Merkle root if posted' and 'get a definitive on-chain bool'), and provides the exact contract addresses for both networks. It doesn't detail error handling or exact return structures, but for a read-only check this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but every sentence earns its place: purpose, two modes, contract addresses, and network support. It is well-structured with clear mode separation, though it could be slightly more concise by trimming redundant phrasing. It's appropriately sized for a tool with 7 parameters and two modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, two modes, two networks) and no output schema, the description is remarkably complete. It explains both modes, the required parameters for each, the network options with contract addresses, and the expected return values (Merkle root or bool). Nothing essential for an agent to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich per-parameter descriptions, so the baseline is 3. The tool description adds relational meaning by explaining which parameters belong to which mode and that leaf, merklePath, leafCount, and index are only required for full verification. It also ties parameters to the RPC source ('Obtained via aggregate_statementPath RPC'), which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: 'Check whether a zkVerify proof aggregation has been posted to Horizen by reading the zkVerify aggregation proxy contract.' It specifies two distinct modes with concrete on-chain calls, making it unambiguous and clearly differentiated from sibling tools that deal with integration/chain info, contract addresses, and price feeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly details when to use each mode: 'Two modes: (1) existence check — provide domainId and aggregationId only; ... (2) full verification — also provide leaf, merklePath, leafCount, and index.' It also clarifies the network selection with 'Supports both mainnet... and testnet' and the default. This gives direct, actionable guidance without needing to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | ||
| assetId | Yes | ||
| baseUrl | No | Stork REST API base URL. Defaults to https://rest.jp.stork-oracle.network |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation is authenticated, returns a full signed payload, and annotates field types (e.g., uint64, int192). It implies a read-only pull and does not mention side effects, which is appropriate. It does not cover error behavior or rate limits, but that is not critical for this simple fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. The purpose is front-loaded, and each sentence adds value: purpose, return format with types, and usage guidance. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers the core return information (signed payload, field types, and how to use the call data). It does not detail the full response structure or error cases, but for a straightforward price fetch it is adequate. The tool's simplicity and clear purpose make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only baseUrl has a description). The description does not explicitly explain apiKey or assetId beyond implying them via 'authenticated' and 'for an asset'. It does not mention the default baseUrl or any parameter specifics, leaving the agent to rely on schema patterns. Given low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Perform an authenticated pull') and a clear resource ('live signed price update for an asset'). It also adds unique details like returning a signed payload with Solidity type annotations, which clearly distinguishes it from the sibling info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (to get a signed price update) and even provides guidance on using the returned solidityCallData field in a downstream contract call. However, it does not explicitly contrast with sibling tools or state when not to use it, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bridge information for Horizen. Covers the native Caldera bridge and Stargate (LayerZero OFT). Always includes caveats about ETH/Stargate limitations.
| Name | Required | Description | Default |
|---|---|---|---|
| bridge | No | ||
| network | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a relevant behavior: 'Always includes caveats about ETH/Stargate limitations,' which sets expectations. However, it does not mention return shape, failure modes, or any other limitations, so the behavioral disclosure is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each with a distinct purpose: state the tool's goal, its scope, and a behavioral guarantee. No filler or redundant phrasing; the most identifying information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info-getting tool, the description covers the core subject and even highlights recurring caveats. But with no output schema, no annotations, and no guidance on default behavior when optional parameters are omitted, the description leaves some practical usage questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning for one enum: 'native Caldera bridge and Stargate (LayerZero OFT)' explains the bridge parameter values. However, the network parameter is not mentioned at all, leaving half the parameter space unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get bridge information for Horizen.' It also clarifies scope by naming the two covered bridges (native Caldera and Stargate/LayerZero OFT), which clearly distinguishes it from sibling tools like get_chain_info or get_token_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for bridge-related queries on Horizen, but it never explicitly says when to use it instead of a sibling tool or what to do when bridge or network is omitted. The context is clear enough that an agent could infer usage, but no direct guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Horizen network metadata: chain ID, RPC URL, explorer URL, gas token, settlement layer.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does indicate the operation is a retrieval and what output fields to expect. It does not disclose anything beyond the returned fields, such as network availability, auth requirements, or response structure, so transparency is adequate but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with a clear front-loaded verb and a tidy list of the returned metadata. No filler or duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description lists the substantive return fields, while the schema documents the only input. Minor omissions such as output formatting/response details prevent a 5, but nothing essential is missing for selecting or calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the only parameter ('network') has a self-documenting enum (mainnet/testnet). The description adds no explicit explanation of the parameter, though the word 'network' in the description and the enum together make it unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('Horizen network metadata') and enumerates concrete fields (chain ID, RPC URL, explorer URL, gas token, settlement layer). This specificity makes it distinguishable from siblings like get_bridge_info or get_token_info even without an explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is appropriate whenever an agent needs Horizen chain-level metadata, listing the exact fields available. It does not, however, state when to prefer this over sibling tools or give any exclusions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a verified contract address on Horizen mainnet or testnet. Returns explicit not-found when unavailable — never guesses.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | ||
| contract | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses a meaningful behavioral guarantee ('Returns explicit not-found when unavailable — never guesses') and clarifies that only verified addresses are returned. It still omits return format and data-source details, but for a simple lookup this is solid coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core operation and the useful not-found behavior are both front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers its core use, network scope, and failure behavior. However, the ambiguous 'contract' parameter and the absence of sibling routing make it only minimally complete for confident agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies 'network' by naming mainnet/testnet, but leaves 'contract' underspecified: an agent cannot tell whether to pass a symbol, name, or address, which is critical for a contract-address lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Get ... verified contract address') and scopes it to Horizen mainnet or testnet. The 'verified' qualifier and not-found guarantee help separate it from generic address/contract lookups, but it does not explicitly contrast with sibling tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence explains when to choose this tool over siblings such as get_token_info or list_contracts. The only contextual hint is the network scope in the first sentence, which is implied usage rather than actual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a Horizen integration (stork, goldsky, purefi, den, zkverify) — category, status, supported networks, access method, and docs paths.
| Name | Required | Description | Default |
|---|---|---|---|
| integration | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only retrieval, but it does not disclose that the 'integration' parameter is optional (required: 0) or what happens when omitted. It also does not mention potential errors, rate limits, or response size. This is a notable gap for a simple but unverified behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the operation and resource. Every phrase adds value: the integration list, the field names, and the parenthetical clarification. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description must fully specify the return contract. It lists the returned categories but omits the response format, the behavior for an omitted parameter, and any error conditions. Combined with the missing usage guidance, an agent has enough to grasp the basic purpose but not enough to confidently call it in all valid states (especially the no-argument case).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only an enum with no description (coverage 0%). The description repeats the enum values and adds context about the returned fields, which helps the agent understand the parameter's purpose. However, it does not explain the optionality of the parameter or how omitting it changes the call, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact verb ('Get') and resource ('details about a Horizen integration'), lists the valid integration names, and specifies the kinds of details returned (category, status, supported networks, access method, docs paths). This clearly distinguishes it from sibling get_* tools that target chains, bridges, tokens, or contract addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (get_chain_info, get_bridge_info, get_token_info, etc.). It neither states the selection criteria nor mentions exclusions. An agent would have to infer the appropriate context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the Stork oracle feed ID for an asset (e.g. ETHUSD). Derived via keccak256(assetId). Returns verified flag for known IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| assetId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it adds substantive details: the ID is derived via keccak256(assetId) and only known IDs carry a verified flag. It does not fully define behavior for unknown assets or the exact return shape, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loads the main purpose, and every sentence adds value: purpose/example, derivation method, and return flag. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deterministic compute tool with a single parameter and no output schema, the description covers what the agent needs to invoke it: the input, the derivation, and a key return detail. It could be slightly more explicit about the response format and unknown-asset handling, but the missing information is minor at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the single assetId parameter is meaningfully explained: it is an asset identifier with the example ETHUSD and is fed into keccak256. This compensates for the schema gap for a one-parameter tool, though it stops short of listing supported asset ID values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and resource ('Stork oracle feed ID for an asset'), with a concrete example (ETHUSD). It is clear, but it does not explicitly contrast itself with sibling tools such as fetch_stork_price, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended context is implied: use this tool when an asset's Stork feed ID is needed, as opposed to fetching price data. However, the description does not state when-not-to-use or name an alternative, leaving the vs-alternatives guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Token key: zen (ZEN governance token), cbtc (cbBTC — Coinbase Bitcoin, 8 decimals), usdce (USDC.e — bridged USDC, 6 decimals). Omit to list all tokens. | |
| network | No | Which network's addresses to return. Defaults to mainnet. | mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return scope (Horizen address plus Base/Base Sepolia cross-chain addresses), highlights the notable cbBTC decimal pitfall ('8 decimals — NOT 18'), and explains the omit-token behavior. It doesn't cover auth/rate limits, but this is a read-only info tool where that is less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero filler: token specs/decimals in sentence one, cross-chain address scope in sentence two, and omit-token behavior in sentence three. The most salient content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param optional read tool with enums and full schema coverage, the description provides the essential domain facts (decimals, networks, list-all behavior) needed to invoke it correctly. The absence of a precise return format is a minor gap, and no output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already documented in the schema with the same token/network details. The description largely restates this, adding minor texture like 'governance' and 'bridged' and re-emphasizing the cbBTC decimal warning. This meets the baseline 3 for high schema coverage but adds little new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Get token addresses and specs') and a specific resource ('tokens on Horizen'), enumerating the three supported tokens. It is clearly distinguishable from siblings like get_chain_info or get_contract_address, though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need token addresses/specs or want to list all tokens. It provides within-tool guidance (omit token to list all), but gives no explicit when-to-use vs alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all contracts in the registry with their display names and which networks they are deployed on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It correctly indicates this is a read-only listing of all contracts with specific output fields, but it does not mention pagination, potential response size, or whether any registry census scope is limited. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action, that conveys the tool's purpose and its key output without unnecessary wording. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, this description provides enough to know when to call and what will be returned. It lacks minor context like response shape or possible scale of results, but it is reasonably complete for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. It still hints that the call is unfiltered ('all contracts'), which is useful given the empty parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('List all contracts in the registry'), a clear resource scope, and names the returned fields (display names and deployed networks). This distinguishes it from more targeted siblings like get_contract_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives like get_contract_address for specific contracts. The word 'list' implies the use case, but there is no direct support for choosing between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0check_zkverify_statusfetch_stork_priceget_bridge_infoget_chain_infoget_contract_addressget_integration_infoget_stork_feed_idget_token_infolist_contractsScored 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.
Evidence-backed crypto due diligence with sources, freshness, and a runtime receipt on every call.
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Read-only BTC/XMR/ZEC/DOGE/LTC chain data for AI agents (16 tools)
Manage your blockchain infrastructure across 80+ chains with your agents.
