Compatibility has three parts: the AI client must support the remote transport, the required authentication method and the tools used by your workflow. Your client's subscription or organisation policy may also affect availability.
What has been verified#
The managed connection baseline was tested with authenticated public HTTPS MCP requests, tool discovery and a harmless read-only tool call. It also passed missing-key, wrong-key, revoked-key and cross-client rejection tests.
Those tests verify the protocol path. They do not certify every version of every desktop application or a customer's separate business-service account.
Choose the right route#
| Client capability | Onboarding approach |
|---|---|
| Remote HTTP with secure custom headers | Suitable for verifying the managed API-key connection. |
| Remote HTTP with OAuth only | Requires a separately verified OAuth setup. |
| Local process connection only | Requires a supported bridge and a separate compatibility check. |
| Organisation disables external tools | The organisation administrator must resolve the policy restriction. |
| No MCP support | Use another supported application or agree a different integration route. |
When asking about a specific client#
Provide its name, version, workspace type and the connection options you can see. A screenshot of those options is useful if all keys, tokens and private details are hidden.
MCP support in one product does not imply that a different product from the same company supports the same connection method. Check each destination independently.
OAuth expectations#
OAuth uses a consent and token flow rather than entering a static API key. Support must be verified for the exact client, endpoint and account. An API-key test is not proof of OAuth readiness. Follow the route in your handoff; do not change authentication modes yourself.