A shared protocol helps clients and servers communicate. You still need to check the features supported by the particular client, server, and account you intend to use.
“MCP-compatible” is a starting point for an evaluation. It is not enough information to promise that every tool, resource, prompt, authentication method, or interactive interface will work in every assistant.
Check the connection and the capability
Begin with transport. Does the client support the server's local or remote connection mechanism? Then check authentication and network reachability. A connector that works from one environment may be unreachable from another.
Next, list the specific capabilities the workflow needs. A client may support tool calls without presenting every other server feature in the same way. Optional extensions and protocol versions also matter. The MCP architecture documentation describes these building blocks.
Read the client vendor's current integration documentation rather than relying on a broad claim in a directory. Organization policy may further limit what the user can connect or invoke.
Make compatibility an acceptance test
Use a small case with a known result. Connect the intended account, discover the relevant tool, and call it through the assistant. Inspect the result in the underlying system.
Then exercise a missing item and an access refusal. If the workflow includes a write, use a reversible synthetic record and verify the stored outcome. Test the feature you are buying rather than stopping at successful discovery.
Keep a short compatibility record containing client version or surface, server version, transport, authentication, tested capabilities, and date. Document anything that was not exercised. This gives you a repeatable check when a component changes.
Separate the common compatibility failures
| Observed result | What to investigate next |
|---|---|
| Client cannot launch the local server | Supported local transport, executable path and runtime dependencies |
| Remote connection cannot be established | Endpoint, reachability and client connection support |
| Sign-in succeeds but the tool is refused | Account permissions, selected scope and organization policy |
| A tool works but a resource is unavailable | Support for the specific server capability and how the client exposes it |
| Direct SDK call succeeds but assistant task fails | Tool discovery, argument selection, approval flow and result handling in the actual client |
These observations help locate a failure; they do not establish its cause on their own. Keep the error message and the exact client surface with the test. A desktop client, a command-line client, and a cloud-hosted chat can have different setup requirements even when they come from the same vendor.
For a purchasing decision, request a supported combination precise enough to reproduce. “Works with MCP” leaves too much open. A named client surface, transport, authentication path and demonstrated action give you something you can verify and revisit after an update.
What to expect from a platform provider
Ask for supported combinations and an example you can run. A provider should distinguish protocol support from a tested integration. If the answer is “it should work,” record it as unverified until you complete the task.
OBTO publishes connection instructions for several clients in its getting-started guide. Choose the instructions for your client and verify identity and target scope before writing. Do not infer that a successful connection in one client proves another client's behavior.
When a client update changes the result, rerun that saved case before changing the server. The previous connection details help isolate which part changed.