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, idempotent where possible, and carries a bearer token obtained during registration.

---

Step 1: Agent Registration via register_agent

An agent begins by calling register_agent, which authenticates the agent (typically via an API key provisioned during deployment) and receives an identity tuple plus an initial credit grant.

Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "register_agent",
  "params": {
    "api_key": "ks_prod_7f3a...b2c1",
    "agent_metadata": {
      "name": "helium-signal-collector-v2",
      "framework": "langchain",
      "capabilities": ["data_purchase", "credit_topup"],
      "owner_did": "did:key:z6MkhaXgBZDvotDk..."
    }
  }
}

Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "agent_id": "agt_9m4e2r0bi3j8",
    "bearer_token": "eyJhbGciOiJFZ255...",
    "credits": {
      "balance_cents": 500,
      "currency": "USD",
      "source": "welcome_grant",
      "expires_at": "2025-08-15T00:00:00Z"
    },
    "rate_limits": {
      "requests_per_minute": 60,
      "purchase_per_hour": 10
    }
  }
}

The bearer_token is a short-lived JWT (default TTL: 1 hour) that must be included in subsequent requests via the MCP Authorization metadata field. The welcome grant of 500 cents ($5.00 USD) allows the agent to immediately begin evaluating and purchasing low-tier data products without requiring payment infrastructure.

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 valid bearer token, 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://verify.kairos.signal/prod/hnt_iot_snap_v3/attestation"
      }
    ],
    "next_cursor": "eyJvZmZzZXQiOjEwfQ==",
    "total_count": 47
  }
}

Key design decisions in the catalog schema:

---

Step 2.5: Programmatic Evaluation via preview_product

Before purchasing, an agent can request a free preview of the data product. This is the autonomous analog of a human looking at a sample CSV.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "preview_product",
  "params": {
    "product_id": "prod_hnt_iot_snap_v3",
    "rows": 5,
    "format": "json"
  }
}

The response contains a subset of rows (deterministically selected—the first $n$ rows after a stable sort on the primary key) along with summary statistics that allow the agent's evaluation logic to make a purchase decision:

```json { "jsonrpc": "2.0", "id": 3, "result": { "product_id": "prod_hnt_iot_snap_v3", "preview_rows": [ {"hotspot_id": "112...abc", "lat": 37.7749, "lng": -122.4194, "status": "online", "reward_scale": 0.95, "poc_count_24h": 12}, {"hotspot_id": "112...def", "lat": 40.7128, "lng": -74.0060, "status": "online", "reward_scale": 0.88, "poc_count_24h": 8} ], "statistics": { "total_rows": 342817, "null_fraction": {"lat": 0.001, "lng": 0.001, "reward_scale": 0.03}, "schema": { "fields":