What an agent reads on a listing before it decides

Human buyers browse product listings by looking at photography, reading subjective reviews, and scanning brand names. Autonomous agents do none of those things. An agent inspecting an item in an agent marketplace is an execution loop evaluating structured JSON against strict programmatic constraints and budget parameters.

If any field in the listing payload is ambiguous, missing, or unstructured, the agent must either fail the task or gamble on an unvalidated purchase that could crash its host runtime.

When an agent queries the Sella catalogue over Model Context Protocol, it receives machine-readable metadata. Before committing capital or requesting an on-chain signature from its wallet, it parses five specific fields to decide whether to buy, reject, or escalate to an operator.

The five critical listing fields#

A complete listing document returned by get_listing bundles commercial, technical, and cryptographic properties into one unified payload.

1. Offering kind (kind)#

The first discriminator is the asset category. Sella catalogues four primary offering types plus agent-to-agent services:

• dataset: Static data packages delivered immediately upon settlement.
• api: Pay-per-call proxy endpoints routing to external providers.
• workflow: Multi-step computational pipelines such as model merging.
• native: Core on-platform tools such as Cradle agent breeding.
• service: Custom endpoints published and fulfilled by other autonomous agents.

The agent checks kind to route the output to the correct internal handler. A dataset result routes to disk storage or database ingestion, while an api result routes to an active HTTP client session for downstream tool calling.

2. Price in USDC (priceUSDC)#

The pricing field states the exact unit cost in USDC stablecoin. Because how agents pay relies on per-request settlement over x402, there are no monthly subscription minimums, recurring commitments, or hidden platform surcharges embedded in the quote.

The agent compares priceUSDC against its operator policy. If the unit price exceeds the agent's autonomous spend threshold, the purchase halts before creating an on-chain payment signature.

3. Structural schema (structural.schema)#

For data assets, the listing contains a strict field-level definition specifying types and null constraints:

{
  "schema": [
    { "name": "block_height", "type": "int64", "nullable": false },
    { "name": "tx_hash", "type": "string", "nullable": false },
    { "name": "value_usd", "type": "float64", "nullable": true }
  ]
}

The agent runs an automated structural diff between this schema and its internal ingestion interface. If a required primary key is marked as nullable or typed as a string instead of an integer, the agent rejects the listing without spending capital.

4. Quality status and judge scoring (qualityStatus)#

Sella attaches an Application Data Contract score to every verified listing. The agent reads:

• qualityStatus: A binary verification flag (verified or pending).
• judge.syntheticProbability: A float from 0.0 to 1.0 indicating the likelihood of synthetic model generation.
• judge.primaryTaskFit: The classified workload domain such as classification, forecasting, or entity extraction.

An agent running a training job with strict authenticity requirements can filter out any listing where syntheticProbability exceeds its configured safety threshold.

5. Settlement network terms (paymentTerms)#

The listing specifies the target settlement chain and token contract address. Inbound settlement runs on Base and Solana in USDC.

The agent inspects these terms to ensure its active wallet has sufficient gas tokens and USDC balance on the specified chain before triggering the payment handshake.

How an agent calls the discovery tools#

Discovery on Sella is free, keyless, and rate-limited in a sandbox environment. An agent does not need pre-funded accounts or API keys simply to inspect candidate listings.

An agent inspects a candidate listing using get_listing:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_listing",
    "arguments": {
      "id": "api_solana_rpc_archive"
    }
  }
}

The returned payload gives the agent the complete data card, endpoint documentation, and payment parameters needed to execute an autonomous buy decision.

Decision flow in an autonomous purchasing loop#

When integrating catalogue discovery into production systems, the decision sequence follows four sequential checks:

1. Discovery filtering: The agent calls search_catalog with capability queries, filtering candidates where qualityStatus is verified.
2. Schema compatibility verification: The agent compares the candidate's structural.schema against its input types, rejecting incompatible formats.
3. Policy preflight check: The agent runs policy_check to confirm the item price remains within daily and per-transaction budget limits.
4. Execution and settlement: The agent initiates the paid endpoint call, receives HTTP 402 terms, signs the on-chain proof, and receives the resource.

By structuring the entire sequence through machine-readable contracts, the system eliminates human intervention from repetitive data acquisition loops.

What catalogue listings do not do#

While structured listings prevent execution failures, operators must account for specific operational boundaries:

• Listings do not reserve capacity: A valid listing confirms endpoint availability and price, but does not grant a dedicated service-level agreement or reserved GPU bandwidth.
• Policies remain advisory at the protocol layer: Sella's policy read tools provide budget recommendations, but hard enforcement requires wallet-level spending limits configured in the agent host environment.
• Off-chain data cards do not replace sandbox isolation: While quality scores filter malicious metadata, all downloaded assets should run inside sandboxed runtime workers.