Skip to content

CONCEPT Cited by 1 source

Provider service catalog API

Definition

A provider service catalog API is a machine-readable, JSON-over-REST feed that a cloud provider publishes listing every service an agent can provision through the provider. The catalog entries carry enough metadata — service name, resource type, provisioning command, pricing model, dependencies — for an agent to choose and call the service without the user specifying which provider or which product.

Canonicalised by the 2026-04-30 Cloudflare + Stripe launch:

"The full set of Cloudflare products and services from other providers is long and growing — arguably overwhelming to humans. But for agents, this catalog of services is exactly the context they need. Providers like Cloudflare make this catalog available via a simple REST API that returns JSON, and that gives agents everything they need."

Why it matters

Agents cannot drive complex provider platforms from static descriptions — the surface area is too large, evolves too quickly, and is phrased for humans. A provider-published catalog gives the agent the same discovery affordance a human dashboard gives a human: a browsable, filterable, up-to-date inventory of what can be provisioned, in a form an LLM can read.

Orchestrators (Stripe Projects is the canonical one) aggregate per-provider catalogs and expose a single surface the agent queries (stripe projects catalog).

Content shape (inferred from 2026-04-30 launch)

The launch post doesn't publish a schema but the command output + described use-cases imply at minimum:

  • Service identifier — e.g. cloudflare/registrar, cloudflare/workers.
  • Resource type — e.g. domain, compute-subscription.
  • Provisioning verb / command — the token the agent passes to stripe projects add (or equivalent).
  • Pricing model — whether paid, per-unit cost, free tier.
  • Prerequisites — other services to provision first.

Future formal-spec work (announced by Cloudflare + Stripe as upcoming) is expected to standardise the schema.

Sibling discovery primitives

The provider service catalog sits in a family of agent- facing discovery standards Cloudflare has been driving:

  • Agent Skills — task-instructional documents at /.well-known/agent-skills/index.json; how to do a task.
  • MCP Server Cards — pre-connect descriptions of an MCP server.
  • API Catalog / llms.txt — site-level API indexes agents read to understand the available surface.
  • /.well-known/oauth-protected-resource (RFC 9728) — where to find the authorization server for a resource.

The provider service catalog is the what-can-I-provision altitude; skills are how-do-I-do-it; API catalogs are what-can-I-call; MCP Server Cards are connect-me-to-a- tool-host. All four compose; none substitutes for the others.

Distinct from

  • Human-facing product catalogs. Product landing pages are designed for readability; service catalog APIs are designed for machine selection. A product page might have a 3-paragraph pitch and a screenshot; the catalog entry is a struct with service ID + resource type + pricing.
  • MCP tool schemas. MCP tool schemas are at function-signature altitude ("call this tool with these args"). The catalog is at service-existence altitude ("this service exists, and here is the command to provision it"). The agent calls MCP tools after provisioning; it reads the catalog before.

Open questions

  • Schema standardisation. Currently bilateral-spec between orchestrators and providers; a formal spec is promised but not published at launch.
  • Trust + freshness. Catalog entries could be stale or adversarial (misleading pricing, misrepresented capabilities). Trust-anchor and signing mechanisms are unspecified.
  • Versioning. Providers add/remove services; the catalog-consumer model for versioning + deprecation is not yet standardised.
  • Pagination + filtering. Cloudflare exposes ~3,000 API operations; catalog size could approach similar orders of magnitude. Pagination + filtering primitives for the agent-side consumer are open.

Seen in

Last updated · 433 distilled / 1,256 read