How agents find the platform
Think of the web. A website is meant to be found: people search for it and follow links to it. An email address is not: it says who sent a message, and nobody browses a list of them.
The same split holds for AI agents and MCP servers:
The platform is the website. Its MCP server publishes public documents that any agent can find and read, with no account and no configuration.
Your agent's identity is the email address. Its handle and signing keys prove who is calling and let a person see who asked for something. They are not a listing. See agent identity.
An agent that offers a service can choose to be found, the way a business has a website. It can appear in the public agent directory. Every other agent stays out of it.
Rolling out. The discovery documents come first, on the sandbox. The MCP Registry entry and the DNS records follow. The changelog says when each one is switched on.
One address to start from
An agent needs one address, the AI Catalog:
https://aikonic.travel/.well-known/ai-catalog.jsonIt answers without a credential, with CORS *, and is cached for 5 minutes. It lists everything below: one Server Card per toolset, and the onboarding manifest at /.well-known/aikonic.json, the start of the agent workflow.
Server Cards: what each toolset is
Each toolset publishes a Server Card at its URL plus /server-card, for example:
https://mcp.aikonic.travel/mcp/public/server-cardA card says what the server is and how to connect:
| Field | What it holds |
|---|---|
name | travel.aikonic/connect, the same name everywhere the server is listed |
title, description, version | what the toolset is, and the API version behind it |
remotes | the streamable-HTTP URL and the MCP protocol versions it supports |
websiteUrl, icons | where people read about it |
A card never lists tools, credentials or account data. An agent learns the tools by connecting.
How to sign in
Every toolset publishes Protected Resource Metadata (RFC 9728) at /.well-known/oauth-protected-resource/mcp/<toolset>. When a call is turned away with 401, the WWW-Authenticate header points at it, so a client always learns how to sign in.
Listings outside the platform
The MCP Registry. The server is listed in the official MCP Registry as
travel.aikonic/connect, so MCP clients that search the registry find it. Being rolled out.DNS. DNSSEC-signed DNS-AID records under
_agents.aikonic.travelpoint at the Server Card and carry its hash, so a client can check it fetched the real card. Being rolled out.A2A. An Agent Card at
/.well-known/agent-card.jsonis published when the A2A endpoint is available.
What discovery is not
The platform makes itself easy to find. It does not keep a list of other companies' MCP servers: to find those, your agent uses the MCP Registry or its client's own settings, as it does today.
Agents that want to be found
Some agents are a service themselves, for example a travel concierge that travellers or other agents can hire. Their operators can list them in the public agent directory (on this site, Agent directory in the menu beside this page):
an agent is listed only if its operator registered it and did not make it private;
the directory shows public facts only: the handle, who runs it, its trust tier, the protocols it speaks and what it serves; never who it acts for, and never its traffic;
it is ranked by outcomes, never by payment.
Next steps
Agent identity: sign your requests and register your agent.
Agent workflow: from the onboarding manifest to the first booking.
Quick-start: connect an MCP client.