Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.chainhelix/intel

REMOTE · MCP.CHAINHELIX.IO · SCANNED SEP 26

Nine chain onchain intelligence with a verifiable onchain signal attestation stream

0 this week 74 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security63
Transport & Reachability100
Schema Quality & AI Usability64
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 11394 tokens (~140/item across 81 items; 81 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage79
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 26% of tool parameters carry a description.Partial
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "webhook_unregister" implies "remove" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
  • An AI judge read all 82 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
  • Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
Install

How do I install the io.chainhelix/intel MCP server?

io.chainhelix/intel is a hosted endpoint at https://mcp.chainhelix.io/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · mcp.chainhelix.io

# add to Claude Code
claude mcp add --transport http io-chainhelix-intel 'https://mcp.chainhelix.io/'
// .cursor/mcp.json
{
  "mcpServers": {
    "io-chainhelix-intel": {
      "url": "https://mcp.chainhelix.io/"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "io-chainhelix-intel": {
      "type": "http",
      "url": "https://mcp.chainhelix.io/"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.io-chainhelix-intel]
url = "https://mcp.chainhelix.io/"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "io-chainhelix-intel": {
      "type": "remote",
      "url": "https://mcp.chainhelix.io/",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add io-chainhelix-intel --url 'https://mcp.chainhelix.io/' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  io-chainhelix-intel:
    url: "https://mcp.chainhelix.io/"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "io-chainhelix-intel": {
      "Transport": "http",
      "Url": "https://mcp.chainhelix.io/"
    }
  }
}
# add to Vellum
assistant mcp add io-chainhelix-intel -t streamable-http -u 'https://mcp.chainhelix.io/'
// mcp.json
{
  "mcpServers": {
    "io-chainhelix-intel": {
      "type": "http",
      "url": "https://mcp.chainhelix.io/"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 25 Sept 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 23 Sept 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “attest” rewrote its description, which is the text the model reads security
    • Tool “cleared_buyer” rewrote its description, which is the text the model reads security
    • Tool “lexicon_bundle” rewrote its description, which is the text the model reads security
    • Tool “lexicon_spec” rewrote its description, which is the text the model reads security
    • Tool “lexicon_statement” rewrote its description, which is the text the model reads security
    • Tool “standing_watch” rewrote its description, which is the text the model reads security
    • Tool “stream_register” rewrote its description, which is the text the model reads security
    • Tool “stream_register_all” rewrote its description, which is the text the model reads security
    • Tool “webhook_register” rewrote its description, which is the text the model reads security
    • Tool “webhook_status” rewrote its description, which is the text the model reads security
    • “webhook_status” added an optional parameter “secret” cosmetic
  • 20 Sept 26 0
    • New tool “lexicon_bulk” functional
    • New tool “lexicon_bundle” functional
    • New tool “lexicon_resolve” functional
    • New tool “lexicon_spec” functional
    • New tool “lexicon_statement” functional
    • “freshness” reworded the description of “name” cosmetic
  • 19 Sept 26 0
    • Tool “screened_payer” rewrote its description, which is the text the model reads security
    • New tool “agent_standing” functional
    • New tool “standing_bulk” functional
    • New tool “standing_spec” functional
    • New tool “standing_watch” functional
  • 18 Sept 26 0
    • Tool “webhook_register” rewrote its description, which is the text the model reads security
    • New tool “lead_alerts” functional
    • New tool “lead_alert_spec” functional
    • New tool “verify_lead_alert” functional
  • 17 Sept 26 0
    • Tool “cleared_buyer” rewrote its description, which is the text the model reads security
    • Tool “screened_payer” rewrote its description, which is the text the model reads security
    • Tool “webhook_register” rewrote its description, which is the text the model reads security
    • Schema quality: 8474 → 9342 ▼ functional
    • New tool “mev_flow_spec” functional
    • New tool “mev_pressure” functional
    • New tool “stream_register” functional
    • New tool “stream_register_all” functional
    • New tool “victim_flow” functional
  • 15 Sept 26 0
    • Tool “freshness” rewrote its description, which is the text the model reads security
    • New tool “fill_receipts” functional
    • New tool “instrument_signals” functional
    • New tool “instrument_spec” functional
    • New tool “instrument_state” functional
    • New tool “instruments” functional
    • New tool “verify_fill” functional
    • New tool “verify_instrument_signal” functional
  • 9 Sept 26 0
    • New tool “buyer_clearance” functional
    • New tool “cleared_buyer” functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 26 Sept 2026 · Probed https://mcp.chainhelix.io

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=mcp.chainhelix.io CN=YE2,O=Let's Encrypt,C=US 4 Aug 2026 2 Nov 2026 ECDSA 256 ECDSA-SHA384 58dfca8b86ac99ef956724aa8f5dcb222f8
SANs: mcp.chainhelix.io
CN=YE2,O=Let's Encrypt,C=US (CA) CN=Root YE,O=ISRG,C=US 3 Sept 2025 2 Sept 2028 ECDSA 384 ECDSA-SHA384 4df3b15dd6c0784c507cd37b58e6f115
CN=Root YE,O=ISRG,C=US (CA) CN=ISRG Root X2,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 ECDSA-SHA384 872165fc34b6e5fba8add5b3705fb53a
CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) CN=ISRG Root X1,O=Internet Security Research Group,C=US 13 May 2026 2 Sept 2032 ECDSA 384 SHA256-RSA 6c8f1dc727c7117f7baf853ac980f9cd

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of mcp.chainhelix.io. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
io. present 57355 8 Verified
chainhelix.io. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
strict-transport-security max-age=31536000; includeSubDomains
x-content-type-options nosniff
x-frame-options DENY
referrer-policy strict-origin-when-cross-origin
permissions-policy camera=(), microphone=(), geolocation=()

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://mcp.chainhelix.io Verified 200
http (plaintext) http://mcp.chainhelix.io HTTPS enforced 301 https://mcp.chainhelix.io/
MCP tools · 81 exposed · ~11,079 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
agent_report ~161

Requires a ChainHelix API key as bearer token, or 5 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. One agent on BNB Smart Chain, its newest probe from the ChainHelix sweep (probedAt and ageSeconds say how fresh; the sweep re-probes the live set about every minute and the whole registry on a rolling basis) read from its own onchain registration, with its probe history, every ChainHelix test hire with result, latency, size and cost, the permanent evidence records on BNB Greenfield, its registration link and how to hire it

NameTypeReqDescription
idnumberyes–
NameTypeReqDescription
endpointstring|null––
evidenceobject|null––
hireobject|null––
historyarray––
idnumberyes–
latencyMsnumber|null––
metaobject––
namestring|null––
probedAtnumber|null––
receiptobject––
registrationstring|null––
statusstring|null––
testSummaryobject|null––
testsarray––

No examples provided.

agent_standing ~231

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. The standing of one ERC-8004 agent on BNB Smart Chain from what it did, not what it declares: its evidence tier from the paid ERC-8183 hires ChainHelix funded and the delivery checks sealed on opBNB, whether it answers right now from the newest probe, and the feedback rows the registry holds for it graded by pattern (on BSC today they come from a rating farm). Every count carries its evidence: job ids, transactions, the registry read. Signed (EIP-191, the published ChainHelix statement signer), valid 24 hours. ChainHelix agents come back as first_party: evidence only, no verdict, no signature. Free without the signature at agents.chainhelix.io/standing/<id>.

NameTypeReqDescription
idnumberyesthe ERC-8004 token id on BNB Smart Chain
NameTypeReqDescription
agentstring––
declaredobject|null––
errorstring|null––
firstPartyboolean––
howToVerifyarray––
idnumberyes–
metaobject––
namestring|null––
nowstringyes–
nowMeansstring––
ownExampleobject|null––
ownerstring|null––
pagestring––
paidHiresobject|null––
permanentEvidenceobject|null––
probeobject|null––
receiptobject––
registryFeedbackobject|null––
sealedChecksarray––
statementobject|null––
tierstringyes–
tierMeansstring––
verifystring––
versionnumber––

No examples provided.

attest ~180

5 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. A ChainHelix API key does not cover this tool. Seal any claim on chain now, reveal it later, a track record nobody can backdate. Send your claim as the payload string with an optional revealDelayHours from 1 to 720, default 72. Your identity is your paying wallet, or your key id. ChainHelix seals the exact time of your commitment on the opBNB chain; the claim text and salt publish automatically at reveal time. This attests WHEN you said it, never whether it is true. Verification spec: the free attest_spec tool

NameTypeReqDescription
payloadstringyes–
revealDelayHoursnumber––
NameTypeReqDescription
committedAtnumber––
errorstring––
hashstring––
notestring––
receiptobject––
revealAtnumber––
revealDelayHoursnumber––
seqnumber––
statusstring––
tenantstring––

No examples provided.

attest_spec ~31

The machine verification spec for the attestation service, how sealed claims are hashed, put on chain and verified independently

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

attest_status ~105

Check one sealed claim by tenant plus seq or hash. Before reveal time only the receipt shows; after it the claim text and salt are included. With a nonce it returns the receipt of a paid answer instead: the sha256 of the answer bytes, its sequence number and, once sealed, the opBNB batch transaction and Merkle path

NameTypeReqDescription
hashstring––
noncestring––
seqnumber––
tenantstringyes–
NameTypeReqDescription
commitobject––
errorstring––
foundbooleanyes–
receiptobject––
recordobject––

No examples provided.

attestation_stats ~25

Live counts of the attestation stream: committed, anchored, revealed, gaps

Input schema present but exposes no named parameters.

NameTypeReqDescription
anchorsnumberyes–
awaitingMaturitynumberyes–
committednumberyes–
gapsnumberyes–
latestSeqnumberyes–
revealDelayHoursnumberyes–
revealednumberyes–

No examples provided.

bridge_flows ~125

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Layer two bridge activity for arbitrum, base and optimism over a window: deposits, withdrawals proven and finalized, message counts, value moved in ETH. window in hours, default 24, max 720. Omit l2 for all three

NameTypeReqDescription
l2string––
windownumber––
NameTypeReqDescription
metaobject––
receiptobject––
resultsarrayyes–

No examples provided.

btc_mempool_history ~108

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Bitcoin mempool over a window: fastest fee, transaction count and size as a sampled series with the window high, low and latest. window in hours, default 24, max 168

NameTypeReqDescription
windownumber––
NameTypeReqDescription
feeHighnumber|null––
feeLownumber|null––
latestobject|null––
metaobject––
receiptobject––
samplesnumber––
seriesarray––
sourcestring|null––
windowHoursnumberyes–

No examples provided.

builder_relays ~101

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Ethereum block builder market over a window: blocks delivered and value per relay, and the top builders by blocks. window in hours, default 24, max 720

NameTypeReqDescription
windownumber––
NameTypeReqDescription
chainstring––
latestBucketnumber|null––
metaobject––
receiptobject––
relaysarrayyes–
sourcestring––
topBuildersarray––
windowHoursnumber––

No examples provided.

buy_key ~180

Buy a ChainHelix API key without a browser or account. Pick a plan (standard 99 dollars a month at 120 requests per minute, or pro 249 dollars a month at 600 requests per minute) and a payment chain (ethereum, solana, bnb, polygon, tron, avalanche or sui). Returns a payment address, an exact amount in USDC or USDT, and a claim token. Send the exact amount, then call claim_key. Orders expire after 24 hours, or sooner under load (2 hours when more than 25 orders are open, 30 minutes above 40). Email is required for the alerts plan (Telegram delivery) and optional otherwise; with one, the key and receipt are also emailed

NameTypeReqDescription
chainstringyes–
emailstring––
planstringyes–

Structured output declared, but exposes no named fields.

No examples provided.

buyer_clearance ~77

The standing clearance on file for a wallet: whether a cleared buyer record exists, its paid period, the current signed sanctions statement, how many times it has been renewed and when it renews next. Send an EVM address. A seller reads this before taking a job instead of paying for a screen

NameTypeReqDescription
addressstringyes–
NameTypeReqDescription
activeboolean|null––
currentobject|null––
currentFreshboolean|null––
enrolledAtstring|null––
errorstring|null––
howstring|null––
howToVerifyarray––
networkstring|null––
nextRenewalAtstring|null––
onFilebooleanyes–
renewEveryHoursnumber|null––
renewalsnumber|null––
resultstring|null––
validUntilnumber|null––
walletstring|null––

No examples provided.

candles ~120

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Price history: open, high, low, close, volume and trade count per candle for one chain, any of fourteen timeframes from one minute to one week, up to 500 candles newest last

NameTypeReqDescription
chainstringyes–
limitnumber––
timeframestring––
NameTypeReqDescription
candlesarrayyes–
chainstringyes–
countnumber––
latestAtnumber|null––
metaobject––
receiptobject––
sourcestring––
timeframestringyes–

No examples provided.

chain_brief ~114

Requires a ChainHelix API key as bearer token, or 5 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. One chain, the whole read in one answer: market state with momentum, price walls, large transfers, bot activity, open interest, stablecoin flows and, for bitcoin, the mempool. Sections that fail are named in unavailable

NameTypeReqDescription
chainstringyes–
NameTypeReqDescription
chainstringyes–
generatednumberyes–
metaobject––
receiptobject––
unavailablearray––

No examples provided.

claim_key ~56

Claim the API key for a paid buy_key order. Takes the claim token. The key is returned exactly once, save it. Payments usually become claimable within 30 minutes of confirming on chain

NameTypeReqDescription
claim_tokenstringyes–

Structured output declared, but exposes no named fields.

No examples provided.

cleared_buyer ~179

2 dollars per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. A ChainHelix API key does not cover this tool. A standing sanctions clearance for your wallet, on file for any seller to read before it takes your job. 2 dollars buys 30 days: the wallet that pays this call is screened now against the OFAC SDN list and the on-chain sanctions oracle, the signed statement is kept on file and renewed every 24 hours for the period, and buyer_clearance (free) returns the current statement to anyone who asks. Call again to extend; the same payment never credits twice. Pay with the wallet to be cleared: a key id cannot be cleared

NameTypeReqDescription
networkstring––
NameTypeReqDescription
activeboolean––
currentobject|null––
currentFreshboolean––
daysAddednumber|null––
enrolledAtstring––
errorstring|null––
howToVerifyarray––
metaobject––
networkstring––
nextRenewalAtstring|null––
notestring|null––
onFileboolean––
receiptobject––
renewEveryHoursnumber––
renewalsnumber––
resultstring|null––
screenedNowboolean|null––
validUntilnumber––
walletstring––

No examples provided.

congestion ~74

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Bitcoin queue depth now vs the past 30 days plus the current fastest fee

Input schema present but exposes no named parameters.

NameTypeReqDescription
asOfnumber|null––
fastestFeenumber|nullyes–
median30dnumber|nullyes–
metaobject––
p90_30dnumber|nullyes–
pendingTransactionsnumberyes–
receiptobject––
sourcestring––

No examples provided.

correlation_matrix ~87

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Pairwise correlation of hourly returns across the nine chains. window in days default 7 max 30

NameTypeReqDescription
windownumber––
NameTypeReqDescription
asOfnumber|null––
meannumber|null––
metaobject––
pairsarrayyes–
receiptobject––
sourcestring––
windowDaysnumberyes–

No examples provided.

daily_digest ~62

One hash per day: the Merkle digest of every reveal, hire deliverable and verification record stored on BNB Greenfield that day, with its root sealed on opBNB. Optional date YYYY-MM-DD, default the latest

NameTypeReqDescription
datestring––
NameTypeReqDescription
datestring|null––
daysarray––
digestBytesnumber|null––
digestSha256string|null––
digestUrlstring|null––
foundbooleanyes–
leavesnumber|null––
rootstring|null––
sealedobject|null––
verifystring|null––

No examples provided.

data_changelog ~73

Dated record of every change to the data this server sells: rule flips, label fixes, duplicate removals, band versions, sample notices, each with the date, the tools affected and the count. Optional tool name to filter, and limit

NameTypeReqDescription
limitnumber––
toolstring––
NameTypeReqDescription
countnumberyes–
disabledboolean––
entriesarrayyes–
errorstring––
toolstring|null––
updatedstring|null––

No examples provided.

deep_report ~134

Requires a ChainHelix API key as bearer token, or 25 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. The complete nine chain research brief in one call: the full market report with price walls, large transfers and bot activity, the live signal stream with conviction scores and ranking tiers, cross chain correlations, options volatility, session statistics and the proof stream counters, with links to verify every signal on chain. The most complete single answer this server produces

NameTypeReqDescription
chainstring––
NameTypeReqDescription
correlationsobject|null––
generatednumberyes–
metaobject––
optionsVolatilityarray|object|null––
proofobject|null––
receiptobject––
reportobject|null––
sessionsarray|object|null––
signalsarray|null––
verifyobject––

No examples provided.

delivery_spec ~43

How to verify a sealed delivery claim yourself: the canonical form, the hash, the calldata layout on opBNB, what each check means and the steps to repeat them

Input schema present but exposes no named parameters.

NameTypeReqDescription
canonicalstring––
checksobject––
hashstring––
namestring––
sealobject––
statsobject––
toVerifyarray––
verdictsobject––

No examples provided.

delivery_status ~131

Requires a ChainHelix API key as bearer token, or 1 cent per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. The sealed delivery claim for a hire. Send the job id, or the sequence number, or the claim hash. Returns the claim, its hash and the opBNB transaction once sealed. A hire with no claim on record is refused before any charge

NameTypeReqDescription
hashstring––
jobnumber––
seqnumber––
NameTypeReqDescription
errorstring|null––
foundbooleanyes–
metaobject––
receiptobject––
recordobject––
totalnumber|null––

No examples provided.

fill_receipts ~145

Requires a ChainHelix API key as bearer token, or 1 cent per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Exchange fill receipts of the instrument lane, newest first: the signal timestamp that caused the fill, venue, side, quantity, price, slippage against the signal, the exchange order id, and the seal batch and transaction once sealed. Optional instrument, signalTs, limit (default 50, max 500)

NameTypeReqDescription
instrumentstring––
limitnumber––
signalTsnumber––
NameTypeReqDescription
countnumber––
metaobject––
receiptobject––
receiptsarray––

No examples provided.

freshness ~105

Free check before you pay: for every data tool, the content hash and validUntil of its current default result (all chains). If the hash matches what you already hold, nothing changed and there is nothing to buy. A tool that needs arguments has no default result and is listed with requiresArguments; its paid answer carries its own meta.contentHash. Optional name for one tool

NameTypeReqDescription
namestring–one data tool to check; omit for all (also accepted as: tool)
NameTypeReqDescription
checkedAtnumberyes–
notestring|null––
toolsarrayyes–

No examples provided.

gas_state ~104

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Network load per chain: latest transaction count, MEV count and rate, average gas and large transaction count, against the 24 hour average of each. Omit chain for all nine

NameTypeReqDescription
chainstring––
NameTypeReqDescription
metaobject––
receiptobject––
resultsarrayyes–

No examples provided.

governance_activity ~126

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. DAO governance on Snapshot over a window: proposals, votes and scores per space, most active first. space is a Snapshot space id such as aavedao.eth. window in hours, default 168, max 2160

NameTypeReqDescription
limitnumber––
spacestring––
windownumber––
NameTypeReqDescription
metaobject––
receiptobject––
resultsarrayyes–

No examples provided.

hire_plan_gridtrader ~529

Plan a hire of the ChainHelix gridtrader agent (ERC-8004 #269224, Grid trading ladder). Given a mark price and a budget, returns a symmetric buy/sell grid: buy levels below the price, sell levels above, equal USD size per level, and when strong price walls are supplied each level is annotated with its nearest wall and flagged if it sits on one. Deterministic arithmetic, no custody, no execution. Not a bounded-loss or profit-target strategy: fees, slippage, gas and PnL are not computed. Send the job parameters; you get back the agent's live wallet-signed quote (the job price, paid into escrow on chain when you fund) and the createJob calldata to sign from YOUR wallet, then fund and tell the agent (steps in the answer). This call is free; the job is not. The parameters here are exactly what the agent accepts; the same schema is on its agent card at https://agents.chainhelix.io/gridtrader/.well-known/agent-card.json. Example: {"price":691.65,"budgetUsd":1000,"levels":5,"spanPct":2,"walls":{"677.8":3,"705.5":2}}

NameTypeReqDescription
budgetUsdnumber–total capital to ladder (also accepted as: capitalUsd, budget, capital, notionalUsd, sizeUsd)
levelsinteger–grid lines per side, default 5 (also accepted as: gridLevels, nLevels)
lowernumber–grid lower bound in price; with upper, an alternative to spanPct
pricenumber–current mark price (also accepted as: mid, midPrice, mark, markPrice, currentPrice, spot)
spanPctnumber–half-width of the grid in percent, below 100, default 5; or send lower and upper (absolute bounds) and the half-width is derived from the wider side (also accepted as: rangePct, widthPct)
termsobject–optional ERC-8183 terms {deliverables, quality_standards}; the agent quotes its fixed price either way
uppernumber–grid upper bound in price; with lower, an alternative to spanPct
wallBandPctnumber–distance in percent that counts as on a wall, default 0.7
wallsobject–known support/resistance walls keyed by price, touches is an integer 1 to 10000; levels on a wall are flagged
NameTypeReqDescription
agentstringyes–
envelopeobject|null––
erc8004Idnumber|null––
errorstring|null––
exampleobject|null––
expectedobject|null––
missingarray|null––
nextstring|null––
planobject|null––
txobject|null––

No examples provided.

hire_plan_healthmon ~515

Plan a hire of the ChainHelix healthmon agent (ERC-8004 #269228, Position health report). Lending health: given collateral rows with liquidation thresholds, debt and prices, returns the health factor, its status (healthy, warning, critical, liquidatable) and per-asset liquidation prices with drop distances. LP range health: send `position` {price, lowerPrice, upperPrice} instead of collateral and debt. One question per job. Deterministic arithmetic, no custody, no execution. Send the job parameters; you get back the agent's live wallet-signed quote (the job price, paid into escrow on chain when you fund) and the createJob calldata to sign from YOUR wallet, then fund and tell the agent (steps in the answer). This call is free; the job is not. The parameters here are exactly what the agent accepts; the same schema is on its agent card at https://agents.chainhelix.io/healthmon/.well-known/agent-card.json. Example: {"collateral":{"ETH":{"amount":10,"liqThreshold":0.8}},"debt":{"USDT":10000},"prices":{"ETH":2000,"USDT":1}}

NameTypeReqDescription
alertHFnumber–warning level, default 1.5
collateralobject–liqThreshold in (0, 1]; required unless `position` is sent (also accepted as: collaterals, supplied, deposits)
criticalHFnumber–critical level, must be below alertHF, default 1.1
debtobject–outstanding debt per symbol; required unless `position` is sent (also accepted as: debts, borrowed, borrows, loans)
positionobject–PancakeSwap v3 LP range health instead of lending health (do not send with collateral or debt); optional nearEdgePct, feesEarnedUsd, positionValueUsd, ageDays; returns range status, distance to each…
pricesobject–a mark for every collateral and debt symbol (also accepted as: marks, quotes, pricesUsd)
termsobject–optional ERC-8183 terms {deliverables, quality_standards}; the agent quotes its fixed price either way
wallsobject–with position only: strong levels keyed by price, each range edge is annotated with the nearest one
NameTypeReqDescription
agentstringyes–
envelopeobject|null––
erc8004Idnumber|null––
errorstring|null––
exampleobject|null––
expectedobject|null––
missingarray|null––
nextstring|null––
planobject|null––
txobject|null––

No examples provided.

hire_plan_rebalancer ~392

Plan a hire of the ChainHelix rebalancer agent (ERC-8004 #269223, Portfolio rebalancing plan). Given current holdings, target weights and prices, returns current vs target weights, per-asset drift and the ordered trade list (sells before buys) that moves the portfolio to target, with the residual cash the plan does not net out. Deterministic arithmetic, no custody, no execution. Send the job parameters; you get back the agent's live wallet-signed quote (the job price, paid into escrow on chain when you fund) and the createJob calldata to sign from YOUR wallet, then fund and tell the agent (steps in the answer). This call is free; the job is not. The parameters here are exactly what the agent accepts; the same schema is on its agent card at https://agents.chainhelix.io/rebalancer/.well-known/agent-card.json. Example: {"holdings":{"BTC":1,"ETH":10},"targets":{"BTC":0.5,"ETH":0.5},"prices":{"BTC":60000,"ETH":2000},"driftThresholdPct":1}

NameTypeReqDescription
driftThresholdPctnumber–no-trade band per asset, default 1
holdingsobject–current position sizes in token units, one key per symbol (also accepted as: positions, balances, portfolio)
minTradeUsdnumber–dust filter on emitted trades, default 5
pricesobject–a mark for every symbol in holdings or targets (also accepted as: marks, quotes, pricesUsd)
targetsobject–desired weights, must sum to 1 (also accepted as: targetWeights, weights, allocation)
termsobject–optional ERC-8183 terms {deliverables, quality_standards}; the agent quotes its fixed price either way
NameTypeReqDescription
agentstringyes–
envelopeobject|null––
erc8004Idnumber|null––
errorstring|null––
exampleobject|null––
expectedobject|null––
missingarray|null––
nextstring|null––
planobject|null––
txobject|null––

No examples provided.

hire_plan_yieldopt ~462

Plan a hire of the ChainHelix yieldopt agent (ERC-8004 #269226, Yield allocation across pools). Given candidate pools with APY, optional TVL and risk score, and the capital to place, returns the allocation per pool under concentration and TVL-share caps, the blended APY and any capital left unallocated because a cap bound first. Deterministic arithmetic, no custody, no execution. Send the job parameters; you get back the agent's live wallet-signed quote (the job price, paid into escrow on chain when you fund) and the createJob calldata to sign from YOUR wallet, then fund and tell the agent (steps in the answer). This call is free; the job is not. The parameters here are exactly what the agent accepts; the same schema is on its agent card at https://agents.chainhelix.io/yieldopt/.well-known/agent-card.json. Example: {"pools":{"pcs-wbnb-usdt":{"apyPct":12.5,"tvlUsd":50000000,"riskScore":2},"venus-usdt":{"apyPct":6.1,"tvlUsd":200000000,"riskScore":1},"new-farm":{"apyPct":80,"tvlUsd":400000,"riskScore":5}},"capitalUsd":10000,"maxPerPoolPct":40}

NameTypeReqDescription
capitalUsdnumber–capital to allocate (also accepted as: budgetUsd, capital, budget, amountUsd)
maxPerPoolPctnumber–max share of capital in one pool, at most 100, default 40
poolsobject–candidate pools keyed by name; riskScore 1 (safest) to 5, default 3 (also accepted as: opportunities, vaults, farms)
riskAversionnumber–0 chases raw APY, 1 applies the full risk discount, default 0.5
termsobject–optional ERC-8183 terms {deliverables, quality_standards}; the agent quotes its fixed price either way
tvlCapPctnumber–max share of a pool's TVL to hold, default 5
NameTypeReqDescription
agentstringyes–
envelopeobject|null––
erc8004Idnumber|null––
errorstring|null––
exampleobject|null––
expectedobject|null––
missingarray|null––
nextstring|null––
planobject|null––
txobject|null––

No examples provided.

hire_quote ~135

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Ask a hireable agent on BNB Smart Chain for a live signed ERC-8183 quote through ChainHelix: send your task description and terms, receive the signed offer envelope and the steps to fund the job. Only agents the live map lists as hireable

NameTypeReqDescription
idnumberyes–
task_descriptionstringyes–
termsobject––
NameTypeReqDescription
acceptedboolean|null––
envelopeobject|null––
errorstring|null––
idnumberyes–
latencyMsnumber|null––
receiptobject––
termsobject|null––

No examples provided.

instrument_signals ~143

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. The instrument lane signals (paper book, BNB Chain venue) newest first, each with its commit status in the CHXI attestation stream: seq, hash, opBNB transaction. Optional instrument id and limit (default 50, max 500). A signal without a seq was written before the stream started or is not yet committed

NameTypeReqDescription
instrumentstring––
limitnumber––
NameTypeReqDescription
countnumber––
metaobject––
receiptobject––
signalsarray––

No examples provided.

instrument_spec ~40

How to verify an instrument signal commit and a fill receipt yourself: canonical forms, hashes, the CHXI calldata layouts on opBNB, the reveal rule

Input schema present but exposes no named parameters.

NameTypeReqDescription
namestring––
namespacestring––
productstring––
receiptobject––
signalobject––
toVerifyarray––

No examples provided.

instrument_state ~127

Requires a ChainHelix API key as bearer token, or 1 cent per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. The live state of each instrument: mark, index, basis in bps, funding rate and next funding time, top of book spread, 24h volume, feed health and age. Optional instrument id. Carries meta (contentHash, validUntil) so freshness can tell you when nothing changed

NameTypeReqDescription
instrumentstring––
NameTypeReqDescription
checkedAtnumber––
instrumentsarray––
metaobject––
receiptobject––

No examples provided.

instruments ~63

The instrument list of the ChainHelix instrument lane: SpaceX and Circle perpetuals on Aster (BNB Chain). Venue, contract, chain, fees, funding cycle, session policy and the label every answer uses. These are derivatives on the venue, never the share

Input schema present but exposes no named parameters.

NameTypeReqDescription
instrumentsarray––
namespacestring––
productstring––

No examples provided.

iv_summary ~75

Requires a ChainHelix API key as bearer token, or 2 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Near term option implied volatility for Bitcoin and Ethereum, now vs one week ago

Input schema present but exposes no named parameters.

NameTypeReqDescription
metaobject––
receiptobject––
resultsarrayyes–

No examples provided.

key_order_status ~47

Check a key order created with buy_key. Takes the claim token, reports whether the payment has been seen and whether the key is ready to claim

NameTypeReqDescription
claim_tokenstringyes–

Structured output declared, but exposes no named fields.

No examples provided.

latest_signals ~145

Requires a ChainHelix API key as bearer token, or 6 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. The live ChainHelix signal stream, newest first. Each signal names chain, direction, entry price, win probability and a conviction score with its ranking tier, and every one is sealed on chain the moment it exists so the record cannot be edited afterward. Verify any of them with the free proof tools. Optional chain, and limit up to 50

NameTypeReqDescription
chainstring––
limitnumber––
NameTypeReqDescription
metaobject––
receiptobject––
resultsarrayyes–

No examples provided.

lead_alert_spec ~57

The lead alerts explained: what each of the three reads measures, when alerts are written, the fields of an alert, the webhook event, and how to verify an alert commit in the CHXL stream on opBNB without trusting us

Input schema present but exposes no named parameters.

NameTypeReqDescription
namestring––
namespacestring––
productstring––
readsobject––
revealOnboolean––
sealingobject––
toVerifyarray––

No examples provided.

lead_alerts ~253

Requires a ChainHelix API key as bearer token, or 6 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Lead alerts on nine chains, newest first: three long reads checked once per closed hour per chain. vol_spike_long (an hour of volume far above its average with a positive MACD histogram), capitulation_long (a high volume down bar, measured in ATR), onchain_spike_long (the chain's own transaction or MEV activity far above its trailing 7 days). Each alert carries the hour, the closing price, the measured values and its commit in the CHXL attestation stream on opBNB (seq, hash, transaction), so the time the alert existed is provable. Optional chain, read, hours back (default 24, max 168), limit (default 100, max 500). checkedThrough tells you the last completed check, so an empty list is a real negative

NameTypeReqDescription
chainstring––
hoursnumber––
limitnumber––
readstring––
NameTypeReqDescription
alertsarray––
chainsarray––
checkedThroughnumber|null––
countnumber––
errorstring––
hoursnumber––
metaobject––
namespacestring––
productstring––
readsarray––
receiptobject––

No examples provided.

lexicon_bulk ~157

Requires a ChainHelix API key as bearer token, or 50 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Resolve up to 25 argument names against the ChainHelix Agentic Lexicon in one call: for each name the entry (id, meaning, representation, unit, example) or, when the name is unknown or ambiguous, the candidates. Each item is a name, or { name, namespace, venue } with the same hints as lexicon_resolve

NameTypeReqDescription
namesarrayyesup to 25 names, each a string or { name, namespace?, venue? }
NameTypeReqDescription
bundleSha256string|null––
countnumber––
errorstring––
lexiconVersionstring|null––
receiptobject––
resolvednumber––
resultsarray––

No examples provided.

lexicon_bundle ~148

19 dollars per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. A ChainHelix API key does not cover this tool. Download the whole ChainHelix Agentic Lexicon for the current version: the bundle (every entry with its meaning, representation, unit, synonyms, venue aliases and sources), the licence texts, the attribution table and the change log, with the sha256 of every file. The answer is a download link per file, valid 7 days, 50 downloads; patches of this version are included, a new version is a new purchase

Input schema present but exposes no named parameters.

NameTypeReqDescription
bundleSha256string|null––
downloadsAllowednumber––
entriesnumber––
errorstring––
expiresAtstring––
filesarray––
licencestring––
namestring––
receiptobject––
verifystring––
versionstring|null––

No examples provided.

lexicon_resolve ~199

Requires a ChainHelix API key as bearer token, or 5 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Resolve one argument name against the ChainHelix Agentic Lexicon: the entry (id, meaning, representation, unit, example) or, when the name is unknown or ambiguous, the candidates to choose from. Optional namespace (common, agent, identity, payment, wallet, onchain, defi, market, data) and venue (an exchange name, e.g. binance: a venue field name resolves through ccxt's mapping)

NameTypeReqDescription
namestringyesthe argument name to resolve, e.g. origQty, stop_price, budgetUsd
namespacestring––
venuestring–exchange name, lower case, e.g. binance
NameTypeReqDescription
bystring––
candidatesarray––
chargedboolean––
entry–––
idstring––
lexiconVersionstring|null––
okbooleanyes–
reasonstring––
receiptobject––
spellingstring––

No examples provided.

Common questions

What is the io.chainhelix/intel MCP server?

io.chainhelix/intel is an MCP server listed in the public MCP registry as io.chainhelix/intel. Nine chain onchain intelligence with a verifiable onchain signal attestation stream. This page covers its hosted endpoint (https://mcp.chainhelix.io).

Is the io.chainhelix/intel MCP server safe to use?

io.chainhelix/intel scores 74 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.chainhelix/intel MCP server expose?

io.chainhelix/intel exposes 81 tools: proof_spec, list_reveals, freshness, daily_digest, data_changelog, and 76 more. Their descriptions and schemas cost roughly 11,079 tokens of context every time the server is loaded.

Does the io.chainhelix/intel MCP server require authentication?

No. We connected to io.chainhelix/intel without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the io.chainhelix/intel MCP server still maintained?

io.chainhelix/intel is still listed as active in the MCP registry. We last reached this channel on 26 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.