Publish a support agent

Describe a support agent, publish its listing on the brand’s domain, and make it searchable through a registry. The examples use the current Open Service Directory (OSD) contract and the fictional airline Example Air. For the other side, see Discover support.

Prepare the agent and its card

Start with a working support agent and authorization to represent the brand. The agent might handle cancelled flights, answer policy questions, or route requests to a support team.

Prepare a protocol-specific card with the agent’s connection details. This example publishes an MCP Server Card at https://support.airline.example/server-card.json. You can instead include the complete card inline in the listing. The card’s URL is not necessarily the agent’s endpoint. Replace the fictional domains with ones you control or are authorized to use.

Create the support listing

An OSD listing needs:

• a globally unique, domain-anchored identifier, a human-readable displayName, and the artifact media type
• exactly one of url (the card’s location) or data (the complete card inline)
• osd:brandName and osd:brandDomain, the brand’s name and canonical domain, with an entry-level @context mapping osd to https://openservicedirectory.org/ns#

Add a short description and two to five representativeQueries describing tasks the agent handles. They help registries match it. Keep them general, with no customer records, credentials, or booking details.

Validate the listing and manifest

Put the listing in a manifest with an entries array, then validate both against the contract’s schemas with a Draft 2020-12 validator:

• osd-catalog-entry/0.3.0.schema.json validates the listing.
• osd-ard-manifest/0.3.0.schema.json validates the manifest.

Load them together with their referenced ard-entry/0.3.0.schema.json from the same release, keyed by their declared $id values. Fix every validation error before publishing.

Publish the brand’s endorsement

For Example Air, publish this JSON at https://airline.example/.well-known/ard.json:

{
  "entries": [
    {
      "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"
    }
  ]
}

Serve it as publicly readable JSON. Assistants must be able to fetch it without signing in. Publish one entry per support agent the brand endorses.

An authorized support platform can generate and maintain the manifest. Work with the brand’s website operator to serve it at this URL, even when the agent and its card are hosted elsewhere.

Submit the listing to a registry

The manifest already supports direct discovery. For registry search, submit the same complete listing through the registry’s admission process and follow its review requirements. Don’t change any fields. The registry adds score and source itself.

Test discovery and connection

1. Fetch the manifest from the public brand-domain URL and validate what is actually served. If it is unavailable, direct discovery fails and endorsement checks are inconclusive.

2. Confirm the referenced card is reachable and describes the intended agent.

3. If you listed the entry in a registry, search for it with the OSD CLI and confirm the verdict is verified:

   osd search "Example Air cancelled flight rebooking" \
     --target https://registry.example/ \
     --contract-version 0.3.0 --verify --json

   Try several representative queries that match the agent’s real scope.

4. Connect with a compatible MCP or A2A client using a test account. Check the operations, authentication, permissions, and any confirmation required before consequential actions.