Google Agent Registry 2026: what is an Agent Card, and how do A2A agents describe capabilities, tools, and skills in JSON?

A catalog, not a third protocol

Agent Registry sounds like Google invented another conversation protocol. It did not. A2A still says how an agent describes itself and how it accepts a Task. The Registry is a discoverable-component catalog on Google Cloud: existing agents become searchable resources. After registration, orchestrators, Gemini Enterprise, and Agent Gateway in the same project can find them by skill keywords. The protocol is still A2A. What changed is who remembers the Card for you. Without a catalog you hard-code URLs in the orchestrator — a 2025 address book, not 2026 discovery.

Registration is automatic or manual. Same-project Agent Runtime, GKE with the AI-agent label and Card annotation, Cloud Run with the functional type, and Google’s own Workspace / Gemini agents can enter the catalog on their own. Automatic registration scans this project only. Cross-project, on-prem, or runtimes without auto-discovery need a handwritten Service, which then yields a read-only Agent. A central governance project that must see spoke agents uses manual cross-project registration, not a magic org-wide scan. The Register agents page was updated 2026-09-22.

The same catalog also takes MCP servers. That file is toolspec.json, shaped like a tools/list response, also capped at 10KB. So the Registry holds sideways colleagues and downward hands at once. Do not write one generic validator for both entry types. How the call hop checks arguments is MCP and JSON Schema. Today is only how the catalog remembers them.

The Agent Card: source JSON that gets indexed

An Agent Card is the A2A server’s digital business card. The spec path is still /.well-known/agent-card.json — see what’s new in A2A v1.0. For an A2A-compliant entry the Registry fetches that card and indexes skills for keyword search. The card itself must pass the official A2A schema. The 1.0 shape puts transports in supportedInterfaces, each with url, protocolBinding, and protocolVersion. Top-level url and protocolVersion are the 0.3 contract. A 1.0 client should not treat them as the primary fields.

Human identity is name, description, and version — the agent’s own version, not the protocol version. Protocol version travels with the interface. Each skills[] item needs id, name, description; the Registry searches tags. examples are prompts for humans, not an arguments schema. The full field table is the next post. Today: no valid Card, no automatic extract for the A2A type. Over 10KB and the Registry rejects the file; the orchestrator never finds you.

Below is a 1.0 card you can commit. Make it parse, then run the official schema. Pouring a whole runbook into description hits the cap first. Discovery is a short blurb plus tags, not a handbook stuffed into a business card.

{
  "name": "Invoice Specialist",
  "description": "Finds and summarizes invoices for finance. Does not post payments.",
  "version": "1.2.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "search-invoices",
      "name": "Search invoices",
      "description": "Look up invoices by week, status, or counterparty.",
      "tags": ["invoices", "finance", "search"],
      "examples": ["Find overdue invoices for last week"]
    }
  ]
}

After registration: what a catalog entry looks like

The spec does not make Google export a local “catalog snapshot.” Review still needs to see what got indexed. Fold the result into a fixture: displayName, specType (A2A_AGENT_CARD or NO_SPEC), cardVersion, extracted skill ids, interfaces, searchKeywords. That snapshot is not an A2A schema instance — do not validate it with the Card schema. It is a CI assert: registered is not the same as searchable.

{
  "registry": "google-cloud-agent-registry",
  "displayName": "Invoice Specialist",
  "specType": "A2A_AGENT_CARD",
  "cardVersion": "1.0",
  "skillsIndexed": ["search-invoices"],
  "searchKeywords": ["invoices", "finance", "search"],
  "interfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC"
    }
  ]
}

Automatic extract happens only for A2A-compliant entries. The Registry queries /.well-known/agent-card.json and writes claimed skills into the catalog. A NO_SPEC REST endpoint enters the catalog with nothing to search — orchestrators see that an agent exists, and cannot match “find the colleague who queries invoices.” To be searchable, add a Card or register standalone skill resources. Gemini Enterprise can also register standalone skills as top-level Skill resources. That is a separate governance line. Do not merge it into the same file as Card skills[].

Diff the snapshot against the committed Card. Keywords disagree: tags were omitted or the index lagged. URLs disagree: you registered a stale endpoint. Card valid but skillsIndexed empty: check whether the Registry read a 0.3 card with 1.0 rules — missing supportedInterfaces silently thins the extract, and the ticket still says “cannot find.”

Card skills are not MCP tools, and not Plugin skills

One word, three layers. A Card skill is what the agent claims it handles, for catalog search and orchestrator choice. An MCP tool is a deterministic call whose contract is inputSchema. A Plugin / Agent Skills SKILL.md is a brief for the same agent’s own model. The Registry indexes the first. Copy an MCP tool name into Card.skills[].id and search might luckily hit; delegation still faces an opaque agent, not tools/call. Multi-turn clarification and async callbacks burst a function-call shape.

Some Card implementations attach inputSchema to a skill. That is a hint shape, not the MCP execution contract. Do not validate a Card with plugin.schema.json, and do not validate tools/call with a Card. Three JSON files all say “capability”; failure handling differs. A bad Card is a discovery failure. A bad inputSchema is a call failure. How one coding agent grows skills and hands is Plugin Manifest in practice. Today is only how another agent is remembered by the catalog.

A NO_SPEC entry has no such claim. In the catalog it looks like an address-book line with a hostname. Orchestrators cannot find it by keyword unless you also register standalone skills or add a Card. Decide whether you need to be found before you decide to speak A2A. An empty Card “for the catalog” indexes an empty skill array — worse than not registering.

0.3 vs 1.0: do not mix the two contracts

The Registry accepts both 0.3 and 1.0; new cards should be 1.0. Version 1.0 moved protocol version and the primary URL into supportedInterfaces; extendedAgentCard sits under capabilities; 0.3’s stateTransitionHistory is no longer a core capability. Mix the two field sets and clients each read a different half; the catalog index loses a half. A2A’s own breaking list is on the v1.0 changes page, not a Google private fork.

Keep at least two cards in review: the legal 1.0 above, and a negative that parks url at the top while registering as 1.0. The second should fail 1.0 validation, or the primary endpoint is ignored. If CI mashes both schemas into one “generic agent check,” you are messier than the client. The Registry picks rules from the version you declared and does not fetch a schema while loading — the same discipline as a Plugin Manifest.

Signatures, extended cards, and GetExtendedAgentCard are the post-auth security layer, not the catalog on-ramp. The public card must yield skills first; then an orchestrator decides whether to pull an authenticated second copy. Signatures are out of scope today. Make tags searchable first.

Fixtures in JSONVue

Keep at least three review fixtures: the 1.0 Card above, the catalog snapshot, and a mixed 0.3/1.0 negative. The first must pass the A2A 1.0 schema. The second uses your snapshot schema, or asserts skillsIndexed and tags. The third must fail. Copying closed Plugin fields into a Card, or pouring a full MCP inputSchema table into skills[], shows up in a diff immediately.

Add one MCP counter-fixture: a legal toolspec.json, to prove the catalog’s second source file. Do not run the Card schema on it. tools[].name is for the runtime; skills[].tags is for search. No secret belongs in a committed fixture. A Card is a public business card — write it as if it will be fetched.

You can do this in the browser:JSON formatterto see whether the Card and snapshot parse;JSON Schema validatorto check 1.0 supportedInterfaces and skills;JSON Diffto catch tags / URL drift between the committed Card and the snapshot. Nothing leaves the machine. Further reading:A2A vs MCP, MCP validation, and the Plugin Manifest.

Related: A2A vs MCP, MCP and JSON Schema, Plugin Manifest in practice.

FAQ

Takeaways and next steps

In 2026, Google Agent Registry collapses to one line: it is a catalog; the Card is the source JSON that gets indexed. Orchestrators search tags and skill names, not the topology on your slides.

Ship in this order: a legal 1.0 Card; check specType at registration; assert skills actually landed in the snapshot; keep a separate toolspec.json for MCP. Check the three contracts in JSONVue. Layers: the A2A vs MCP post. Fields: the next post. The walk: the post after that.