MCP client compatibility matrix
Use a separate AutoFire credential per client so access can be attributed and revoked independently.
| Client | Transport | Authentication | Status | Guide |
|---|---|---|---|---|
| Codex CLI, IDE, and desktop | Streamable HTTP | Bearer token environment variable | Supported | Open ↗ |
| Claude Code | Remote HTTP | Authorization header from environment | Supported | Open ↗ |
| Generic 2026 MCP client | Streamable HTTP | Bearer token header | Supported | Open ↗ |
| ChatGPT hosted plugin | Remote MCP | OAuth 2.1 | Feature-gated pending production OAuth verification | Open ↗ |
Cloud MCP authentication
Hosted clients that do not support a custom bearer secret require OAuth. AutoFire’s OAuth resource metadata and consent storage are feature-gated; the public OAuth option will remain unadvertised until Supabase OAuth, asymmetric JWT signing, audience validation, consent, and revocation are tested in production-like conditions.
No token passthrough
The MCP resource server validates credentials for its own audience. It does not forward the inbound bearer token to another API or give clients a Supabase service-role key.
Requirements for a generic MCP client
- ✓ HTTPS Streamable HTTP support
- ✓ Bearer Authorization header support
- ✓ MCP 2026-07-28 or stateless 2025 compatibility
- ✓ JSON Schema-based tool input validation
- ✓ Ability to respect read-only tool annotations
- ✓ Secret storage outside prompts and project source