Find a Service before searching its catalog

Use a Directory as an optional starting point

An Agent does not need a Directory when it already knows a Service origin. When the origin is unknown, the Directory provides a searchable index of public Service metadata so the Agent can identify suitable candidates before beginning direct ODP discovery.

A Directory is not an ODP protocol role, and ODP does not standardize directory queries, rankings, facets, or response formats. The commands on this page use the InFlow Directory's API and its directory client; other directories can define different discovery interfaces without changing ODP Service behavior.

Keep the index and the catalog separate

Directory results are discovery metadata. They help choose a Service, but they do not replace a current Service Document or a response obtained directly from that Service.

Understand what is indexed

The InFlow Directory indexes public Service metadata and Collection names and descriptions. A Collection result includes its parent Service so an Agent can continue discovery at the correct origin. This index is not a substitute for reading the current Collection or Offering from the Service.

Search Service metadata

A free-text query can return matching Services and Collections. Structured filters narrow candidates by their Service's keyword, enrollment protocol, advertised ODP operation, payment protocol, or payment option. The --source odp filter restricts these examples to ODP entries. These commands do not search fields inside individual Offerings.

inflow directory search "AI search" --source odp \
  --keyword search \
  --operation search-offerings \
  --payment mpp:inflow --payment x402:base

Use facets to refine Service selection

Search results can include facet counts for matching keywords, operations, enrollment protocols, payment protocols, payment options, and trust protocols. Counts cover all matching Service and Collection results before the result limit is applied. A Collection contributes the metadata of its owning Service.

Directory facets are not Offering-search refinements. A facet narrows which Services are candidates; a refinement comes from a selected Service's search-capability catalog and narrows Offerings within that Service.

Find suggested names

Suggestions return Service and Collection names that match the supplied text and filters. Use a suggested name as a search query to retrieve the corresponding entries. These are names from the Directory's index, not keyword completions or terms accepted by a Service's Offering search.

inflow directory suggest sea --source odp

Continue the same search

The CLI supports a next continuation URL when a Directory returns one. Pass that value unchanged with inflow directory search --next; do not construct a cursor yourself. The InFlow Service-and-Collection search currently returns a limited result set without a continuation URL. Narrow the query or filters when that result set is insufficient.

Do not interpret the cursor, alter it, or combine it with new search criteria. Start a new search when the query, filters, or requested limit changes.

Interpret freshness and visibility correctly

Each result's indexed_at records when its metadata was indexed; a Collection has its own indexing time. It does not promise that a Service's live catalog has remained unchanged since that time. Inspect the selected Service before relying on its current capabilities.

Public search contains Services that are published, visible, and backed by a valid ODP Service Document. Paused, disabled, hidden, or invalid entries are excluded. A missing Service therefore does not prove that its origin lacks ODP support; it can still be inspected directly.

Treat ordering as Directory policy

The InFlow Directory ranks Service and Collection results by matches in its index, with identifiers providing deterministic ordering for ties. ODP does not define this policy, and position is not an ODP endorsement, a measure of Service quality, or a ranking of any Offering inside the Service.

Inspect the selected Service

After selecting a candidate, use service.service_origin from the result to retrieve the live Service Document. Verify the operations currently advertised, then request Collections, Offerings, or Actions directly from the Service.

The Directory remains public. The selected Service can require enrollment or authentication for its catalog operations and can protect later execution with MPP or x402.

Publish by submitting an origin

Submit a Service's HTTPS origin after its public ODP integration passes validation. Acceptance makes the origin eligible for indexing; it does not prove Seller ownership or transfer authority over the Service's catalog to the Directory.

The Directory refreshes its indexed metadata from the Service and can remove an entry from public search when the document becomes invalid or unavailable. Resubmission requests another refresh. Follow Publish to the Directory for the validation and submission sequence.

Next steps