Pack of Cards

string name = 1 [(google.api.field_behavior) = REQUIRED];

Unchanged from v1.0.0.

The URL where this interface is available. Must be a valid absolute HTTPS URL in production.

Unchanged: endpoint in REQUIRED `supportedInterfaces[].url` (L339). Changed nearby: optional AgentInterface.tenant is now described as "An opaque string used for routing requests to a specific agent or tenant when multiple agents are served behind a single A2A endpoint" (L344-L345); the protocol "does not define its format or semantics" (L349).

Accessing `https://{server_domain}/.well-known/agent-card.json`

§14.3 template unchanged (L3328, L3337). IANA's well-known URI registry lists `agent-card.json` as permanent (checked 2026-09-15).

The resource at this URI MUST return an AgentCard object as defined in Section 4.4.1 of the A2A specification.

Still no media type for the card at the well-known URI. Changed here: the REST binding now says "application/a2a+json **SHOULD** be used for requests and responses" (L2750), which covers `GET /extendedAgentCard`; the JSON-RPC binding keeps `application/json` (L2236). `application/a2a+json` is still not in IANA's application registry (checked 2026-09-15).

A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.

Unchanged: proto is normative; JSON uses camelCase (§5.5, L1204).

A list of protocol extensions supported by the agent.

`repeated AgentExtension extensions = 3;` (L417). Unchanged.

Agent Cards **MAY** be digitally signed using JSON Web Signature (JWS)

Unchanged: JCS (RFC 8785) canonicalization before signing (L2008); `signatures` optional (proto L395).

The version of the A2A protocol this interface exposes.

REQUIRED (L354). Unchanged. Appendix A.2.1 still mentions an AgentCard `protocolVersions` field (L3509, L3517).

Optional human-readable title or display name for the MCP server.

`title?: string` (L81). Clients read `title` from the card, not the catalog entry (docs/discovery.md L54-L55).

Server name in reverse-DNS format. Must contain exactly one forward slash

Pattern `^[a-zA-Z0-9.-]+/[a-zA-Z0-9._-]+$` (L50). The valid example examples/ServerCard/valid/minimal.json uses `example-org/minimal`, with no dot. Catalog-level identifier: `urn:air:{publisher}:{namespace}:{name}` (docs/discovery.md L48).

Fetch `https://{domain}/.well-known/ai-catalog.json`

Card location: 'MCP Servers MAY host their Server Card at `GET <streamable-http-url>/server-card`, which we reserve for this purpose, though any unreserved URI (on any domain) is valid' (L174-L175). SEP 5c8483d L90: 'Cards can be hosted at any unreserved URI, with `<streamable-http-url>/server-card` reserved as the recommended location.'

Server Cards use the media type `application/mcp-server-card+json`.

Not in the IANA application media-type registry (checked 2026-09-15); the only 'mcp' matches are unrelated vnd.3gpp.mcptt-* types. Clients SHOULD send `Accept: application/mcp-server-card+json` (L182).

An **MCP Server Card** is a JSON document that describes a single MCP server

extension metadata, which remains the card's extension point.

The line begins 'Vendors who genuinely need to attach install hints to a Server Card can use namespaced [`_meta`]'. schema.ts L115 and L121 define `_meta?: MetaObject`. SEP 5c8483d L89: '`_meta` is not used to advertise MCP capabilities or negotiated extension support.'

Clients MUST NOT treat Server Card contents as authoritative for security or

Advisory only. The 'Server Card Accuracy' security note (L229-L238) calls an inaccurate card 'a mild confusion or downgrade vector'. Hosted cards MUST use HTTPS, TLS 1.2 or later, in production (L273). No signature or trust manifest.

Schema URLs are versioned by the `vN` segment rather than by date; a

$schema must equal `https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json` (L35, L40). version = server version, 'Equivalent of `Implementation.version`' (L55-L57). remotes[].supportedProtocolVersions = 'MCP protocol versions actively supported by this remote endpoint' (L199-L202). README.md L63: 'The `v1` shape is still pre-release and card-only'.

? displayName: text,

Prose: listed under OPTIONAL (L259, L261). Resolution order (L342): entry displayName, then the artifact's own name, then the identifier's trailing segment.

the standard `urn:air` naming structure is **HIGHLY RECOMMENDED** and **MUST** be used for open or federated systems.

Open-text field ('any valid URI or URN is accepted', same line). Format `urn:air:{publisher}:{namespace}:{name}` (L209).

/.well-known/ai-catalog.json

OPTIONAL; a catalog MAY be served from any URL. Link relation `ai-catalog` (L1256). Registration sections: link relation (L1629), well-known URI (L1645). Neither is in the IANA registries (checked 2026-09-15); IANA lists only RFC 9727 `api-catalog`.

application/ai-catalog+json

Registration section L1582. `curl https://www.iana.org/assignments/media-types/application.csv | grep -i catalog` on 2026-09-15 returns no ai-catalog entry.

An AI Catalog document is a JSON object that MUST contain the following

represent the extension type (namespace), and the corresponding value contains the extension data.

Keys 'MUST be a valid URL or a reverse-DNS string' (L1121-1122). Entry `extensions` L326; catalog top level L151; Trust Manifest L612.

contain at least one *substantive* trust member:

`trustManifest` is OPTIONAL (L553-555). Trust Manifest `signature` is a detached JWS (L604-605); optional top-level catalog `signature` JWS (L156-157). The CDDL still lacks the top-level `signature` (L1670-1675) and TrustManifest `subject`/`issuedAt`/`expiresAt` (L1709-1719).

`specVersion`

'Major.Minor' format (L104); Version Handling section L1174.

| displayName | MUST | Human-readable name. |

Row of the table introduced by 'An ARD entry MUST carry:' (L86).

Domain-anchored URN form (`urn:air:<publisher>:<namespace>:<agent-name>`); see Appendix C.

The JSON-LD @id MAY mirror the identifier (L90). ard-entry.schema.json pattern ^urn:air:... (L26).

Hosting a manifest of entries at `https://{domain}/.well-known/ard.json`.

Link relation: rel="ard" (L199). A consumer MUST fetch /.well-known/ard.json and MUST honour rel="ard"; it MAY also consult the predecessor /.well-known/ai-catalog.json and rel="ai-catalog" (L202). A publisher on the predecessor path SHOULD move to ard.json (L204). In-page JSON-LD markup (L197), Agentmap and DNS (L200) are also listed.

The manifest is a JSON document with an `entries` array of ARD entries (§4)

No media type is defined for the manifest document. Entry `type` is the artifact's IANA media type (L92); registries are found through entries whose type is application/ai-registry+json (L215). The application/ai-catalog+json nested-catalog examples are gone.

An entry is a JSON-LD node describing an agentic resource.

Per entry. A consumer MUST expand an entry with the ARD base context (L80; spec/schemas/ard.context.jsonld). Carrying @context in the entry is OPTIONAL (L82). The /.well-known/ard.json manifest itself is 'a JSON document' (L196).

Terms from any additional namespace declared in the entry's `@context` MAY also appear

Such terms become filter dimensions with no spec change (L108). `metadata` remains an optional descriptive term (L106). The schema sets additionalProperties: true by design (L530); ard.cddl ard-entry ends with a `* tstr => any` wildcard (L25).

ARD does not define a signing or verification procedure of its own.

trustManifest is optional; ARD requires only trustManifest.identity (L173), whose trust domain MUST align with the URN publisher (L177). Signing, canonicalization and key resolution come from the framework named in trustManifest.trustSchema (L181). ard-entry.schema.json L170 no longer names JWS. The schema's entry property key is `TrustManifest` (L81); the spec, ard.cddl (L45) and the base context use `trustManifest`.

ARD requires only an `entries` array of ARD entries

ArdManifest requires only entries (L106); other top-level members are transport-defined and ignored by ARD. ard.cddl ard-manifest is entries plus a wildcard (L13-L15). specVersion is no longer defined. The base context URL ends /context/v1 (spec L78) and entry `version` is the artifact version; neither is a spec-version field.

**Required:** `name` (Unicode string, unique within the issuing vendor namespace)

The spec text still has no display-name field. The companion schema schemas/fafa.schema.json documents an optional `agent.displayName` from 9e79b6914b6cb0ef6df299e52de17ccc47657a5e (2026-07-05), and FAFA's published card uses it (agent.fafa L9). See notes.

`id` (globally unique identifier — DID, URI, or vendor-scoped UUID)

Practice: FAFA's card uses `id: did:web:faf.one:agent`.

It does not define discovery, transport, authorization, or orchestration.

Spec unchanged. Practice only (not in spec): faf.one serves FAFA's card at /.well-known/fafa with Content-Type application/vnd.fafa+yaml (checked 2026-09-15). The one well-known URI request filed is for /.well-known/faf (protocol-registries/well-known-uris#97, open, labels 'new registration' and 'waiting for stable reference'). No request covers /.well-known/fafa.

(registered 2026-06-26, last updated 2026-06-26)

Spec at this SHA: L5 '**MIME Type:** `application/vnd.fafa+yaml`', L7 '**IANA Registration:** Registered 2026-06-26 (vendor tree)' (https://github.com/Wolfe-Jam/faf/blob/190c3380847c022da3e13a28af57c4dc68b3e02c/AGENT-FORMAT.md#L7). The IANA record's 'Published specification' is https://github.com/Wolfe-Jam/faf/blob/main/AGENT-FORMAT.md.

A `.fafa` file is a single YAML document:

§13 (L216): YAML 1.2 / RFC 9512.

**Optional top-level fields:** `attachment`, `provenance`, `signature`, `metadata` (free-form vendor extensions).

§13 (L219): forward-compat rule for unknown top-level fields and unknown agent/capabilities/endpoints subfields. It does not name `provenance` subfields.

Where present, `signature` carries provenance/integrity material; verification is the consumer's responsibility.

Unchanged. FAFA's published card carries no `signature` block.

The top-level `version` field declares which version of this specification the document conforms to.

Spec §16 (L252) lists 'Optional parameters: version', but the IANA record says 'Optional parameters: N/A' and 'versioning is handled in-band via the top-level "version" field'.