How AI Agents Discover and Buy Data: The MCP Purchase Flow
The era of agents browsing dashboards, copying API keys, and manually wiring credit cards is over. As AI systems transition from passive tool-callers to autonomous economic actors, the infrastructure for machine-to-machine commerce must evolve from kludged REST portals into protocol-native transaction flows. The Model Context Protocol (MCP)—originally designed for context provisioning—is emerging as the transport layer for exactly this kind of autonomous commerce, particularly for data products.
This post walks through the complete lifecycle: an AI agent registers with a data marketplace via MCP's JSON-RPC, receives free starter credits, discovers and evaluates DePIN data products, purchases snapshots, and tops up credits via Stripe. We'll formalize the trust model that makes autonomous purchase viable—because when a machine spends money without a human in the loop, provenance is everything.
---
The Problem: Self-Service Commerce for Non-Human Actors
Traditional data marketplaces assume a human at a browser. The purchase flow looks like:
This breaks down at scale. A quant research agent exploring 200 DePIN feeds doesn't have time for step 2, and its operator shouldn't need to intervene for step 3. What's needed is a protocol-native commerce layer where agents can:
- Discover products programmatically with rich metadata.
- Evaluate fitness-for-purpose using structured provenance and verification.
- Transact using metered credits with deterministic settlement.
- Verify post-purchase that the data matches the product description.
---
Step 1: Agent Registration via MCP JSON-RPC
MCP operates over JSON-RPC 2.0, typically transported via stdio or SSE. An agent initiates by connecting to a marketplace's MCP server and exchanging capabilities.
Initialization Handshake
// Client → Server: initialize
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-03-26",
"capabilities": {
"roots": { "listChanged": true },
"sampling": {}
},
"clientInfo": {
"name": "kairos-quant-agent",
"version": "0.4.1"
}
}
}
// Server → Client: initialize response
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-03-26",
"capabilities": {
"tools": { "listChanged": true },
"resources": { "subscribe": true },
"prompts": { "listChanged": true }
},
"serverInfo": {
"name": "kairos-data-marketplace",
"version": "1.2.0"
}
}
}
After the handshake, the client sends an initialized notification. At this point, the agent is connected but not yet economically identified.
Agent Registration Tool Call
The marketplace exposes a register_agent tool. The agent invokes it with nothing but a name — self-registration is instant and unconditional:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "register_agent",
"arguments": {
"agent_name": "quant-signal-discovery",
"email": "[email protected]"
}
}
}
The server registers the agent and returns its credential:
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [{
"type": "text",
"text": "{\"api_key\": \"ks_live_9f2c...\", \"credits_balance\": 5.0}"
}]
}
}
message) to let the agent evaluate low-cost products before requiring payment infrastructure. This is the machine equivalent of a free trial, but deterministic and programmatically accessible. The key is a plain API key — no bearer tokens, no expiring credentials — and it authenticates the account surfaces only: purchases, balance checks, top-ups.
---
Step 2: Product Discovery and Evaluation
Listing Products
The agent discovers available data products through the list_products tool:
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "list_products",
"arguments": {
"category": "depin",
"modality": "weather",
"geohash": "u4pr",
"min_coverage": 0.95
}
}
}
The response returns structured product metadata:
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"content": [{
"type": "text",
"text": "[{
\"product_id\": \"depin:weather:helium:u4pr:daily\",
\"name\": \"Helium Weather Feed - Copenhagen Area\",
\"description\": \"Daily aggregated weather observations from Helium IoT sensors in geohash u4pr. Includes temperature, humidity, barometric pressure, wind speed/direction.\",
\"price_per_unit\": 5,
\"unit\": \"snapshot\",
\"data_format\": \"parquet\",
\"schema\": \"s3://kairos-schemas/depin-weather-v3.avsc\",
\"coverage\": 0.973,
\"provenance\": {
\"source_count\": 142,
\"last_audit\": \"2025-06-12T14:30:00Z\",
\"verify_url\": \"https://verify.kairos.network/v1/snapshot/depin:weather:helium:u4pr:daily/QmX7k...\"
},
\"temporal_range\": { \"start\": \"2024-01-01\", \"end\": \"2025-06-12\" },
\"quality_score\": 0.94
}]"
}]
}
}
Evaluation: The Fitness Function
An autonomous agent doesn't "read descriptions"—it computes fitness. The evaluation function combines coverage, quality, provenance depth, and cost:
$$ \mathcal{F}(p) = \alpha \cdot C(p) + \beta \cdot Q(p) + \gamma \cdot \log_2(N_s(p)) - \delta \cdot \frac{P(p)}{B} $$
Where:
- $C(p)$ is coverage (fraction of expected data present)
- $Q(p)$ is the quality score (completeness + accuracy)
- $N_s(p)$ is the number of source devices contributing to the product
- $P(p)$ is the price in credits
- $B$ is the agent's current balance
- $\alpha, \beta, \gamma, \delta$ are tunable weights reflecting the agent's utility preferences
The agent filters products where $\mathcal{F}(p) > \tau$ for a decision threshold $\tau$, then selects the argmax.
---
Step 3: Purchasing a DePIN Data Snapshot
Once the agent selects a product, it initiates a purchase (the real tool is purchase_data; the 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 a synchronous, atomic transaction:
credits_balance >= price.Response:
{
"jsonrpc": "2.0",
"id": 4,
"result": {
"content": [{
"type": "text",
"text": "{\"product_key\": \"depin_supply_snapshot\", \"status\": \"completed\", \"credits_balance_after\": 4.51, \"rows\": 141995, \"delivery\": \"inline — the full snapshot ships in this response\", \"content_hash\": \"sha256:a1b2c3d4...\", \"receipt\": { \"verify_url\": \"https://kairossignal.com/v1/provenance\", \"provenance_chain\":
"provenance_chain": [{"action": "ingest", "timestamp": "2025-07-15T10:00:00Z", "hash": "sha256:a1b2c3d4..."}, {"action": "validate", "timestamp": "2025-07-15T10:00:12Z", "hash": "sha256:d4e5f6..."}, {"action": "package", "timestamp": "2025-07-15T10:00:45Z", "hash": "sha256:g7h8i9..."}], "merkle_root": "0x8f2a...", "bitcoin_anchor": "btc-tx:5a1c..."}}}
The receipt carries a full provenance chain — from raw ingestion through validation to packaging — plus the Merkle root and its Bitcoin anchor. This is the crucial trust element: the agent receives cryptographic proof that the purchased data was not fabricated or altered, and that it existed at the time of purchase.
Step 5: Verification Loop
After delivery, a rigorous agent does not just trust the content_hash in the receipt. It re-computes the hash of the delivered artifact and confirms it matches sha256:a1b2c3d4.... It then checks the Merkle proof against the published, Bitcoin-anchored root. Only after both checks pass does it consider the data usable.
This verification loop is cheap and fully automated. It is the reason an autonomous agent can buy infrastructure telemetry without a trusted intermediary — every step is cryptographically checkable.
The Complete Autonomous Flow
Putting it together, the end-to-end MCP purchase flow is:
list_products — discover available data products.purchase_data — atomically buy with credits; the product ships inline with its content hash and provenance chain.verify_footprint — confirm the delivered data matches its published fingerprint.content_hash, Merkle proof, and Bitcoin anchor.The same flow is available via our REST API and the MCP server, giving both human developers and autonomous agents a self-serve path to 327 live networks of verifiable DePIN intelligence. No sales call, no manual approval — data discovery, purchase, and verification are all programmable.
Try it with a free key:
# Discover the catalog
curl "https://api.kairossignal.com/v1/networks" -H "X-API-Key: *"
Pull supply telemetry with provenance
curl "https://api.kairossignal.com/v1/supply?network=akash" -H "X-API-Key: *"
---
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