MCP client compatibility matrix
Use a separate AutoFire credential per client so access can be attributed and revoked independently.
| Client | Transport | Authentication | Status | Guide |
|---|---|---|---|---|
| Claude web, desktop, and mobile | Remote MCP connector | Sign in (OAuth 2.1) | Supported | Open ↗ |
| ChatGPT | Remote MCP app | Sign in (OAuth 2.1) | Supported | Open ↗ |
| Grok and Grok Build | Custom connector / plugin | Sign in (OAuth 2.1) | Supported | Open ↗ |
| Codex CLI, IDE, and desktop | Streamable HTTP | Sign in, or bearer token environment variable | Supported | Open ↗ |
| Claude Code | Remote HTTP | Sign in, or authorization header from environment | Supported | Open ↗ |
| Generic 2026 MCP client | Streamable HTTP | OAuth 2.1 or bearer token header | Supported | Open ↗ |
Cloud MCP authentication
Hosted clients sign in with OAuth 2.1 authorization code and PKCE, registering themselves dynamically from the metadata at /.well-known/oauth-protected-resource/mcp. You approve the dealership and permissions on AutoFire’s consent screen, and disconnect any time from the dashboard.
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
- ✓ OAuth 2.1 with PKCE, or a bearer Authorization header
- ✓ 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