Discover support

Find support listings from a brand’s domain or through registry search, check their endorsement, and connect to the selected agent. The examples use the current Open Service Directory (OSD) contract and the fictional airline Example Air.

Find entries

Read a known brand domain

If you know the brand’s canonical domain, retrieve its ARD manifest. For example https://airline.example/.well-known/ard.json.

Validate it against the OSD manifest schema, then look in its entries array for an agent that fits the task and uses a protocol your application supports. Entries published on the intended brand’s domain are endorsed by that publication.

Search a configured registry

Choose a registry under your application’s trust policy and send POST /search with an exact contract version, so you know which schemas apply. The registry domain here is fictional:

POST /search HTTP/1.1
Host: registry.example
Content-Type: application/json
Accept: application/json
OSD-Accept-Contract-Version: 0.3.0

{
  "query": {
    "text": "Example Air cancelled flight rebooking"
  },
  "pageSize": 5
}

To narrow the search to a known domain, use this query instead:

{
  "text": "cancelled flight rebooking",
  "@context": { "osd": "https://openservicedirectory.org/ns#" },
  "filter": { "osd:brandDomain": "airline.example" }
}

The context binds the osd prefix used by the filter. The filter constrains the brand. The text describes the need.

Inspect registry results

Confirm that the response declares OSD-Contract-Version: 0.3.0 and validate the body against the matching search-response schema. Reject responses with a missing or mismatched version header or an invalid body.

Each result is a complete OSD entry plus a relevance score and source:

{
  "results": [
    {
      "identifier": "urn:air:airline.example:support:assistant",
      "displayName": "Example Air Support",
      "description": "Support for cancelled flights and rebooking.",
      "representativeQueries": ["My flight was cancelled", "Help me rebook my flight"],
      "type": "application/mcp-server-card+json",
      "url": "https://support.airline.example/server-card.json",
      "@context": { "osd": "https://openservicedirectory.org/ns#" },
      "osd:brandName": "Example Air",
      "osd:brandDomain": "airline.example",
      "score": 96,
      "source": "https://registry.example/"
    }
  ]
}

• url addresses the agent’s card, which holds the connection details.
• source is the registry where the entry was indexed, not the agent’s origin.
• score measures query relevance, not brand endorsement or trust.
• osd:brandName and osd:brandDomain are claims to check against the business the customer meant.

If several candidates remain plausible, ask the customer. If none fits, refine the query or offer another support route.

Check the brand’s endorsement

For each registry candidate, retrieve and validate the manifest from the intended brand’s domain, then compare the complete entry, excluding score and source, with the published entries. The trust model explains its match, mismatch, and inconclusive outcomes.

Entries read directly from the brand’s validated manifest need no comparison. Either way, choose the agent that fits the customer’s request.

Connect to the selected agent

Retrieve the artifact referenced by url, or read inline data. The entry’s type identifies it, such as an MCP Server Card or an A2A Agent Card. Follow its connection details and authentication requirements.

The agent decides which tools or tasks are available and what the customer may do. After connecting, follow its authorization and customer-confirmation requirements.