You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Agent Catalog extends the agent discovery mechanism to support **open discovery of multiple agents served under a shared origin**.
2190
2190
2191
-
In the core specification ([Section 5](#5-agent-discovery-the-agent-card)), open discovery is typically performed using a well-known location—`/.well-known/agent.json`—which is the recommended way to expose an individual agent's Agent Card. This approach implicitly assumes a **one-agent-per-host** or **per-base-path** model, where each agent has its own dedicated and discoverable entry point.
2191
+
In the core specification ([Section 8](#5-agent-discovery-the-agent-card)), open discovery is typically performed using a well-known location—`/.well-known/agent-card.json`—which is the recommended way to expose an individual agent's Agent Card. This approach implicitly assumes a **one-agent-per-host** model, where each agent has its own dedicated and discoverable entry point.
2192
2192
2193
-
However, in real-world deployments, it is common for a single host or gateway to serve **multiple agents**, each accessible via distinct subpaths (e.g., `/a2a/agent1`, `/a2a/agent2`). The `/.well-known/agent.json` mechanism does not support enumerating such multi-agent deployments.
2193
+
However, in real-world deployments, it is common for a single host or gateway to serve **multiple agents**, each accessible via distinct subpaths (e.g., `/a2a/v1/agent1`, `/a2a/v1/agent2`). The `/.well-known/agent-card.json` mechanism does not support enumerating such multi-agent deployments.
2194
2194
2195
2195
To address this limitation, the Agent Catalog adopts the [API Catalog format (RFC 9727)](https://datatracker.ietf.org/doc/rfc9727/) as standardized by the IETF.
2196
2196
@@ -2200,10 +2200,10 @@ Clients can discover Agent endpoints and Agent Cards through the following mecha
2200
2200
2201
2201
-**Well-Known URI:** The Agent Catalog is exposed at a standard location such as `/.well-known/api-catalog` on the shared origin. This location is defined as a well-known URI in [RFC 9727](https://datatracker.ietf.org/doc/rfc9727/), enabling clients to locate catalogs in a consistent and interoperable manner.
2202
2202
2203
-
The Agent Catalog follows the [API Catalog format](https://datatracker.ietf.org/doc/rfc9727/), which is based on the [Linkset](https://datatracker.ietf.org/doc/rfc9264/) specification. This format allows a server to expose a collection of agent endpoints in a standardized structure, where each entry consists of:
2203
+
The Agent Catalog follows the [API Catalog format](https://datatracker.ietf.org/doc/rfc9727/), which is based on the [Linkset](https://datatracker.ietf.org/doc/rfc9264/) specification. This format allows a server to expose a collection of agent endpoints in a standardized structure, where each entry may include:
2204
2204
2205
-
-**An `anchor`:** The base URI for an individual agent (e.g., `https://example.org/a2a/agent1`)
2206
-
-**A `describedby` link:** Pointing to the agent's own Agent Card, which describes its capabilities and interface (e.g., `https://example.org/a2a/agent1/agent.json`)
2205
+
-**An `anchor` (optional):** The base URI for an individual agent (e.g., `https://example.org/a2a/v1/agent1`), if applicable.
2206
+
-**Link relations to the agent's description:** Typical examples include `describedby`, `service-desc`, or `service-meta`. Implementations may also use a URI pointing to the relevant section of the Agent Card specification (e.g., `https://a2a-protocol.org/latest/specification/#5-agent-discovery-the-agent-card`) as the link relation.
2207
2207
2208
2208
This mechanism enables clients to enumerate all available agents under a shared origin and fetch their respective Agent Cards dynamically. It makes agent discovery interoperable, extensible, and well-suited for federated or platform-hosted environments.
2209
2209
@@ -2213,41 +2213,7 @@ Agent Catalogs may expose sensitive metadata depending on deployment context.
2213
2213
2214
2214
For further considerations and best practices regarding the publication and protection of API Catalogs, refer to the [Security Considerations](https://datatracker.ietf.org/doc/rfc9727/) section of the RFC.
|`linkset`|[`AgentLinkContext[]`](#8a41-agentlinkcontext-object)| Yes | An array of agent-specific link context objects. |
2225
-
2226
-
### 8A.4.1. `AgentLinkContext` Object
2227
-
2228
-
Represents a [Link Context (RFC 9264 §4.2.2.)](https://datatracker.ietf.org/doc/rfc9264/) object specifically for agents. Extends the general Link Context structure by requiring an `anchor` field and including a `describedby` relation to link to the agent's card endpoint.
|`anchor`|`string`| Yes | A URI identifying the agent's primary endpoint. MUST be an absolute URI. |
2237
-
|`describedby`|[`AgentLinkTarget[]`](#8a42-agentlinktarget-object)| Yes | A list of links to the agent's metadata (Agent Card). |
2238
-
|*Additional properties*|`unknown`| No | Additional [link relation types](https://www.iana.org/assignments/link-relations/link-relations.xhtml) MAY be included as needed. |
2239
-
2240
-
### 8A.4.2. `AgentLinkTarget` Object
2241
-
2242
-
Represents a [Link Target (RFC 9264 §4.2.3.)](https://datatracker.ietf.org/doc/rfc9264/) object that specifically points to an agent card in JSON format. This is a specialization of the generic Link Target with a fixed media type of `application/json` as required for agent metadata.
|`href`|`string`| Yes | A URI pointing to the agent's metadata (Agent Card). MUST be absolute. |
2247
-
|`type`|`"application/json"`| Yes | The media type of the Agent Card. MUST be `"application/json"` to conform to A2A expectations. |
2248
-
|*Additional properties*|`unknown`| No | Extension attributes may be included, as defined in [RFC 9264 §4.2.4.](https://www.rfc-editor.org/rfc/rfc9264#section-4.2.4). |
0 commit comments