Skip to main content
Glama

Kairos Signal — verifiable DePIN data API

by com.kairossignal
OverviewDiscussionsAdmin

Buy a data product with credits

purchase_data
Destructive

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.

Input Schema

NameRequiredDescriptionDefault
api_keyYesYour API key from register_agent
product_keyYesProduct key to purchase (e.g. depin_provenance, depin_networks; list_products has every key and price)
idempotency_keyNoOptional. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"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. 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."New value: +"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."
  2. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"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."New value: +"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. 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."
  3. Changed1 schema field changed
    • changedInput schema / properties / product_key / description
      Previous value: -"Product key to purchase (e.g. dag_pro, mcp_unlimited)"New value: +"Product key to purchase (e.g. depin_provenance, depin_networks; list_products has every key and price)"
  4. Changed1 schema field changed
    • 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"
+}
  5. Changed1 schema field changed
    • 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)"
  6. First observed

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Kairos Signal — verifiable DePIN data API toolsInspect
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