The Problem: Agents Need Data, But Data Markets Are Built for Humans
Modern AI agents—whether running as autonomous trading strategies, research pipelines, or DePIN orchestration daemons—require continuous access to high-fidelity, domain-specific data. The problem is structural: existing data marketplaces assume a human in the loop. A human browses a catalog, evaluates a sample, negotiates a license, enters payment details, and downloads a dataset. This process is fundamentally incompatible with autonomous agent workflows that operate on sub-second timescales and require programmatic procurement.
The Model Context Protocol (MCP) provides the transport and semantic substrate to solve this. By exposing data discovery, evaluation, and purchase as typed JSON-RPC methods over a standardized protocol, we can enable agents to autonomously acquire data products with cryptographically verifiable provenance and deterministic payment settlement.
This post walks through the complete MCP purchase flow—from agent registration to data delivery—with full protocol specifications, trust models, and architectural rationale.
---
Architecture Overview
The system comprises four logical layers:
┌─────────────────────────────────────────────────────┐
│ AI Agent Runtime │
│ ┌──────────┐ ┌──────────┐ ┌───────────────────┐ │
│ │ LLM/Plan │ │ Tool Use │ │ Credit Manager │ │
│ └────┬─────┘ └────┬─────┘ └────────┬──────────┘ │
│ │ │ │ │
│ ┌────▼──────────────▼─────────────────▼───────────┐ │
│ │ MCP Client (JSON-RPC) │ │
│ └────────────────────┬────────────────────────────┘ │
└───────────────────────┼──────────────────────────────┘
│ stdio / SSE / HTTP
┌───────────────────────▼──────────────────────────────┐
│ MCP Gateway Server │
│ ┌──────────┐ ┌──────────┐ ┌────────────────────┐ │
│ │ Auth & │ │ Product │ │ Settlement Engine │ │
│ │ Registry │ │ Catalog │ │ (Stripe + Escrow) │ │
│ └──────────┘ └──────────┘ └────────────────────┘ │
│ ┌──────────┐ ┌──────────┐ ┌────────────────────┐ │
│ │ Proven- │ │ Snapshot │ │ Verify Service │ │
│ │ ance Log │ │ Store │ │ (verify_url) │ │
│ └──────────┘ └──────────┘ └────────────────────┘ │
└───────────────────────────────────────────────────────┘
The agent communicates with the MCP gateway via JSON-RPC 2.0, as defined by the MCP specification. Every method call is stateless, and no bearer token or session is involved: authentication is a plain API key, passed as the api_key tool argument on the calls that need an account.
---
Step 1: Agent Registration via register_agent
An agent begins by calling register_agent, which self-registers the agent — no pre-provisioned key or identity provider is involved — and receives an API key plus an initial credit grant.
Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "register_agent",
"arguments": {
"agent_name": "helium-signal-collector-v2",
"email": "[email protected]"
}
}
}
The server registers the agent and returns its credential — a plain API key, not a token:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [{
"type": "text",
"text": "{\"api_key\": \"ks_live_9f2c...\", \"credits_balance\": 5.0}"
}]
}
}
Registration is instant and unconditional — no approval step. The free grant is $5.00 of credits (3 grants per IP per 30 days; a repeat signup from a used network returns a $0.00 balance with the reason in message), enough to evaluate and purchase low-cost data products immediately: POST /v1/credits/purchase debits the balance and ships the product inline. Credits never change the account's tier — tier-gated views stay 402 until a paid subscription tier.
The credit balance model is intentionally simple:
$$B_{t+1} = B_t - \sum_{i \in \mathcal{P}_t} p_i \cdot \mathbb{1}[\text{settled}_i] + \sum_{j \in \mathcal{T}_t} \Delta_j$$
Where $B_t$ is the balance at time $t$, $\mathcal{P}_t$ is the set of purchases settled in that interval, $p_i$ is the price of purchase $i$, and $\Delta_j$ represents top-up transactions. Credits are denominated in cents to avoid floating-point arithmetic issues—a principle borrowed from financial systems engineering.
---
Step 2: Product Discovery via list_products
With a registered key, the agent queries the product catalog. This is not a simple key-value lookup; the catalog supports multi-dimensional filtering over a structured schema.
Request
{
"jsonrpc": "2.0",
"id": 2,
"method": "list_products",
"params": {
"filter": {
"category": "depin",
"network": "helium",
"data_type": "snapshot",
"max_price_cents": 200,
"min_freshness_minutes": 60
},
"sort": {
"field": "freshness",
"order": "desc"
},
"pagination": {
"limit": 10,
"cursor": null
}
}
}
Response
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"products": [
{
"product_id": "prod_hnt_iot_snap_v3",
"name": "Helium IoT Network Snapshot",
"description": "Full state snapshot of Helium IoT hotspot metadata, proof-of-coverage receipts, and DC burn rates",
"category": "depin",
"network": "helium",
"data_type": "snapshot",
"price_cents": 150,
"freshness_minutes": 15,
"schema_version": "3.2.1",
"sample_rows": 5,
"provenance": {
"publisher_did": "did:key:z6MkhaXgBZDvotDk...",
"chain_of_custody": [
{"action": "ingest", "timestamp": "2025-07-15T10:00:00Z", "hash": "sha256:a1b2c3..."},
{"action": "validate", "timestamp": "2025-07-15T10:00:12Z", "hash": "sha256:d4e5f6..."},
{"action": "package", "timestamp": "2025-07-15T10:00:45Z", "hash": "sha256:g7h8i9..."}
]
},
"verify_url": "https://kairossignal.com/v1/provenance"
}
],
"next_cursor": "eyJvZmZzZXQiOjEwfQ==",
"total_count": 47
}
}
Key design decisions in the catalog schema:
freshness_minutes: The maximum age of the data in the snapshot. For DePIN data, this is critical—a 4-hour-old hotspot location dataset is qualitatively different from a 15-minute-old one.sample_rows: The number of rows the free/tryshowcase and the keyless surfaces let an agent evaluate before committing to a purchase.provenance.chain_of_custody: An append-only log of transformations applied to the data from raw ingestion to packaged product, each entry carrying a SHA-256 hash of the data state at that point.
Step 2.5: Programmatic Evaluation via the Free Sample
Before purchasing, an agent can evaluate data quality for free — no credits, no key. The autonomous analog of a human looking at a sample CSV is the keyless showcase endpoint:
curl https://kairossignal.com/try
The response carries full supply telemetry for 3 showcase networks, every value with its source, as_of timestamp and a verify_url back to the network's own API. The keyless surfaces (/v1/networks, /v1/supply, /v1/market, /v1/revenue, /v1/provenance) extend the same evaluation to the whole 40-network free sample — null-fraction behaviour, freshness verdicts and the provenance envelope are all visible before committing any credits.
Step 3: Purchase via purchase_data
Once the agent is satisfied with the preview, it purchases with credits (the real tool is purchase_data; the api_key from register_agent identifies the account being debited):
{
"jsonrpc": "2.0",
"id": 4,
"method": "tools/call",
"params": {
"name": "purchase_data",
"arguments": {
"product_key": "depin_supply_snapshot",
"api_key": "ks_live_9f2c..."
}
}
}
The server performs an atomic transaction: balance check, credit debit, and the data product ships inline in the same response — no separate delivery step — with its content_hash and provenance chain, so the agent can verify the delivered data is exactly what was purchased.
Why This Flow Matters
The MCP purchase flow is what makes autonomous data acquisition possible without a human in the loop. An agent can:
- Discover what data products exist via
list_products. - Evaluate data quality via the free
/trysample and the keyless endpoints before committing credits. - Purchase and verify delivery via
purchase_dataand theverify_url.
Try the flow — the browsing step needs no key at all:
# List available data products (keyless)
curl "https://api.kairossignal.com/v1/networks"
Preview before you buy (keyless)
curl "https://api.kairossignal.com/v1/supply?symbol=helium"
---
Try it yourself
Query the live catalog, supply telemetry, and provenance receipts directly: /v1/networks, /v1/supply on the REST API.
Related reading: the DePIN MCP server · the 10 MCP tools · how ai agents discover and use mcp servers · how AI agents buy DePIN data
Start with a free API key — $5 in credits, no credit card — and query the live networks, their series, and the MCP server. Try the API free → · See pricing
---
Get Started With DePIN Intelligence
Kairos Signal provides verifiable, provenance-first telemetry for DePIN networks, including first-party supply data read directly from a network's own API or blockchain. Every value carries a verify_url you can check yourself, and each daily batch is Merkle-rooted and anchored to Bitcoin.
Every API response is signed with ed25519 and timestamped. You can prove what was served and when, months later. That is what we mean by provenance-first.
Related reading: DePIN Intelligence Guide · DePIN Telemetry · How to Query DePIN Data · DePIN Data Verification · Pricing