Quickstart
Two paths, depending on which side of the transaction you are on. Both run against
stellar:testnet, which is free and needs no key.
I want to get paid
I want to pay
Core concepts
| Term | Meaning |
|---|---|
| Facilitator | The service that verifies a payment authorization and settles it on-chain. It never takes custody and is never the source of funds. |
| Resource | A paid HTTP endpoint or a paid MCP tool. Identified by resource.url, and for MCP by the tuple (resource.url, input.toolName). |
| Bazaar | The discovery catalog. Resources enter it automatically when a payment carrying discovery metadata settles. |
| Scheme | How the amount is determined. exact charges a fixed price. upto authorizes a cap and settles actual usage. |
| Auth entry | A Soroban authorization signed by the buyer permitting one specific contract call. Not a pre-signed transaction — the facilitator builds and submits the transaction around it. |
Discover services (Bazaar)
The Bazaar is how an agent finds a service it has no prior integration with. Every result carries what is needed to call and pay for the resource: the URL or tool name, the network, the asset, the amount, and the receiving address.
Choose a discovery interface
Three ways in. They return the same resources in the same shape.
SDK
Typed helpers over the discovery endpoints. Use this when you are writing the agent yourself.
REST API
Plain GET requests. Use this from any language, or to inspect the catalog by hand.
Bazaar MCP
Search and paid-call tools inside an agent runtime. Use this when a model drives the loop.
Discover with the SDK
Search by relevance
search takes a natural-language query and returns ranked results. Filters are
applied as hard constraints before ranking, so a result you cannot pay for never occupies a
ranked slot.
Browse without a query
When you do not need relevance ranking — a periodic sync, an inventory, a UI listing — browse the catalog directly with offset pagination.
List one seller's resources
If you know the address receiving payment, filter on it to see everything that seller has listed.
Discover with the REST API
Two endpoints. /discovery/search ranks by relevance and requires a query;
/discovery/resources browses and does not.
Query parameters
| Parameter | Type | Endpoint | Description |
|---|---|---|---|
query | string | search | Required on search. Natural-language description of the capability wanted. |
type | string | both | http or mcp. |
payTo | string | both | Filter to one receiving address. |
scheme | string | both | exact or upto. |
network | string | both | CAIP-2 identifier, e.g. stellar:pubnet. |
extensions | string | both | Filter to resources declaring a given protocol extension. |
limit | number | both | Maximum resources returned. |
offset | number | resources | Number of results to skip. |
cursor | string | search | Continuation token from the previous page. Advisory. |
Response envelope
partialResults is true when the response is complete enough to use
but not fully ranked — for example the reranking pass exceeded its latency budget and
results were returned from fusion alone. Treat the ordering as weaker, not the results as
wrong.
Discover with Bazaar MCP
The MCP discovery server puts catalog search behind a tool call, so a model can find a capability in its own loop — no discovery-specific code on your side. Paying for what it finds is the separate flow documented in Discover & pay over MCP.
The Bazaar exposes the catalog over MCP Streamable HTTP, on its own port — separate
from the REST API — at /mcp (default https://agentsmith.xyz/mcp). It is stateless and
unauthenticated — discovery is free. Point any MCP client at the URL:
Claude Code can register it in one line —
claude mcp add --transport http bazaar https://agentsmith.xyz/mcp
— or connect programmatically with the @modelcontextprotocol/sdk
Client over
StreamableHTTPClientTransport.
| Tool | What it does |
|---|---|
search_services | Natural-language search over the catalog. Required query, plus the same optional filters as the REST endpoint (type, network, asset, maxPriceUsd, limit). Returns a merged list — available (payable) services first, unavailable ones at the tail — as structuredContent plus a text summary. |
Inputs and outputs are structured and deterministic. Every rejection carries a non-null
machine-readable reason, so a model can reason about the failure instead of
parsing an error string.
Resource object
What a catalog entry contains, and which parts are optional.
| Field | Description |
|---|---|
resource.url | Endpoint address. Together with input.toolName this is the catalog key for MCP tools. |
resource.description | Human-readable summary of what the resource does. |
resource.mimeType | Response content type. |
resource.serviceName | Optional. Provider name, up to 32 ASCII characters. |
resource.tags | Optional. Up to 5 topical keywords. |
resource.iconUrl | Optional. HTTP or HTTPS only. |
info.input | How to invoke it. Discriminated by type: http or mcp. |
info.output | Optional. Response shape. |
schema | JSON Schema (Draft 2020-12) that info is validated against at catalog time. |
routeTemplate | Optional. Parameterized path pattern using :param syntax, for dynamic routes. |
accepts[] | Payment requirements: scheme, network, asset, maxAmountRequired, payTo, maxTimeoutSeconds. |
For MCP resources, info.input additionally carries toolName and
inputSchema (both required), plus optional description,
transport and example.
What to read next
Pay for a resource
A discovery result already carries the payment requirements, so the flow below works whether you found the resource in the Bazaar or already knew its URL.
What happens underneath
- The request returns
402 Payment Requiredwith the accepted payment requirements. - The signer produces a Soroban auth entry permitting exactly that transfer — asset, amount, recipient.
- The request is retried with the signed payload. The seller calls
/verify, then/settle. - The facilitator submits the invocation and pays the network fee. You need no XLM.
signatureExpirationLedger, derived from the seller's
maxTimeoutSeconds — roughly 12 ledgers, about 60 seconds, by default. A
slow retry loop lets an authorization lapse. Verify rejects an authorization with too few
ledgers left to settle, with a distinct reason, so you re-sign rather than lose the payment
mid-flight.
Metered calls
For services billed on usage rather than per call, the upto scheme authorizes a
ceiling and settles the actual amount consumed.
upto design is not final. upto has EVM
and SVM specifications but no Stellar one yet. We are authoring
scheme_upto_stellar.md and contributing it upstream; this section will document
the mechanism once that specification lands. Until then, treat upto as announced
but unspecified on Stellar.
Discover and pay over MCP
With the MCP server configured, a model can go from an intent to a paid result without any resource-specific code. The tool call below is the whole integration.
The server searches the catalog, applies the price ceiling, calls the best-ranked payable resource, handles the 402 and the signature, and returns the result together with the settlement hash. If nothing payable matches, it returns a typed reason rather than an empty answer.
Accept payments
Wrap a route, set a price, point at a facilitator. You do not touch Soroban RPC, auth-entry construction, or fee handling.
Get discovered
There is no registration step. Declare discovery metadata alongside your price, and the resource is cataloged the first time a payment for it settles.
Confirming the listing landed
The cataloging outcome comes back on the EXTENSION-RESPONSES response header as
base64-encoded JSON. Decode it to find out what happened.
| Status | Meaning |
|---|---|
success | Metadata validated against the schema and the resource is cataloged. |
processing | Accepted; cataloging is happening asynchronously. |
rejected | Validation or another check failed. rejectedReason carries the explanation. |
