kairos-signal

Hodge lead-lag decomposition of one network's metrics (paid)

get_hodge_regime_sieve

Destructive

Paid: 1 credit ($1.00) per answered call, charged once and only after a non-empty answer is computed; an unavailable answer, a refusal or an error costs nothing. Send your API key in the X-API-Key header or as api_key. Each call is a new answer and a new charge (no idempotency key). For one DePIN network: daily closes of its stored first-party metrics over the last days complete UTC days (one publisher per metric; a metric that is an exact combination of others, e.g. a writer-derived ratio, is excluded and named; the panel's effective rank and near-identical pairs are reported), each metric's daily log change, and the lag-1 lead-lag flow between every pair (correlation of one metric today with the other yesterday, minus the reverse). A Helmholtz-Hodge decomposition on the complete graph splits the flow into a gradient part (one consistent ordering, reported as a lead score per metric) and a curl part (cyclic lead-lag); the harmonic part is zero on a complete graph and is shown as a check. Descriptive, no significance test; the flow size expected under independence is given for scale. Uses up to max_metrics (3-16, default 10) metrics, by name order. Every input daily close is returned with its as_of and verify_url. The tool name is historical: no regime classification or trading signal is produced.

Input Schema

Name	Required	Description
`days`	No	Daily changes in the window (default 30), ending at the latest complete UTC day.
`symbol`	Yes	One network ticker, e.g. AKT, FIL, RENDER.
`api_key`	No	Your API key, only if your client cannot send the X-API-Key header.
`max_metrics`	No	Metrics used (default 10).
`metric_filter`	No	Optional case-insensitive substring of metric names, e.g. GPU.

Output Schema

Name	Required	Description	Default
`tool`	No
`result`	Yes
`schema`	Yes
`status`	Yes
`symbol`	Yes
`call_id`	No
`credit_cost`	Yes
`charge_state`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026
RemovedOct 23, 2026
AddedOct 22, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true and idempotentHint=false, and the description explains exactly why: 1 credit per answered call, charged only after a non-empty answer, free on refusal/error, and explicitly no idempotency key so retries re-charge. Auth mechanics (X-API-Key header or api_key param) are also given, which annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that chains billing, auth, panel construction, flow math, decomposition, and output guarantees together. The billing caveat is correctly front-loaded, but the middle math segment could be trimmed or split without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid, non-idempotent analytical tool with an output schema, everything an agent needs is present: charge conditions, auth options, window semantics, metric selection and exclusion rules, and the harmonic-part check. Return-value detail is rightly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining max_metrics is applied 'by name order', that excluded metrics are exact combinations (e.g. writer-derived ratios) and are named in the panel, and that rank plus near-identical pairs are reported. Minor wording drift on `days` ('daily closes' vs schema's 'daily changes') is the only blemish.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (decomposition) and resource (one network's lead-lag flow across its stored metrics), and explicitly disambiguates the misleading tool name: 'no regime classification or trading signal is produced.' An agent can separate this from get_rmt_regime_state or get_network_signals without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through negatives ('Descriptive, no significance test', 'no regime classification or trading signal') rather than explicit routing. It never names the sibling to use when you actually want a regime state or a significance-tested signal, which is the main alternative an agent would weigh.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All kairos-signal tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.