Compatibility

Compatibility is a verified matrix

A compatibility entry should identify the client and version, transport, operating-system assumptions, authorization path, supported operations, known limits, and the date and owner of the verification. Marketing copy is not a substitute for that record.

Current preview boundary

• Codex and Claude Code setup examples are presented as planned flows.
• The public frontend does not exchange tokens or run a live compatibility probe.
• The MCP endpoint, auth callback, and runtime health contract require owner verification.
• Unsupported combinations should be labelled unavailable rather than inferred from a successful page load.

Current evidence record

The frontend currently has no owner-supplied, versioned client verification record. These rows make the absence of evidence explicit; they do not convert preview setup text into supported client policy.

• Codex: Not verified. Documented preview only: Remote Streamable HTTP MCP (preview setup copy); Browser OAuth (preview setup copy). Tested version, OS/architecture, operations, and verification date: not recorded. Support is not claimed.
• Claude Code: Not verified. Documented preview only: Remote Streamable HTTP MCP (preview setup copy); Browser OAuth (preview setup copy). Tested version, OS/architecture, operations, and verification date: not recorded. Support is not claimed.
• Other MCP clients: Not verified. No client-specific transport or authorization evidence is recorded. Tested version, OS/architecture, operations, and verification date: not recorded. Support is not claimed.

Owner evidence before support

1. Record the exact client version, OS/architecture, local or SSH browser location, transport, and authorization or device method.
2. Test and record the operations that actually work, including bounded scoped read and the failure/recovery cases; do not infer writes from reads.
3. Name the owning versioned contract and date the evidence without storing credentials or customer memory contents.
4. Keep the integration card planned or unavailable until that evidence exists and is reviewed.

Updating a client command

1. Change the command and its availability label in one place: the typed agent command list that feeds the connection guide and integration cards.
2. Update the matching example on this documentation site in the same change.
3. Record the change, its verification evidence, and the owning service confirmation in the changelog.
4. Only mark a client as available after the compatibility record above names the tested version, transport, and date.

What the matrix will record

1. Client name, version range, and transport mode.
2. Required identity provider and authorization callback behavior.
3. Read, write, relationship, and management capabilities that were actually tested.
4. Known failure states, recovery steps, and the next review date.