Kairos Signal — DePIN Telemetry

purchase_data

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 17, 2026

addedInput schema / properties / idempotency_key

Added value: +{
+  "description": "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.",
+  "type": "string"
+}

Changed1 schema field changedAug 9, 2026

changedInput schema / properties / product_key / description

Previous value: -"Product key to purchase (e.g. houston_metro_leads, foreclosure_leads)"New value: +"Product key to purchase (e.g. dag_pro, mcp_unlimited)"

First observedJul 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Kairos Signal — DePIN Telemetry tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?