Versions and what changed
Connect's product version is 6.3.2. Every page in this manual carries the date its claims were last checked against the running system, and every machine surface carries the specification version it is written to. All three are published together at /docs-data/versions.json, so a client never has to infer a version from prose.
Three versions that are not the same thing#
- The product version
- One number for the running system: 6.3.2. Connect is operated as a single production deployment, so there is no version for a workspace to be on, pin or upgrade to.
- The date on a page
- When this page's claims were last checked against that system. It moves independently of the product version, because a page can be re-verified without anything changing, and can go stale while the software moves on.
- A specification version
- Which revision of an external standard a published surface is written to — the MCP revision, the OpenAPI version, and so on. These change on the specification's schedule, not on Connect's.
Conflating the three is the usual way a reader ends up misled, which is why each is stated separately and each is generated rather than typed.
The specification versions#
Each of these was re-read from its primary source on 10 September 2026. These are the strings the generated artefacts actually carry, so a client can rely on them rather than negotiating.
| Specification | Version | Why that one |
|---|---|---|
| Model Context Protocol | 2026-07-28 | The revision the server implements: Streamable HTTP on one endpoint, POST only. This revision removed protocol-level sessions and the standalone GET stream, so GET and DELETE answer 405. |
| A2A | 1.0.0 | The agent card is published at the well-known path the specification names. |
| JSON-RPC | 2.0 | The envelope both of the above are carried in. |
| OpenAPI | 3.1.0 | 3.2.0 exists. The public description stays at 3.1.0 because tool support for it is universal and nothing here needs a 3.2 feature. |
| Arazzo | 1.1.0 | The workflow description that sits beside the OpenAPI one. |
| AsyncAPI | 3.1.0 | The description of the events a client can subscribe to. |
| RFC 9309 | The Robots Exclusion Protocol | robots.txt is written to the RFC rather than to convention, so a crawler's own parser and this site agree. |
| IndexNow | 1.0 | Bulk submission of changed URLs, up to ten thousand per request, with a key file of 8 to 128 hexadecimal characters. |
| llms.txt | Community proposal | Not an IETF or W3C standard, and Google has said no Search system reads it. Published as a supplemental map, never as a substitute for HTML, robots or sitemaps. |
What the date on a page means#
It means somebody checked the claims on that page against the running system on that day — the capability register, the code, a current test, the current production state, or an approved policy. It does not mean the page was edited then, and it does not mean the software changed then.
Where a page and the generated JSON disagree, the JSON is the authority. It is produced by the build from one source; a page is prose, and prose can lag.
Where a change is recorded#
Three places, each with a different job. The capability register is where an availability change shows up, as a word changing beside a capability. The version manifest is where a specification version changes. What a published change entry looks like, and how to follow one, is documented in the changelog and its feed.
Nothing in this manual is a per-release feature list. That is deliberate: a feature list tells you what moved, and the question a reader almost always has is what is true now, which the register answers directly.
What a version number will not tell you#
- Whether a capability is usable. The register says that, capability by capability, with its evidence.
- What your plan allows. Allowances are commercial and sit outside the version entirely.
- Whether a page is right. The date beside the page says when it was last checked; the number at the top of this one does not.
- Which specification revision a client should send. Read the version manifest, or the description document for the surface you are calling.
Questions#
Which version am I running?
The one in production. Connect is operated as a single deployment rather than as software you install, so there is no per-workspace version to select, and no upgrade for you to schedule.
Can I pin an older specification revision?
The published surfaces are written to the versions in the table above, and the manifest names them so a client can check before it calls. Anything a client needs to negotiate is documented on the surface's own page rather than assumed.
Is this manual versioned as a whole?
No. Each page carries its own checked date, which is more useful than one number for a thousand pages: it tells you the age of the claim in front of you rather than the age of the collection.