# Discover support

> Find a support listing, check the brand's endorsement, and pass the selected agent to an assistant.

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:

```http
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:

```json
{
  "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:

```json
{
  "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](https://cautious-adventure-v6loy75.pages.github.io/concepts/trust-model.md#complete-entry-matching) 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.