Protocol reference
Connect speaks four protocols on the wire — MCP revision 2026-07-28, A2A 1.0.0, JSON-RPC 2.0 underneath both, and ordinary HTTP — and publishes three description formats: OpenAPI 3.1.0, Arazzo 1.1.0 and AsyncAPI 3.1.0. The rest of this section is background on standards Connect obeys as a publisher or does not implement at all, and each page says which it is.
What is actually on the wire#
Two of these are agent protocols with a live endpoint behind them. The others are files: a description a tool reads, or a convention a crawler follows. Mixing the two categories is the most common way to misread a protocol page, so the table separates them.
| Protocol | Version | Where it appears |
|---|---|---|
| Model Context Protocol | 2026-07-28 | POST /mcp — public documentation tools |
| A2A | 1.0.0 | /.well-known/agent-card.json and POST /a2a — five public skills |
| JSON-RPC | 2.0 | The envelope both of the above use |
| OpenAPI | 3.1.0 | The published description of the public HTTP API |
| Arazzo | 1.1.0 | Multi-step workflows across those API calls |
| AsyncAPI | 3.1.0 | The outbound webhook and event description |
| RFC 9309 | Robots Exclusion Protocol | robots.txt, served by the application |
| RFC 8615 | Well-known URIs | Everything under /.well-known/ |
| llms.txt | Community proposal | A supplemental map, not a standard |
| Schema.org | Vocabulary, not a version | JSON-LD on every documentation page |
Does Connect use every protocol in this section?#
No. Three groups, and every page belongs to exactly one of them.
- Implemented and reachable
- MCP, A2A, JSON-RPC, Streamable HTTP, well-known URIs, RFC 9309 and Schema.org. There is a running endpoint or a served file you can fetch.
- Published as a description
- OpenAPI, Arazzo, AsyncAPI and llms.txt. Connect writes these documents; nothing in Connect executes them at runtime.
- Explained, not implemented
- OAuth as a delegated-access pattern for agents, and most of the scheduling formats. Connect's own sign-in is Google OAuth and its API authentication is an integration key; neither is an OAuth authorisation server for third-party agents.
The reason for including the third group at all is that a reader integrating with Connect meets those standards elsewhere and needs to know where Connect stops. A page that only listed what Connect runs would answer half the question.
The two agent endpoints, in one paragraph each#
The MCP endpoint is POST /mcp, Streamable HTTP, and it exposes public documentation tools only: search, fetch, capability listing, workflow and protocol lookup, product status and the changelog. It needs no credential and reaches no workspace. Revision 2026-07-28 removed protocol-level sessions and the standalone GET stream, so GET /mcp and DELETE /mcp answer 405 with an Allow: POST header rather than hanging on a stream that would never carry anything.
The A2A endpoint is POST /a2a, advertised by a card at /.well-known/agent-card.json, and it answers message/send for five public skills: explain-connect, search-connect-docs, describe-capability, explain-workflow and explain-integration. There is no authenticated extended card. The card says supportsAuthenticatedExtendedCard: false rather than implying a private surface that does not exist.
Both read the same generated documentation corpus the website serves, so an agent and a person cannot be told different things about the same capability.
Reading order#
- Start with JSON-RPC 2.0 if you have not met it — both agent protocols are JSON-RPC underneath, and its error model explains most of what you will see go wrong.
- Then MCP and Streamable HTTP for the transport details, including the three headers every POST carries.
- Then A2A and the Agent Card if you are building an agent that needs to find Connect rather than a client that already has its URL.
- The description formats — OpenAPI, Arazzo, AsyncAPI — are independent of the above and can be read whenever you need them.
Each page here is about the standard. What Connect specifically publishes and how to call it lives under Developers, which is the practical companion to this reference.
Everything in this section#
19 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| A2A agent discovery | The three ways one agent finds another under A2A — a well-known URI, a curated registry, or direct configuration — and which one Connect supports. |
| A2A — the Agent2Agent protocol | The Agent2Agent protocol 1.0.0: how one agent finds another, asks it something in words, and why it sits beside MCP rather than replacing it. |
| Arazzo | Arazzo 1.1.0 describes a multi-step sequence across API calls machine-readably — the order, the criteria and the outputs that carry between steps. |
| AsyncAPI | AsyncAPI 3.1.0 describes event and webhook interfaces — channels, operations and message envelopes — and Connect publishes one for its outbound webhooks. |
| JSON-RPC 2.0 | JSON-RPC 2.0, the envelope MCP and A2A both sit on: request, response, notification, the reserved error codes and how Connect maps them to HTTP. |
| llms.txt | llms.txt is a community proposal, not a standard, and Google has said no Search system reads it. What it is for, and why this site publishes one anyway. |
| MCP resources | MCP resources and prompts: what each is for, when a resource is the better answer than a tool, and the four resources Connect publishes. |
| MCP security | Origin validation, authentication, scoping and blast radius for an MCP server — and the one tool nobody should build, whatever the request sounds like. |
| MCP tools | How an MCP tool is defined — name, title, description, input schema and annotations — and why a client must treat every one of those fields as untrusted. |
| MCP transports | The two MCP transports — stdio for a local process and Streamable HTTP for a remote server — and what revision 2026-07-28 took out of the HTTP one. |
| Model Context Protocol | What the Model Context Protocol is, what revision 2026-07-28 changed, and exactly which tools Connect exposes over it at POST /mcp. |
| OAuth for agents | Delegated access when the client is a program rather than a person: what OAuth gives you, what it does not, and how Connect handles machine callers instead. |
| OpenAPI | OpenAPI as a description format, why Connect publishes 3.1.0 rather than the newer revision, and the difference between a public contract and an internal route map. |
| RFC 9309 — the Robots Exclusion Protocol | What RFC 9309 actually standardises about robots.txt — matching rules, status-code handling, size limits — and the parts people quote that are not in it. |
| Scheduling formats | Where date and time interchange appears in Connect: RFC 3339 instants on the wire, due times on follow-ups, and why iCalendar does not appear at all. |
| Schema.org | The Schema.org vocabulary in JSON-LD: the types this documentation actually emits, the ones deliberately refused, and the rule that structured data must match the page. |
| Streamable HTTP | The Streamable HTTP transport in detail: one POST endpoint, the three MCP headers, when a response streams, and how a call is cancelled without a session. |
| The A2A Agent Card | The A2A Agent Card: where it lives, the fields that matter, how Connect generates its own, and what must never appear in a public card. |
| Well-known URIs | RFC 8615 and the /.well-known/ prefix: why fixed paths need a registry, what lives there on this site, and what does not belong there. |
Questions#
Do I need MCP and A2A, or is one enough?
Usually one. MCP is how a client — an assistant, an IDE, a script — reaches Connect's tools and data. A2A is how another autonomous agent discovers Connect and asks it a question in its own words. If you are wiring Connect into a chat client, you want MCP. If you are building an agent that must find capable peers at runtime, you want A2A. They are complementary rather than competing.
Why does this section give version strings for some things and not others?
Because some of these are versioned specifications and some are not. MCP revisions are dates, A2A and the description formats carry semantic versions, RFCs carry a number, and Schema.org is a continuously updated vocabulary with no meaningful version for a publisher to declare. Inventing a version for the last group would look precise and be wrong.
Is any of this needed to use Connect normally?
No. Everything in this section is for reading, integrating or auditing. A workspace using Connect for email, phone, WhatsApp and follow-ups never touches an agent endpoint or a description file.