DePIN network telemetry with the source, as_of time and an upstream verify URL on every value.
Scored across 21 tools
Most tools have a clearly distinct resource or action, but several adjacent retrieval tools (get_network, get_network_signals, get_stats, get_data_dictionary, list_datasets) require reading descriptions to separate. The two verification tools are also close in spirit: verify_value checks upstream numbers while verify_footprint checks Merkle inclusion. The paid analytics tools are technically distinct but not self-explanatory from their names alone.
All 21 tools use predictable snake_case with a verb_noun pattern: get_, list_, fetch_, find_, verify_, purchase_, register_, check_, topup_. There is no mixing of camelCase or vague standalone verbs. The one slight oddity, topup_credits, is still readable and consistent with the rest.
At 21 tools the surface is heavy, spanning datasets, DePIN network retrieval, paid analytics, billing, auth, and verification. The count is defensible for a broad commercial data API, but it sits in the borderline 16-25 range where each tool must justify its place. Several read-only discovery tools overlap enough that the set could likely be tightened.
The surface covers the main lifecycle: discovery (find_networks, list_datasets, get_data_dictionary, get_stats), retrieval (fetch_dataset, get_network, get_metric_history), analytics, purchasing/credits, and verification. No major CRUD gap is apparent for a read-only data API, though there is no explicit full network catalog tool and bulk/history access is routed indirectly through products or fetch_dataset. These are minor workaroundable gaps.
Check your remaining credit balance. Use after purchases to see remaining credits.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the 'after purchases' timing cue and does not mention rate limits, cost, or response shape, so it adds modest value beyond annotations.
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, purpose stated first, use case second, with no filler. Every clause earns its place for a tool this simple.
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 single-parameter read tool whose annotations cover safety and idempotency, the description plus schema is nearly sufficient; 'remaining credits' implies the return value. It lacks any note on units, currency, or failure behavior for an invalid key, which is the only real gap.
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?
There is a single parameter (api_key) with 100% schema description coverage, so the schema already documents it fully. The description adds nothing about the parameter, which matches the baseline 3 when the schema does the work.
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+resource ('Check ... credit balance') that is unambiguous and clearly distinct from siblings like topup_credits or purchase_data in intent. It does not explicitly name an alternative, so it stops short of the 5 tier.
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?
'Use after purchases to see remaining credits' gives a concrete triggering context, which is more than most definitions offer. It provides no explicit exclusions or named alternatives, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query records from a dataset with limit/offset. Free tier: 10 records per query. For depin_onchain, raw archived observations, including rejected rows, are retained. observation_quality reports limited PKT airdrop checks; not_checked means not validated. This read-time annotation is not covered by original proof hashes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records (max 10 for free tier) | |
| offset | No | Record offset | |
| dataset | Yes | Dataset name (e.g., depin_onchain) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context beyond them: the free-tier 10-record cap, that rejected rows are retained for depin_onchain, and that observation_quality read-time annotations are not covered by original proof hashes.
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 core query sentence is front-loaded, but the remainder pivots into dataset-specific caveats about observation_quality and proof hashes that only apply to one dataset, diluting focus for general callers. Some sentences earn their place; others are only conditionally relevant.
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 read-only query tool with an annotation-covered safety profile and full schema coverage, the essentials are present. However, with no output schema, gaps remain around default limit, ordering, and pagination behavior that the description could reasonably address.
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%, so the schema already documents dataset, limit, and offset, establishing the baseline of 3. The description restates limit/offset and echoes the tier cap ('10 records per query') but adds no format, default, or ordering detail 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 states a specific verb and resource: 'Query records from a dataset with limit/offset,' and the title reinforces 'Fetch raw dataset rows.' It is unambiguous what the tool does, though it does not explicitly distinguish itself from siblings like list_datasets or get_data_dictionary.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. It gives context (free tier cap, depin_onchain retention) but never tells the agent when this tool is the right choice versus list_datasets, get_data_dictionary, or purchase_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up DePIN networks (and Bittensor subnets) that have live data, by name or ticker, e.g. 'akash', 'helium', 'FIL'. Returns symbol, name, category and the network's public page. Use it to get the symbol that get_network, get_metric_history and verify_value take; a network with no public ticker is listed under its internal reference (symbol_kind 'internal_ref'). Read-only, no key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20). | |
| query | No | Name or ticker fragment, case-insensitive. Omit to list. | |
| category | No | Optional category filter, e.g. compute, storage, wireless, AI. |
| Name | Required | Description |
|---|---|---|
| matches | Yes | |
| networks | Yes | |
| returned | Yes | |
| networks_searched | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context beyond them: results are limited to networks with live data, no API key is required, and networks without public tickers appear under an internal reference.
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 three dense, front-loaded sentences with no filler. Purpose, return shape, downstream use, and the internal_ref edge case are all communicated efficiently.
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, the schema fully documents parameters, and an output schema exists, so return values need not be detailed. The description covers the key edge case (internal_ref) and the intended follow-up tools, making it complete for correct 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 100%, so the schema already documents query, category, and limit. The description reinforces query semantics with examples and explains the internal_ref symbol kind, but does not add syntax or behavior for category or limit 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 uses a specific verb and resource: looks up DePIN networks and Bittensor subnets by name or ticker. It gives concrete examples ('akash', 'helium', 'FIL') and states the returned fields, making the tool clearly distinguishable from siblings.
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?
It explicitly says to use this tool to get the symbol required by get_network, get_metric_history, and verify_value, routing the agent to the correct downstream tools. It also explains the internal_ref fallback for networks without a public ticker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ONBOARDING SPEC: freshness, history depth, coverage and endpoints per feed (depin_onchain, depin_daily, health_profiles, signal_ledger, market_ticks, zk_footprints). Machine-legible; answers 'how stale is this and how far back does it go' for every feed. Free, no key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it is machine-legible, free, and requires no API key, which affects whether and how an agent invokes it. That is real added value over the structured fields.
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 dense sentences that front-load what it returns (freshness, history depth, coverage, endpoints) and lead with 'ONBOARDING SPEC'. It is tight, though the label and feed enumeration make it slightly list-heavy.
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-param, read-only tool with full annotation coverage and no output schema, the description covers what it answers, its scope, and its cost/auth posture. The only minor gap is the exact return shape, which the description only gestures at with 'machine-legible'.
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?
There are zero parameters, so the baseline is 4 by the rubric. The description correctly implies a parameterless call with nothing to configure, and 'no key' confirms no auth parameter is needed.
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 resource (metadata about feeds) and enumerates the feeds by name, and quotes the exact question it answers ('how stale is this and how far back does it go'). It is clearly distinguishable from siblings like get_stats or get_metric_history, though the label 'data dictionary' plus the enumerated feeds does the heavy lifting.
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 scope question ('how stale is this and how far back does it go') implies when to consult it, and 'free, no key' tells the agent there is no setup cost. But there is no explicit when-to-use vs. alternative guidance (e.g., vs. get_metric_history or list_datasets), so an agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid: 2 credits ($2.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). Computes the left-hand side of Theorem 1 in Qazi (2026, arXiv:2608.12576), the enforcement capacity p * (lambdaS + deltamin Phi): the largest per-audit deterrence ratio a network's slashing and probation can support, in the network's stake unit. Inputs are the network's published protocol parameters (stake per provider, slash fraction, audit probability, probation ladder, hardware-identity binding), each returned with the URL it was read from and the date it was last confirmed there; unsourced stake or slash parameters are refused, never defaulted, and so is one not re-confirmed within 60 days. Where a network publishes no audit probability, p = 1 is used and the figure is labelled an upper bound (capacity_upper_bound_p1); a slash fraction published only as a recommended default is labelled so and its range is reported. Structural screens (deviations that cannot be detected, missing identity binding) are reported. A ceiling, not a verdict: the cheating gain it would have to exceed is private, so no incentive-compatibility answer is given. Networks without sourced parameters are answered unavailable and not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| tool | No | |
| result | Yes | |
| schema | Yes | |
| status | Yes | |
| symbol | Yes | |
| call_id | No | |
| credit_cost | Yes | |
| charge_state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses the exact billing contract (2 credits, charged only after a non-empty answer, free on refusal/error), the absence of an idempotency key ('Each call is a new answer and a new charge'), and the fallback behaviour where audit probability is missing (p = 1, labelled capacity_upper_bound_p1). It also explains how marginal inputs are surfaced (recommended-default slash fractions flagged with range, structural screens reported), which is far richer than readOnlyHint/destructiveHint/idempotentHint convey.
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?
Every sentence carries load — pricing, theorem, input sourcing, fallbacks, scope limits — with no filler. The one structural flaw is front-loading: the billing preamble comes before the statement of what the tool computes, so an agent skimming the first clause learns the price before the purpose.
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?
An output schema exists, so return values needn't be described, and the description supplies everything else a caller needs: cost, invocation auth, input sourcing rules, refusal and unavailability behaviour, labelling conventions, and the ceiling-versus-verdict caveat. For a paid, non-idempotent compute tool this is complete.
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%, so the baseline is 3; the description earns above that by explaining that inputs are 'the network's published protocol parameters… each returned with the URL it was read from and the date it was last confirmed' and by defining the refusal semantics that govern the symbol argument's viability. It does not add per-parameter syntax (e.g. case sensitivity for tickers) beyond the schema's examples.
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 precise computational object — 'the left-hand side of Theorem 1 in Qazi (2026, arXiv:2608.12576), the enforcement capacity p * (lambda*S + delta*min Phi)' — with its unit and its interpretation as 'the largest per-audit deterrence ratio a network's slashing and probation can support.' No sibling tool produces this quantity, so an agent can distinguish it without opening any schema.
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?
It states explicit when-not conditions: networks without sourced parameters 'are answered unavailable and not charged,' unsourced stake or slash inputs are 'refused, never defaulted,' and parameters not re-confirmed within 60 days are refused. It also clarifies the scope limit ('A ceiling, not a verdict… no incentive-compatibility answer is given'). What's missing is routing to alternatives — it never says to use find_networks or get_network first to confirm a ticker exists or to discover which networks have sourced parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the derivation ledger index. With a symbol: up to 20 recent archived upstream fetches behind that network, each with time, verify_url, the SHA-256 and size of the raw payload, the collector code hash and the fetch status, so a published value can be traced to the exact bytes and build that produced it (the payload bytes themselves are the paid derivation_replay product). A network with live data that the ledger does not cover yet returns entries: [] with ledger_status not_yet_covered and the covered symbols. Without a symbol: every covered symbol with its latest fetch time and entry count. Read-only, no key. To compare a live value with its upstream right now, use verify_value.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Optional: one network symbol, case-insensitive (e.g. AKT). Omit for the coverage list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so 'Read-only, no key' mostly restates them (though 'no key' does add auth context). What earns credit is genuinely new behavior: the 20-entry cap, the 'entries: [] with ledger_status not_yet_covered plus covered symbols' edge case, and the explicit paywall boundary that payload bytes are the separate paid derivation_replay product. That is material disclosure an agent could not infer from the annotations.
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?
Front-loaded with the core purpose and organized by mode (with symbol / without symbol / read-only), with no filler sentences. It is on the long side for one optional parameter, but each sentence contributes a distinct fact (fields returned, truncation limit, empty-result status, paywall boundary).
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?
There is no output schema, and the description compensates fully: it enumerates the returned fields (time, verify_url, SHA-256, size, collector code hash, fetch status), describes the coverage-list shape, and handles the not_yet_covered edge case. An agent has everything needed to call it and interpret the response.
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 100% and the single optional param already documents case-insensitivity and that omitting it returns the coverage list. The description adds the 'up to 20 recent fetches' limit, but that is return-volume behavior rather than parameter semantics. Baseline 3 is right when the schema carries the parameter documentation.
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+resource ('Returns the derivation ledger index') and then cleanly splits the tool into its two operating modes: with a symbol (up to 20 archived upstream fetches) and without (coverage list). It also names the sibling it is not — 'To compare a live value with its upstream right now, use verify_value' — so an agent can separate it from verify_value and verify_footprint 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: supply a symbol to trace one published value to bytes/build, omit it to get the coverage list. It also names verify_value as the alternative for live comparisons, which is the main confusion risk among the verify_* siblings. When-to-use and when-to-use-something-else are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| tool | No | |
| result | Yes | |
| schema | Yes | |
| status | Yes | |
| symbol | Yes | |
| call_id | No | |
| credit_cost | Yes | |
| charge_state | Yes |
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.
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.
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.
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.
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.
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.
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: each first-party on-chain supply series it has (eligible metrics whose name contains 'supply', e.g. onchain_total_supply), its daily close at the latest complete UTC day and 7 and 30 days earlier, the percentage changes, and each change annualised by compounding ((end/start)^(365/days) - 1, so a 7-day move is heavily amplified). Each series is the supply of the contract or chain at its verify_url; one below half of the network's reference supply (a bridged or partial representation, e.g. a BEP-20 wrapper) is not used, and one with no reference held, or counted in another unit than whole tokens of the network's ticker (base units, a second token), is labelled unchecked. A series with 2 or fewer distinct daily closes in 30 days is not used (a stuck feed cannot be told from a fixed supply). Every endpoint carries its as_of and verify_url; nothing is interpolated. No exchange-listing, price, funding, market-cap or aggregator data is used; the tool name is historical. Networks without an eligible supply series are answered unavailable and not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| tool | No | |
| result | Yes | |
| schema | Yes | |
| status | Yes | |
| symbol | Yes | |
| call_id | No | |
| credit_cost | Yes | |
| charge_state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far beyond the annotations: exact billing (1 credit / $1.00 per answered call, charged only after a non-empty answer, free on refusal/error/unavailable), the no-idempotency rule, and the data-quality filters that silently exclude series (below half reference supply, ≤2 distinct closes in 30 days, wrong unit → 'unchecked'). The absence of interpolation and the per-endpoint as_of/verify_url are also disclosed.
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?
It is one dense ~230-word block whose first sentence is billing rather than what the tool returns, pushing the purpose behind payment mechanics. Most sentences do carry unique information (charge conditions, exclusion rules, annualisation formula), but the wall-of-text framing makes it slow for an agent to extract the core answer.
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?
An output schema exists so return formatting need not be explained, yet the description still covers cost model, auth path, non-idempotency, series eligibility, unit-checking, and the 'no interpolation' guarantee. For a paid single-network tool with only two parameters, nothing an agent needs before calling 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% and both parameters already carry descriptions, so the schema does the heavy lifting. The description adds only indirect meaning for 'symbol' by explaining that networks lacking an eligible supply series return unavailable rather than erroring; it adds nothing new about api_key placement beyond what the schema states.
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 precisely what is returned: each first-party on-chain supply series whose metric name contains 'supply', its latest complete UTC daily close plus 7- and 30-day-ago closes, percentage changes, and annualised compounding. It also pre-empts the misleading name by stating the tool uses no listing/price/market-cap data and that 'the tool name is historical', which lets an agent separate it from siblings like get_metric_history or get_network_signals.
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?
It states the unit of use (one network ticker per call) and the outcome when no eligible supply series exists ('answered unavailable and not charged'), which is useful selection context. But it never says when to pick this over get_metric_history, get_network_signals or get_network, and gives no positive guidance on which networks or questions it suits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the daily series for one network metric (one point per UTC day, with how many observations backed it), e.g. symbol=AKT metric=GPU_ACTIVE. Days with no observation are absent, never zero. The free tier serves the last 7 days and says so in window_notice; an X-API-Key header on the connection serves your tier's window. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of history requested (default 7). | |
| metric | Yes | Metric name exactly as get_network lists it, e.g. GPU_ACTIVE. | |
| symbol | Yes | Network ticker, e.g. AKT. |
| Name | Required | Description |
|---|---|---|
| metric | Yes | |
| points | Yes | |
| symbol | Yes | |
| window_days | No | |
| window_notice | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the closing 'Read-only' is redundant. The description nonetheless adds material behavior beyond the annotations: absent days are omitted rather than zero (a critical semantics trap for an agent), and auth/tier limits are disclosed via the X-API-Key header and window_notice.
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 tight sentences, front-loaded with the return shape, followed by the absent-vs-zero caveat and then the access rules. Nothing is padded and each clause carries distinct information.
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?
With an output schema present, the description need not document return fields, and it still covers the non-obvious gaps: observation density per point, missing-day semantics, free-tier window, and API-key authentication. An agent has everything needed to call it correctly and interpret results.
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 100%, so symbol, metric and days are already documented with examples and bounds. The description only reinforces the symbol/metric pairing via its example and touches the 7-day default indirectly through tier language; it adds little parameter meaning 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?
States a specific verb and resource — 'Returns the daily series for one network metric' — and pins down grain (one point per UTC day) and an example invocation (symbol=AKT metric=GPU_ACTIVE). It is clearly separable from listing tools like get_network, though it never names a sibling explicitly to route against.
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?
Offers contextual guidance about windowing — the free tier serves 7 days and signals it via window_notice, and an X-API-Key header unlocks your tier's window — which tells the agent what to expect but not when to prefer this tool over alternatives such as get_stats or get_network. Usage is implied rather than stated with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the latest first-party measurements for one DePIN network (GPU and CPU capacity, storage, node or hotspot counts, on-chain totals), each with value, unit, as_of, freshness and the verify_url on the network's own API that you can open to check it. Market prices are not included. metric_filter narrows by substring; stale readings are omitted unless include_stale is true. Incident/stale exclusion reasons are returned separately, without values and not counted as metrics. Read-only, no key.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Network ticker, e.g. AKT, FIL, HNT (find_networks resolves names). | |
| max_metrics | No | Max metrics returned (default 40). | |
| include_stale | No | Include readings past their freshness window (default false). | |
| metric_filter | No | Optional case-insensitive substring, e.g. 'gpu' or 'storage'. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| symbol | Yes | |
| category | No | |
| page_url | No | |
| telemetry | Yes | |
| stale_omitted | No | |
| metrics_matched | No | |
| metrics_returned | Yes | |
| onchain_first_party | Yes | |
| deep_network_profile | No | |
| live_withheld_not_live | No | |
| onchain_withheld_not_live | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/no-key, yet the description still adds real behavior: what a metric record carries (value, unit, as_of, freshness, verify_url), that incident/stale exclusion reasons come back separately without values and are not counted as metrics, and that each value is independently verifiable. It omits return shape detail, though an output schema exists.
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 dense paragraph that front-loads the returned payload and then layers the filter/stale/incident semantics. No sentence is wasted, though 'Read-only, no key' largely repeats annotations and could be dropped.
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?
With an output schema present, the description needn't detail return values and doesn't. It covers the freshness model, the exclusion-reason side channel and the verify_url, giving an agent enough to call this correctly; only sibling routing for history/name-resolution is left to other tools.
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%, so baseline is 3; the description still adds semantic value by explaining that metric_filter is a substring match and that include_stale controls the freshness window rather than filtering something else. It doesn't restate max_metrics or the symbol format, which are handled in-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?
States a specific verb and resource ('returns the latest first-party measurements for one DePIN network') and enumerates the metric families covered (GPU/CPU capacity, storage, node counts, on-chain totals). It also carves out what it is not ('Market prices are not included'), which separates it from siblings like get_metric_history and check_balance.
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?
Makes the scope boundary explicit by excluding market prices and by noting stale readings are omitted unless include_stale is true, which tells the agent when to flip that flag. It doesn't name a competing sibling for historical or cross-network queries (find_networks / get_metric_history), so the alternative routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current scheduled Hodge and lag-relation snapshots, coverage, observation times, invariants and timestamped history for configured market, DePIN and world cohorts. Requires an API key on a paid tier that includes the engines capability (https://kairossignal.com/pricing), sent in the X-API-Key header of the MCP connection; the free starter key from register_agent does not include it, and a call without a qualifying key is refused with isError. Descriptive relationships only: no fitted memory kernel, causal attribution, calibrated anomaly probability or trading-performance claim. Missing or stale inputs remain explicitly unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| schema | Yes | |
| status | Yes | |
| production_mode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: discloses the X-API-Key auth mechanism, tier gating, that failures surface as isError, that missing or stale inputs are reported as unavailable rather than imputed, and explicitly bounds the semantics (descriptive only, no causal attribution or anomaly probability). That is exactly the extra context annotations cannot carry.
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?
Front-loads the return payload, then auth, then semantic caveats — a sensible ordering. It is dense and a couple of clauses (the pricing URL, the disclaimers list) run long, but every sentence carries distinct information.
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?
With an output schema already describing return structure and annotations covering safety, the remaining burden is auth, failure modes, and interpretive limits — all of which the description supplies. Nothing an agent needs to call this 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?
The tool takes no parameters, so the baseline is 4; the description correctly implies there is nothing to configure. It adds no parameter information because none is needed.
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 concrete verb ('Returns') and enumerates the exact payload: scheduled Hodge and lag-relation snapshots, coverage, observation times, invariants and timestamped history across named cohorts. This is clearly distinguishable from siblings like get_hodge_regime_sieve or get_network, which cover narrower slices.
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?
Explicitly names the prerequisite (paid-tier API key with the engines capability) and warns that the free key from register_agent will be refused, which is a genuine routing signal. It does not, however, say when to prefer this over the more targeted siblings such as get_hodge_regime_sieve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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: the correlation matrix of the daily log changes of its stored first-party metrics over the last days complete UTC days (one publisher per metric; exact combinations of other metrics, e.g. writer-derived ratios, excluded and named; effective rank and near-identical pairs reported), its eigenvalues, and the Marchenko-Pastur edges for the same number of independent series (q = N / (T-1)). Reports the largest eigenvalue over the upper edge, how many eigenvalues exceed it, the absorption ratio (variance share of the top ceil(N/5) eigenvalues) and each metric's loading on the top eigenvector. The edge is a reference for independent light-tailed series; telemetry changes are neither, so exceeding it describes co-movement and is not a test. Uses up to max_metrics (3-60, default 30) metrics, by name order. Every input daily close is returned with its as_of and verify_url. No regime label, position size or trading mode is produced.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 30). | |
| metric_filter | No | Optional case-insensitive substring of metric names, e.g. GPU. |
| Name | Required | Description |
|---|---|---|
| tool | No | |
| result | Yes | |
| schema | Yes | |
| status | Yes | |
| symbol | Yes | |
| call_id | No | |
| credit_cost | Yes | |
| charge_state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Exceptional disclosure beyond the annotations: exact price (1 credit / $1.00), the charge condition (only after a non-empty answer is computed; errors/refusals free), the explicit absence of idempotency (each call is a new charge), and the header/param auth options — all consistent with idempotentHint=false and with a paid tool where destructiveHint reflects credit spend.
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?
Dense but efficient: billing terms first, then the computation, then interpretation limits and outputs. The opening sentence is about cost rather than what the tool does, which delays purpose slightly, but for a metered tool the charge semantics are the highest-stakes fact and earn their position.
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 paid, multi-parameter analytical tool this covers pricing, auth, idempotency, inputs used, exclusions, statistical caveat, and explicitly what is NOT returned ('No regime label, position size or trading mode'). With an output schema present, return-value detail is correctly left light while provenance (as_of, verify_url) is still flagged.
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%, so the baseline is 3, but the description adds real meaning: `days` is complete UTC days, `max_metrics` operates 'by name order' with a 3-60 range, and the q = N/(T-1) definition ties the window to the spectrum. It does not explain `metric_filter`, leaving that to 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?
Names a precise computation on a specific resource: the correlation matrix of daily log changes of a network's stored first-party metrics, its eigenvalues, and the Marchenko-Pastur edges (q = N/(T-1)). That verb+resource pair is specific enough to separate it from spectral siblings like get_hodge_regime_sieve or get_network_signals.
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 by the description of the statistic and the caveat that exceeding the edge 'describes co-movement and is not a test', which tells an agent how to interpret, not when to pick this tool. No sibling alternative is named and no precondition (e.g. minimum metric availability) is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid: 1.5 credits ($1.50) 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: an exact two-factor functional ANOVA of the daily log changes of its stored first-party metrics over the last days complete UTC days (same input rules as get_rmt_regime_state), with factors day (moves shared by the network's metrics that day) and unit (metrics measured in the same unit; units held by one metric are pooled into one named group; a panel where a group would hold one metric, or that has only one unit group, is answered unavailable, uncharged). Returns each factor's variance share, their interaction and the metric-specific remainder, the mean absolute Shapley value per factor, and for the latest day each metric's change split exactly into its day and unit Shapley values plus remainder (additivity error reported). Descriptive: not causal, not a forecast. Uses up to max_metrics (3-60, default 30) metrics, by name order. Every input daily close is returned with its as_of and verify_url.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 30). | |
| metric_filter | No | Optional case-insensitive substring of metric names, e.g. GPU. |
| Name | Required | Description |
|---|---|---|
| tool | No | |
| result | Yes | |
| schema | Yes | |
| status | Yes | |
| symbol | Yes | |
| call_id | No | |
| credit_cost | Yes | |
| charge_state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry readOnlyHint=false, idempotentHint=false and a generic destructiveHint=true; the description supplies the actual behavior an agent needs — 1.5 credits per answered call, charged only on a non-empty answer, free on unavailability/refusal/error, no idempotency key, auth via X-API-Key or api_key, and a caps on metric count. It also states the results are descriptive, not causal or a forecast, and that additivity error is reported.
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?
Cost and charge semantics are correctly front-loaded, but the middle of the description is a single dense run-on sentence with parenthetical nesting about unit pooling and unavailable panels that is hard to parse. The content mostly earns its place, but it is not structured for scanning.
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 paid, non-idempotent analytical call this covers everything an agent needs: price and charging trigger, auth paths, refusal/unavailable semantics, metric-count limits, and the shape of what is decomposed. An output schema exists, and the description still briefly names the returned quantities and additivity error, so nothing material 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%, so days, symbol, max_metrics, api_key and metric_filter are all documented in the schema itself, which sets the baseline at 3. The description adds only marginal meaning beyond that (metric selection is 'by name order', max_metrics 3-60 default 30) and never mentions metric_filter, the one parameter most likely to need extra explanation.
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 precise verb and resource: an exact two-factor functional ANOVA / Shapley decomposition of daily log changes for one DePIN network, with named factors (day, unit) and named outputs. It also explicitly anchors itself to a sibling ('same input rules as get_rmt_regime_state'), so an agent can separate it from get_rmt_regime_state and get_metric_history.
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?
It gives clear context: one network at a time, input rules inherited from get_rmt_regime_state, and when-not conditions (a unit group holding a single metric, or only one unit group, yields an unavailable answer). It does not spell out the alternative to pick when you want raw metric history versus this attribution, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the row count of every dataset served here (depin_onchain, market_ticks and the rest), their total, the scope statement and the free-tier limits. No arguments, no key, read-only. For one network's live values use get_network; for freshness and history depth per feed use get_data_dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new context beyond them: 'No arguments, no key' tells the agent no authentication or parameters are needed. It stops short of stating cost or rate-limit behavior, which would round out a 5.
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, return contents front-loaded, routing second, and no filler. The 'read-only' clause is mildly redundant against the annotations, but everything else 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 no-arg, no-auth, read-only stats tool with no output schema, the description covers what it returns, what is excluded, and which siblings handle related queries. Only the absence of cost/credit implications and return-shape hints keeps it from a 5.
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?
There are zero parameters, so the baseline is 4. The description's 'No arguments' declaration is consistent with the empty schema and usefully confirms no input is required; no further parameter meaning is possible.
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 (returns row counts of every dataset) and enumerates the payload: per-dataset counts, total, scope statement, and free-tier limits. It also names the sibling tools it is not (get_network, get_data_dictionary), so an agent can discriminate 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing is given for both alternatives: use get_network for one network's live values and get_data_dictionary for freshness/history depth per feed. This is unambiguous when-to-use and when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the current dataset catalog with record counts. Browsing is free; existing query and daily-call limits apply.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds genuinely non-structured information: this operation is free of charge while queries are subject to existing query and daily-call limits. It does not mention pagination or list size limits.
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, zero filler, with the what-you-get ('catalog with record counts') front-loaded before the cost caveat. Nothing to trim.
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-param, no-output-schema list tool the description covers what is returned and the cost model, which is most of what an agent needs. It omits whether the catalog is paginated or how large it can be, a minor gap.
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 takes zero parameters and the schema is an empty object, so there is nothing to disambiguate. Baseline 4 applies; no parameter meaning is needed or missing.
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 ('List the current dataset catalog') and adds scope detail ('with record counts'), which distinguishes it from the singular fetch_dataset sibling. It does not explicitly name which sibling to use instead, but the plural-list scope is unambiguous.
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 cost framing ('Browsing is free; existing query and daily-call limits apply') implies this is the cheap discovery step worth doing before fetching or purchasing, but it never states that directly nor names an alternative tool. Usage is implied rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse purchasable products with prices in credits ($1 = 1 credit). DePIN supply-telemetry, provenance, derivation-replay, history and the intel bundle start at $0.49. Grade purchases are conditional on measured-grade availability; check /v1/credits/pricing before buying. 30-day Pro access to the DAG manifold API is sold as dag_manifold_30d and delivers its API key inline. Not purchasable, refused by purchase_data with 503 not_yet_deliverable and nothing charged: the signal-feed tiers (retired, not sold), dag_pro (buy dag_manifold_30d instead), and dag_quant, dag_enterprise and mcp_unlimited (listed, not on sale yet). The five paid analytics tools are not products here: each charges credits per answered call, stated in its own description. Call after register_agent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/ idempotent/ non-destructive, and the description adds substantial context beyond them: which tiers are refused by purchase_data with a 503 not_yet_deliverable and nothing charged, that dag_manifold_30d delivers its API key inline, and that grade purchases are conditional on measured-grade availability. This is exactly the extra behavioral context a listing tool needs.
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 purpose and price basis are front-loaded in the first clause, then caveats follow. It is dense and enumerates many tier names, which makes it sprawl slightly, but each clause carries decision-relevant information (what is purchasable, what is refused, what to buy instead) rather than filler.
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?
No output schema exists, so the description carries return-value burden; it conveys the concept of products-with-prices and refusal states well, though it does not describe the shape of the returned list (fields, ordering). For a zero-param listing tool this is close to complete.
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 takes zero parameters, so there is nothing for the description to document; the baseline for a no-param tool is 4. Schema coverage is moot here since the object is empty.
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 opening sentence states a specific verb (browse) and resource (purchasable products) with pricing units ($1 = 1 credit). It further disambiguates against siblings by stating the five paid analytics tools are not products here and that several listed tiers are not purchasable. An agent can distinguish this from purchase_data or get_data_dictionary without opening any schema.
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?
Explicit sequencing: 'Call after register_agent' tells the agent the prerequisite order. It also states alternatives ('buy dag_manifold_30d instead' of dag_pro) and directs to check /v1/credits/pricing before buying. When-to-use and exclusion conditions are both present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy a product with your credits; most products ship their data inline in the response. Deliverability is product-specific, including grade availability; check /v1/credits/pricing before buying — call list_products for the live prices rather than trusting a figure restated here, which is how a price in a second place drifts from the first. The signal_* keys (retired, not sold), dag_pro (sold as dag_manifold_30d), dag_quant, dag_enterprise and mcp_unlimited (not on sale yet) return 503 not_yet_deliverable and charge nothing; they are deliberately blocked, not broken. Most products deliver data inline; dag_manifold_30d delivers a 30-day DAG manifold API key inline; a delivery larger than 4 MB (today depin_history and lead_lag_correlations, each tens of MB, and derivation_replay whenever its 100 raw upstream bodies pass 4 MB, as an unfiltered pull does today) returns the receipt and a no-charge URL that serves the stored payload. Every purchase carries an idempotency_key (yours, or one generated and returned to you): if a call errors, the answer says whether you may have been charged, and repeating it with the same idempotency_key returns the receipt and data without a second charge. Use api_key from register_agent.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | Your API key from register_agent | |
| product_key | Yes | Product key to purchase (e.g. depin_provenance, depin_networks; list_products has every key and price) | |
| idempotency_key | No | Optional. Any stable string unique to THIS intended purchase (e.g. a uuid); when absent the server generates one and returns it on any error it can still answer. Send your own: if your connection is cut before any answer arrives (a client or proxy timeout; the public endpoint gives up on a request that has not answered within about 60 s), only a key you chose lets you replay. If a network error makes you retry the same call, re-send the SAME idempotency_key: the retry returns the same receipt and re-delivers the data without a second charge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already flagging destructive=true and idempotent=false, the description adds substantial charge and delivery semantics: blocked products return 503 and charge nothing, oversized deliveries return a no-charge URL, and idempotency_key replay avoids a second charge. It also explains error behavior around possible charges. This is rich behavioral context beyond the annotations.
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 purpose and pricing warning are front-loaded, and the dense detail is largely relevant to a purchase tool with charge and delivery edge cases. However, some idempotency detail repeats the schema and the aside about prices drifting in a second place could be trimmed.
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?
No output schema exists, so the description must carry delivery and error expectations; it does so thoroughly, covering inline delivery, API keys, oversized payload URLs, blocked products, idempotency replay, and charge uncertainty on errors. An agent has enough information to call this safely.
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 100%, so all three parameters are already documented, including detailed idempotency_key behavior. The description reinforces product_key examples and pricing checks but largely repeats schema-level parameter meaning rather than adding new per-parameter semantics. Baseline 3 is appropriate.
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 first sentence states a specific verb and resource: 'Buy a product with your credits', and immediately clarifies that most products deliver data inline. It also distinguishes this from list_products for pricing and names blocked product families, so an agent can identify the tool's role without opening the schema.
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 pre-purchase guidance: check pricing via list_products, and note that signal_* keys are retired and return 503 without charge. It also tells the caller to use api_key from register_agent. It does not explicitly compare against fetch_dataset or say how to retrieve previously purchased data, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an API key for this agent and grants the free starter credits ($5 free credits, no card (first 3 keys per IP per 30 days)). Past the per-IP limit a key is still created, with $0, and the response says so. A key is needed for purchase_data, check_balance, topup_credits and every tool that charges credits; get_network_signals needs one on a paid tier with the engines capability, which the free starter key does not have. Every other read-only tool works without one. email is optional and used for delivery and top-up notices.
| Name | Required | Description | Default |
|---|---|---|---|
| No | OPTIONAL contact email (for delivery and topup notifications). Omit to register anonymously. | ||
| agent_name | Yes | Your agent name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (readOnly=false, idempotent=false, destructive=false); the description supplies the real behavioral facts: a per-IP quota of 3 keys per 30 days, and a soft-failure mode where a key is still issued at $0 past the limit with the response disclosing it. That is quota policy and failure semantics an agent cannot get from annotations or schema.
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 creation action and credit grant are front-loaded, followed by the routing rules that matter most. The final email sentence is largely redundant with the schema and could be cut, but nothing else is padding.
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 creation tool with no output schema, it covers quota, failure behavior, and downstream tool requirements thoroughly. It stops short of saying that the issued key itself is returned in the response, which is the one fact an agent still has to infer.
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%, so both parameters are already documented. The description restates the email semantics (optional, used for delivery and top-up notices) almost verbatim from the schema and adds nothing about agent_name, so it earns only the baseline.
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 ("Creates an API key for this agent") plus the immediate consequence (grants free starter credits). It is unmistakably distinct from every sibling, none of which create credentials.
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?
Explicitly enumerates which tools require the key (purchase_data, check_balance, topup_credits, anything that charges credits), the special case for get_network_signals (paid tier + engines capability), and the negative case (every other read-only tool works without one). This is exactly the when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add credits. Card (one call): {"method": "stripe", "amount": N} where N is $20 or $99 — returns a Stripe checkout_url already bound to your api_key, and credits post automatically once Stripe confirms payment at $1 = 1 credit. No human step and no wallet needed. USDC on Base, two modes. micro_decimal, no wallet signature: {"method": "usdc", "mode": "micro_decimal", "amount": N} with N whole USDC from 1 to 999,999 returns a unique amount with a 6-decimal suffix and an expires_at; a finalized Base transfer of EXACTLY that amount, from any sender including an exchange, before expires_at credits your account (1 USDC = 1 credit); a different amount does not credit your account. verified_wallet (the default when mode is omitted): verify your sender first via POST /v1/credits/crypto/challenge and /verify with X-API-Key, sign the returned challenge with your own EOA, then pass the verified from_address; only a transfer FROM that wallet is credited. In every USDC mode send only after a successful quote; credit requires finalized Base evidence. Instructions: https://kairossignal.com/docs/crypto.html
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | USDC only. micro_decimal: no wallet signature; the quote is a unique amount to send exactly, from any sender. verified_wallet (default when omitted): requires from_address verified through the wallet challenge flow. Ignored for stripe. | |
| amount | Yes | stripe: Amount in USD to add. Fixed packs only: 20 or 99. Any other value returns the available packs instead of a link. USDC micro_decimal: whole USDC, 1 to 999999. USDC verified_wallet: the USDC amount to quote (GET /v1/credits/crypto states the accepted range). | |
| method | Yes | Payment method | |
| api_key | Yes | Your API key | |
| tx_hash | No | Legacy optional field; a transaction hash does not replace from_address or verify payment. | |
| from_address | No | Required for USDC verified_wallet mode (the default): your EOA address already verified to this API account through the wallet challenge flow. Not used by micro_decimal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides rich behavioral detail beyond annotations: it explains that the stripe checkout_url is bound to the api_key and credits post automatically, that micro_decimal returns a unique amount with an expiry and requires exact matching, and that verified_wallet requires prior wallet verification. These details substantially augment the annotations.
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 front-loaded with 'Add credits' and then logically organized by payment method. It is somewhat lengthy due to the complexity, but every sentence contributes necessary information. Slight redundancy with schema descriptions prevents a 5.
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 (two distinct payment flows with multiple modes), the description covers all essential aspects: how to initiate each flow, what to expect in return, and the conditions for credit posting. The included documentation link further ensures completeness.
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 100%, so all parameters are documented in the schema. The description adds value by explaining concrete edge cases (e.g., a different amount does not credit your account) and providing example payloads, going beyond the schema's parameter definitions.
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 'Add credits' and clearly details the two payment methods (card and USDC). It distinguishes the two paths internally but does not explicitly compare to sibling tools like purchase_data, 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?
The description explains how to call each method and mode but does not state when to use this tool versus alternatives or when to prefer stripe over USDC. Usage is implied by the payment method descriptions, leaving gaps in strategic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retained Merkle-membership check for one depin_onchain observation: stamp_day (YYYYMMDD), leaf_index (0-based row in /attestations/batch_.tsv), expected_row_sha256. verified=true ONLY when the row at that index hashes to expected_row_sha256 AND its inclusion path reaches that day's manifest merkle_root. Says nothing about Bitcoin status or upstream accuracy. Returns JSON: row_sha256, merkle_root, row_hash_matches, inclusion_path_reaches_root, verified, proof_url. Use it when you hold a row from a daily batch and want to show it was committed that day; a call with arguments missing lists the days with a proof ready and a working example. Read-only, no key. Other datasets: unsupported (no retained proof).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | No | Only depin_onchain has retained proofs (the default). | depin_onchain |
| stamp_day | Yes | Batch day as YYYYMMDD (UTC); separators are ignored. | |
| leaf_index | Yes | 0-based line number of the row in /attestations/batch_<stamp_day>.tsv. | |
| expected_row_sha256 | Yes | Lowercase hex SHA-256 of that row's exact bytes (no trailing newline). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds real context beyond them: the exact truth condition for verified=true, an explicit statement of what it does NOT assert (Bitcoin status, upstream accuracy), the no-key requirement, and the missing-argument fallback. This is unusually rich behavioral disclosure.
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?
Front-loaded with the core purpose and truth condition, and every sentence carries content (scope limit, return fields, usage, fallback). It is dense with parentheticals and could be tightened, but nothing is clearly wasted.
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?
With no output schema, the description compensates by enumerating the returned JSON fields (row_sha256, merkle_root, row_hash_matches, inclusion_path_reaches_root, verified, proof_url). Combined with scope limits and usage, an agent has everything needed to call and interpret it.
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%, so the baseline is 3, but the description adds semantic meaning beyond the schema by tying expected_row_sha256 and leaf_index to the verified=true condition and the manifest merkle_root. It reinforces rather than merely repeats the field formats.
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+resource (retained Merkle-membership check for one depin_onchain observation) and scopes it tightly to a single dataset and row, distinguishing it from the sibling verify_value by naming the exact proof type and data domain. An agent can tell what it does without opening the schema.
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?
Gives an explicit when ('when you hold a row from a daily batch and want to show it was committed that day'), a when-not ('Other datasets: unsupported'), and even describes missing-argument behavior (lists days with a proof ready plus an example). It does not name a sibling alternative to redirect to, so it stops short of the top bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-reads the upstream API behind one of our values right now and reports where the same number appears in the upstream response (JSONPath), the relative difference, and a verdict: exact, within_1pct, within_10pct, no_matching_field, not_checkable_by_get, or withheld_not_live (no upstream fetch; ours is empty). Use it to check a figure before relying on it. Makes one GET to a third-party API; read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | Metric name from get_network, e.g. ACTIVE_MINERS. | |
| symbol | Yes | Network ticker, e.g. FIL. |
| Name | Required | Description |
|---|---|---|
| ours | Yes | |
| match | No | |
| metric | Yes | |
| symbol | Yes | |
| verdict | Yes | |
| upstream | No | |
| explanation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/open-world safety, but the description adds real operational context: exactly one GET to a third-party API (latency/cost implication), and the important exception that withheld_not_live performs no upstream fetch at all. It also explains why results are non-idempotent (a live re-read at call time). It does not mention auth, rate limits, or failure modes on the upstream call, keeping it below a 5.
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?
Front-loaded with the action and resource, then the reported fields, then the verdict vocabulary. The long enum list is dense but earns its place because the verdict values carry decision-relevant meaning. Slightly overpacked for a single paragraph.
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?
An output schema exists, yet the description still explains the verdict semantics an agent needs to interpret results, plus the no-fetch edge case. With 2 well-documented params and full annotation coverage, nothing essential is missing for correct 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 coverage is 100% and both parameters are documented with examples and a cross-reference to get_network, so the description has little left to add. "One of our values" plus the symbol/metric pairing in the schema is sufficient; no extra syntax or constraint detail appears in the description itself.
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: re-reads the upstream API behind a stored value and reports the matching JSONPath, relative difference, and a verdict. The enumerated verdicts (exact, within_1pct, no_matching_field, withheld_not_live, etc.) make the output shape concrete and distinguish it from siblings like verify_footprint or get_metric_history.
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?
"Use it to check a figure before relying on it" gives a clear triggering context, and the withholding/not-checkable verdicts implicitly scope when the tool can and cannot help. It stops short of naming alternatives (e.g., when to use get_metric_history instead), so no explicit exclusion or sibling routing.
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.
get_network2 fields changedOutput schema / properties / live_withheld_not_liveAdded value: +{
+ "type": "object"
+}Output schema / properties / onchain_withheld_not_liveAdded value: +{
+ "type": "object"
+}Provenance-first DePIN telemetry: 331 live networks + 129 Bittensor subnets, 10,508 series.
Signed internet telemetry, read-only: DNS, TLS, WHOIS, reachability. Every record Ed25519-signed.
Read-only electricity, gas, and weather data with structured provenance and units.
Verified behind-the-meter data center power, announcements, and provenance receipts.
Add one secure layer between your agents and this server.
