Skip to main content
Glama

kairos-signal

by io.github.OV3RK177
OverviewDiscussionsAdmin

Buy a data product with credits

purchase_data
Destructive

Buy a product with your credits; the data ships 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_*, 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
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). 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 / 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)"
  2. 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"
+}
  3. 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)"
  4. Changed6 schema fields changed
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "Your API key from register_agent",
+  "type": "string"
+}
    • removedInput schema / properties / dataset
      Removed value: -{
-  "description": "Dataset to purchase",
-  "type": "string"
-}
    • addedInput schema / properties / product_key
      Added value: +{
+  "description": "Product key to purchase (e.g. houston_metro_leads, foreclosure_leads)",
+  "type": "string"
+}
    • removedInput schema / properties / quantity
      Removed value: -{
-  "description": "Quantity",
-  "type": "integer"
-}
    • removedInput schema / properties / sku
      Removed value: -{
-  "description": "Product SKU",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "dataset"
-]New value: +[
+  "product_key",
+  "api_key"
+]
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: deliverability is product-specific, data is returned inline, specific key families return 503 by design, and credits do not alter access tier. It does not, however, describe receipt/error behavior or warn that the credit spend is irreversible.

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?

Front-loaded with the action and the return behavior. The parenthetical about a price 'drifting' from its first location is wordy meta-commentary, but the remaining sentences (503 blocked keys, credits buy data not tier) each carry operational value.

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?

No output schema exists, and the description compensates by stating that data ships inline in the response and that deliverability is product-specific. For a destructive, credit-spending tool the remaining gap is the absence of receipt/charge-failure semantics, but the essentials for correct invocation are present.

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 product_key, api_key and idempotency_key are already fully documented, including retry semantics. The description only restates that the api_key comes from register_agent and points at list_products for keys/prices, adding little beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource ('Buy a product with your credits') plus the key outcome ('the data ships inline in the response'), which distinguishes it from siblings like list_products (browse) and fetch_dataset (retrieve). An agent can identify the operation 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?

Gives a clear prerequisite (api_key from register_agent), routes pricing lookups to list_products instead of trusting a restated figure, and names a concrete when-not case: the signal_*, dag_* and mcp_unlimited keys are priced but deliberately blocked. It stops short of advising when to prefer a read-only sibling over spending credits.

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

All kairos-signal 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