DePIN supply telemetry and network data with source, as_of, and verification links. Discover datasets, inspect provenance, and retrieve data through Streamable HTTP. Data access requires an API key.
Scored across 11 tools
Most tools target clearly different actions: account/credit tools, product/dataset browsing, data fetching, and verification. The main ambiguity is get_stats, whose generic 'aggregate statistics' description could be confused with fetch_dataset or list_datasets, but the other nine tools are well separated.
All tool names follow a consistent imperative verb_noun pattern in snake_case, e.g. fetch_dataset, list_products, purchase_data, verify_footprint. There are no mixed conventions or vague standalone verbs.
11 tools is well within the ideal 3-15 range for a data-marketplace/provenance server. Each tool maps to a needed step in the register, fund, discover, purchase, fetch, and verify workflow.
The core lifecycle is covered: registration, credit top-up, product listing, purchasing, dataset discovery, fetching, and provenance/verification. Minor gaps such as the absence of order history or explicit dataset filtering beyond limit/offset are workarounds rather than blockers.
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?
No annotations are provided, so the description carries the behavioral burden. It implies a read-only operation by saying 'Check' but does not state whether the operation is side-effect-free, what it returns, or whether there are rate limits. For a simple balance check, this is acceptable but not fully transparent.
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 terse and front-loaded with the core action. The second sentence adds practical usage guidance but repeats 'remaining,' making it slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description provides a complete enough picture: what it checks, when to use it, and the required authentication context. Minor omissions are the exact return shape and a clearer read-only guarantee.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter (api_key with 'Your API key') at 100% coverage. The description adds no additional parameter detail, meeting the baseline of 3.
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 clearly identifies the verb ('Check') and the resource ('remaining credit balance'), making the tool's function unambiguous and distinct from sibling tools like topup_credits or purchase_data.
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 explicit context for when to use the tool ('Use after purchases'), which helps route an agent correctly. It does not explicitly list when not to use it or alternatives, but the API list makes the distinction reasonably clear.
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?
With no annotations provided, the description carries the full burden, and it does a solid job: it discloses the free-tier record cap, retention of rejected rows for depin_onchain, the limited validity of observation_quality, the meaning of not_checked, and the proof-hash coverage limitation. These are meaningful behavioral traits beyond the 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 first sentence immediately states the action and parameters, followed by terse, relevant caveats. The domain-specific details about depin_onchain and observation_quality are dense but necessary behavioral context, and no sentence is 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?
Given that there is no output schema and no annotations, the description provides the critical context an agent needs: pagination parameters, free-tier limits, and important data-quality caveats. It does not cover ordering or error behavior, but for a read-only query tool the provided context is strong.
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 schema already describes all three parameters, including the free-tier max of 10 for limit. The description adds no new parameter-specific meaning beyond restating limit/offset behavior, so it stays at the baseline for high schema coverage.
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 begins with a specific verb and resource: 'Query records from a dataset with limit/offset.' This clearly states the operation and distinguishes it from siblings like list_datasets, which are about enumerating available datasets rather than retrieving records.
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 makes the core use case clear by stating it queries records from a dataset, but it does not explicitly say when to avoid this tool or point to an alternative such as list_datasets. The usage is implied rather than directly compared against siblings.
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?
No annotations are provided, so the description carries the full burden. It communicates that this is an informational, machine-legible resource, that it is free and requires no key, and that it answers specific metadata questions. For a zero-parameter read-only tool this is solid behavioral disclosure, though it doesn't explicitly state 'no side effects' or describe the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the 'ONBOARDING SPEC' label, then the content scope, then the access constraint. Every sentence earns its place; there is no filler or redundancy.
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-parameter informational tool, the description is nearly complete: it names all covered feeds, the dimensions of metadata, the access requirement, and the machine-legible nature. It could be slightly richer by specifying the output format, but it provides enough for an agent to invoke and interpret the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema carries no burden and the baseline is 4. The description still adds meaning by specifying what the dictionary contains (freshness, history depth, coverage, endpoints, feed names), which helps an agent understand the returned content even without an output 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 very specific purpose: it is an onboarding spec exposing freshness, history depth, coverage, and endpoints per named feed. It lists the exact data feeds covered and explicitly answers the 'how stale / how far back' questions, making it clearly distinct from sibling tools like fetch_dataset or list_datasets.
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 phrase 'ONBOARDING SPEC' and the question 'how stale is this and how far back does it go' give strong contextual guidance for when to call it. It does not explicitly name alternatives or state when not to use it, but the intended use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DERIVATION TRUTH: raw upstream payloads, SHA-256-pinned, with the exact collector code hash for each fetch. Replay any published value: fetch the verify_url yourself, run the pinned code, compare. Answers 'a hash proves a footprint, not the derivation' — divergence from origin is mechanically detectable. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Optional: filter to one symbol (e.g. AKT). Omit for the coverage list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It mentions that values are 'free' and that the tool enables replay verification via provide verify_url and code hash, and states that divergence is mechanically detectable. However, it does not clarify the output format, whether any mutation is involved, or potential limitations. The cryptic language obscures operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single unbroken sentence-like block that leads with a slogan and then meanders through verification concepts. It is neither concise nor front-loaded with the core action. The phrase 'DERIVATION TRUTH' is attention-grabbing but not informative, and the overall structure wastes space on rhetorical framing rather than clear functional statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description must define what the tool returns, but it never explains the ledger's structure—whether it is a list of records with fields like payload, SHA, code hash, verify_url, etc. It mentions 'coverage list' but does not define it. For an agent to know what to expect from a call, this is incomplete.
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 schema provides complete coverage for the single 'symbol' parameter, describing it as an optional filter and referencing the coverage list. The description adds no extra parameter context. Since schema coverage is 100%, the baseline of 3 applies; the description does not enhance or detract from parameter understanding.
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 never explicitly states that the tool returns the derivation ledger. It opens with the slogan 'DERIVATION TRUTH' and discusses SHA-256 pinning and replay verification, but the direct action ('get the ledger') is only implied by the tool name. It does add meaning (raw upstream payloads, hashes, code hashes) so it's not a tautology, but an agent must infer the primary function from context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like verify_footprint or get_zk_provenance. The description does not mention alternatives or exclusions. The only practical note is 'Free', which addresses cost, not usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate statistics from the databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral expectations itself. The verb 'Get' implies read-only intent, but the description does not mention whether the operation is safe, cached, expensive, authenticated, or if it returns a single summary or a structured object.
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 short and front-loaded, which is good for a trivial tool. However, it is under-specified rather than truly informative, so it is concise only in the sense of being short.
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?
Even though the tool has no parameters, it has no output schema and no annotations, and the description does not clarify what the output looks like, what 'databases' means, or when this tool should be preferred over sibling tools. An agent is left guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already fully describes the invocation contract. There is no meaningful parameter detail for the description to add.
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 identifies an operation ('get aggregate statistics') and a target ('databases'), but it is vague about what statistics are returned, from which databases, and in what scope. It does not distinguish the tool from siblings such as fetch_dataset or list_datasets.
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 guidance on when to use this tool vs. the sibling tools, no exclusions, and no workflow context. An agent cannot tell whether this is the right tool for a user asking for a specific statistic or an overall dashboard summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available datasets with record counts. Free to browse — market ticks, DePIN network stats, technical indicators, US county atlas, ZK footprints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It clearly conveys a read-only, non-destructive operation through 'List' and 'Free to browse.' It does not discuss rate limits or authentication, but for a zero-parameter catalog listing, it adequately signals the behavioral outcome.
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 the core action and output ('List all available datasets with record counts'), then adds a concise, useful list of dataset categories. Every clause earns its place—there is no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only discovery tool with no output schema, the description covers the essential contract: list datasets, show record counts, and browse for free. It doesn't specify output formatting or explicitly route to siblings, but this is complete enough for a simple catalog listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the description has no parameter details to add. The baseline for 0-param tools is 4. The phrase 'List all available datasets' confirms there are no filters or inputs needed, which aligns with the empty input 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: 'List all available datasets with record counts.' This clearly distinguishes it from siblings like list_products (different resource), fetch_dataset (fetches a single dataset), and purchase_data (transactional). The added dataset-category examples reinforce the scope of the resource.
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 statement of when to use this tool versus alternatives. 'Free to browse' hints that this is a discovery/browsing endpoint before purchasing, but it does not say 'use fetch_dataset to get actual data' or 'use purchase_data to buy access.' Usage guidance is implied but not explicit.
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, grades and the intel bundle are BUYABLE NOW from $0.49. Signal-feed tiers, DAG-manifold tiers and mcp_unlimited are priced but NOT yet purchasable: their entitlement is not wired into the serving API, so purchase_data refuses them with 503 not_yet_deliverable rather than charging you for nothing. Call after register_agent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the credit conversion rate, which tiers are purchasable now versus merely priced, and — unusually valuable — that purchase_data will fail with '503 not_yet_deliverable' on the unwired tiers, preventing a wasted call. It stops short of describing pagination or the shape of the returned list.
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 purpose and pricing, then the buyable/not-buyable distinction, then the precondition. Sentences are dense with product jargon (DePIN, DAG-manifold, mcp_unlimited) but each carries distinct information and none is 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?
There is no output schema, so the description should ideally describe what a product listing contains; it covers pricing and entitlement status but not the fields returned per product. Given the zero-parameter surface and the strong behavioral coverage, it is close to complete for an agent's needs.
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 still adds meaning by explaining what the listed items are priced in and which entitlement states appear in the catalog.
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 ('Browse purchasable products') and immediately qualifies it with pricing ('$1 = 1 credit'), so the agent knows this is the catalog/price-listing tool rather than the acquisition tool. It never names a sibling to contrast with, but the wording is specific enough to separate it from list_datasets and purchase_data on its own.
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 ordering prerequisite ('Call after register_agent') and draws a clear buyable/not-buyable line, routing the agent to purchase_data for the actual transaction. It does not state when a different listing tool would be preferable, which keeps it short of a 5.
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; the data ships inline in the response. Deliverable today: the whole depin_* family plus depin_intel_bundle — 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_*, dag_* and mcp_unlimited keys are priced but return 503 not_yet_deliverable — they are deliberately blocked, not broken, because nothing grants their entitlement yet. Credits buy DATA; they do not change your access tier. 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. dag_pro, mcp_unlimited) | |
| idempotency_key | No | Optional. Any stable string unique to THIS intended purchase (e.g. a uuid). 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 no annotations, the description carries the full burden. It discloses that data ships inline, that certain products are deliberately blocked (503 not_yet_deliverable), and that credits do not change access tier. It also implies purchase requires valid api_key. However, it doesn't mention error handling for insufficient credits or the nature of the receipt beyond what's in schema (idempotency). Still, it covers the most critical behaviors.
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 informative but slightly verbose, mixing multiple clauses in one long paragraph. It is front-loaded with the purpose sentence, which is good, but the rest could be tightened. For example, the 503 explanation and the pricing advice could be separated into bullet points. It's not excessively long, but it lacks crisp structure.
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 moderately complex (purchase, idempotency, blocked products) and has no output schema. The description covers the main deliverable (inline data), the blocked products, the pricing caution, and the auth requirement. It doesn't detail the exact receipt format or failure modes, but the description gives enough for an agent to call it correctly and interpret the 503 case. It is reasonably 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 baseline is 3. The description adds meaningful context: product_key refers to product families (depin_*, signal_*, etc.) and that some are blocked, plus advises checking list_products for accurate pricing. api_key is tied to register_agent. Idempotency_key is well described in schema, and the description reinforces its purpose implicitly through the block note. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific action: 'Buy a product with your credits; the data ships inline in the response.' It identifies the resource (product) and the result (inline data), and distinguishes this purchase tool from siblings like list_products (pricing), register_agent (auth), and topup_credits (adding credits). It also specifies which product families are currently deliverable, removing ambiguity.
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 explicit guidance: use list_products for live prices rather than a stale figure, and use api_key from register_agent. It also clarifies that blocked products (signal_*, dag_*, mcp_unlimited) return 503 by design, so an agent knows not to treat them as broken or to attempt them. It doesn't explicitly contrast with topup_credits, but the overall context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE. One call: get an API key instantly (no card, no human, no Stripe, ~5 seconds) plus $5 free credits, no card (first 3 keys per IP per 30 days). Past that per-IP limit a key is still created, at $0, and the response says so — it is never a silent zero. Works immediately: query live DePIN telemetry (504 symbols, every value carries a verify_url you can check yourself), GPU inference, DAG manifold. Try get_data_dictionary first if you want the coverage spec, or GET https://kairossignal.com/try with zero setup. Nothing to cancel; credits just sit there until you spend them. Then list_products to see what $0.49+ buys.
| 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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: no card/human/Stripe required, ~5 seconds, $5 free credits, first 3 keys per IP per 30 days, past-limit keys are still created at $0 and the response says so (never a silent zero), and credits don't auto-expire. It doesn't mention whether the call is idempotent or what happens on duplicate agent_name, but the disclosed traits are substantial.
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 dense and front-loaded with the most important information ('START HERE. One call: get an API key instantly'). Every sentence adds value, though it is somewhat long and packs in marketing-style details (e.g., 'no card, no human, no Stripe') that could be trimmed. The structure is effective for an entry-point tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description is quite complete: it covers what the tool does, the free-credit terms, the per-IP limit behavior, and what to do next. It doesn't describe the exact response shape, but the description explicitly says the response indicates when the per-IP limit is exceeded, which partially compensates. The main gap is not describing the API key format or how to use it with other tools, but the sibling list and follow-up hints mitigate that.
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 both parameters. The description adds meaning by explaining that email is optional and that omitting it registers anonymously, which directly clarifies the email parameter's semantics beyond the schema's 'OPTIONAL contact email' note. It doesn't add detail on agent_name, but the schema covers it.
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 'START HERE' and states a specific verb+resource: get an API key instantly with $5 free credits. It clearly distinguishes this from siblings by naming list_products and get_data_dictionary as follow-up alternatives, and the 'START HERE' marker positions it as the entry point among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('START HERE', first call) and names alternatives: 'Try get_data_dictionary first if you want the coverage spec' and 'Then list_products to see what $0.49+ buys.' It also explains the per-IP limit behavior and that a key is still created past the limit, so an agent knows what to expect in edge cases.
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 ({"method": "usdc"}) is also accepted but requires more work: 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 and send only after a successful quote — credit requires finalized Base evidence. Instructions: https://kairossignal.com/docs/crypto.html
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount in USD to add. Fixed packs only: 20 or 99. Any other value returns the available packs instead of a link. | |
| 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: your EOA address already verified to this API account through the wallet challenge flow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that Stripe credits post automatically upon payment confirmation, that USDC requires a verification and signing flow, that credit depends on finalized Base evidence, and that an invalid amount returns available packs instead of a link. It also flags the legacy tx_hash field as not replacing from_address. These are meaningful behavioral disclosures.
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 information-dense yet concise. Every sentence adds necessary detail: the core action, the Stripe one-call format, the automatic credit posting, the USDC multi-step flow, and a documentation link. It front-loads the primary method and keeps the structure logical, with no 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?
Given the complexity of two payment methods and the lack of an output schema, the description covers the essential return behavior (checkout_url, packs on invalid amount) and the full crypto workflow. It also notes the legacy field. Minor omissions like rate limits or error handling are not critical given the detail provided.
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 adds value beyond the schema by showing the exact JSON body for Stripe (method and amount), explaining the USDC verification sequence, and clarifying that amount must be 20 or 99 (with out-of-range returning packs). This enriches parameter understanding without repeating schema text.
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 begins with 'Add credits' and then details two specific methods (Stripe and USDC), including exact call formats and the credit conversion rate. This clearly states the verb-resource-action and the scope, making it easy to distinguish from data-fetching siblings like list_datasets or get_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on how to use the tool for both methods, including a step-by-step for USDC and a direct call format for Stripe. It notes that 'No human step and no wallet needed' for Stripe and that USDC 'requires more work,' which helps agents choose the appropriate method. It does not explicitly state when not to use the tool or name alternatives, but the context is sufficient.
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. Other datasets: unsupported (no retained proof).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | Yes | ||
| stamp_day | Yes | ||
| leaf_index | Yes | ||
| expected_row_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does well: it gives the exact truth conditions ('verified=true ONLY when ... AND ...'), defines the leaf index and row hash, and flags what the result does not certify. It stops short of describing the full response/error shape, so it is not 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 dense sentences, no filler and no restating of the tool name. The main purpose and parameters are front-loaded, and each clause (format, row path, AND condition, limitations) 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 4-parameter verification tool with no annotations and no output schema, the description covers inputs, verification semantics, dataset restrictions, and interpretation caveats. The only mild gap is that it doesn't explicitly state the output container for verified (e.g., a boolean field), though it is strongly implied by 'verified=true.'
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?
Even though schema description coverage is 0%, the description defines every input's meaning: stamp_day's format, leaf_index's 0-based row location in '/attestations/batch_<day>.tsv', and expected_row_sha256's role in the hash check. It also ties dataset to the only supported value, depin_onchain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource: 'Retained Merkle-membership check' for 'one depin_onchain observation', which immediately identifies its role. It also distinguishes itself from broader provenance/ledger tools by stating it verifies inclusion only and 'says nothing about Bitcoin status or upstream accuracy.'
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 supported dataset and explicitly excludes others: 'Other datasets: unsupported (no retained proof).' The limitation 'Says nothing about Bitcoin status or upstream accuracy' also tells the agent when not to rely on this tool's result. It does not name a specific sibling alternative, but the exclusion is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provenance-first DePIN telemetry: 331 live networks + 129 Bittensor subnets, 10,508 series.
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Hosted on-chain data for AI agents: DEX trades, OHLCV, top traders, fund tracing, address labels.
Add one secure layer between your agents and this server.
