# An MCP Client Compatibility Checklist for Caroush [Read the original article]() By Garry · Founder Published: 2026-09-29T20:06:34.093Z Updated: 2026-09-29T20:13:22Z 7 min read Categories: Social media tools Verify client version, transport, OAuth, discovery, result handling, and approval behavior before relying on a Caroush connection. ![Mint connectors of different shapes sit on an ink board beside a pale blue connector and an ivory inspection frame.]() ## Key takeaways - A vendor logo or generic MCP setting does not prove compatibility with a particular server. - Verify the exact client product and its complete authorization requirements. - Record the bounded operations that passed and retain clear limits on what remains untested. An AI product displays an MCP setting, and a website displays that product's logo. Those two observations do not prove that the product can complete a particular server's connection flow. Compatibility depends on the installed client, supported transport, authorization features, protocol behavior, and the workflow you intend to run. For Caroush, a useful checklist goes beyond “can I paste the endpoint?” It establishes whether the client can obtain the correct workspace grant, discover the required tools, interpret results, and preserve approval boundaries. Treat compatibility as evidence from a bounded test rather than a permanent property of a brand name. ## Identify the exact client product and version A vendor can offer several interfaces with different integration capabilities. A command-line agent, desktop application, web chat, and editor extension may not share the same MCP implementation or authorization support. Caroush's [client guides]() document Claude Code, Codex, Cursor, and compatible remote clients. That does not verify every other interface from those vendors or every assistant name displayed in the frontend selector. Record the exact product and installed version being evaluated. If the client updates automatically, note the version used for the last successful test. A support statement about a different product or release is useful background, but it is not evidence about your installation. Use the [Caroush MCP section]() to find setup information, then verify the specific path. Do not infer official partnerships, directory listings, or one-click installation from a logo or a general compatibility label. ## Confirm the transport the server actually uses The [MCP transport specification]() distinguishes transport models and optional behavior. Caroush documents a remote Streamable HTTP service with request-scoped streaming, not a local stdio package or a permanent server event stream. The client must support the server's actual transport. A client that only launches local processes is not automatically compatible with a remote URL. A wrapper may provide a bridge, but that introduces another component whose support and credential handling must be evaluated separately. Check the documented endpoint and the expected request behavior. Caroush's quickstart says GET and DELETE on the MCP resource return 405, so an address-bar page check is not the acceptance test. For a [social content platform](), the useful test is a supported protocol exchange that returns an expected result. The shape of a configuration field tells you less than the behavior of the completed connection. ## Verify the complete authorization requirements The [MCP authorization specification]() describes OAuth-based access for protected remote resources. Servers can have specific implementation requirements, and clients must support the applicable flow rather than only a subset of its visible screens. Caroush documents PKCE S256, resource indicators, and dynamic public-client registration. A client must also handle the accepted redirect behavior and token lifecycle. Opening a browser consent page is not proof that registration, code exchange, and protected requests all work. There is no unrestricted static-token fallback in Caroush's documented design. If a client lacks the required OAuth capability, do not compensate by pasting backend credentials or another user's token. Use a supported client or an explicit manual handoff. The account matters too. Eligible active paid access is required for API/MCP, and the seven-day trial excludes it. Compatibility testing under an ineligible account can fail for reasons unrelated to the client's protocol implementation. ## Check version behavior and discovery A client and server need a coherent supported protocol path. Current MCP architecture differs from legacy initialization behavior, and Caroush documents support for both newer and selected legacy versions. Follow the current quickstart and client implementation rather than combining examples from unrelated versions. After authorization, verify that discovery returns the tools needed for the task. The authenticated list can depend on scopes, so compare it with the connection's intended role rather than demanding the entire public catalog. Confirm that the client handles pagination or supported refresh behavior where relevant. A partially displayed list can reflect a client issue rather than a missing server capability. Keep a small expected-tool inventory tied to the workflow. For a draft pilot, that inventory can be narrow: context confirmation and a supported draft operation if mutation testing is authorized. An [AI content-generation workflow]() does not need every publishing, deletion, and automation tool merely to establish that the connection is useful. ## Inspect structured results and background work A compatible client should understand more than a text response. Caroush returns structured states, request references, operation references, and sometimes native resource identifiers. The client needs to preserve those distinctions when explaining progress. Test whether it can report an approval requirement without claiming the action executed. Test whether it distinguishes a queued operation from completed content. For get\_job\_status, the operation's own state appears inside the returned data, separate from the success of the read itself. If the planned workflow includes generation, the client must be able to follow the returned native object through the documented status tool. If it includes publication, the actual delivery state and real permalink matter more than the handler's initial success. A [scheduling workflow]() is not ready merely because login works. The client should preserve the correct object and delivery references through review, execution, and any uncertain outcome. ## Require visible approval and bounded authority Caroush requires browser review for consequential operations such as publication, scheduling, deletion, carousel approval, and sensitive automation changes. The client should surface the review URL and describe the exact pending action clearly. It should not approve on the user's behalf as a routine step, treat denial as a retryable error, or create replacement approval requests automatically after expiration. These behaviors concern the workflow's authority, not just its connection syntax. Use the [editorial review process]() to establish who checks content and destinations. Then verify that the client respects the backend approval boundary. A tool-enabled assistant can remain helpful while waiting for a person to make the consequential decision. Also review the client's broader tool environment. A narrow Caroush grant does not automatically limit what other connected services can receive. Keep private content and task outputs within the user's intended sharing boundary. ## Evaluate failure behavior, not only the happy path A useful acceptance test includes an invalid argument, a denied or absent permission in a controlled fixture, and a pending operation. The client should identify the failing layer rather than suggesting unrelated configuration changes or inventing success. Check retry behavior. Caroush mutations require stable idempotency identity for identical retries, and a new connection creates a new namespace. The client should reconcile uncertain prior work before creating a fresh action after reconnection. Observe whether it honors waiting guidance and stops bounded retries when a human decision is needed. A client that floods status reads or repeatedly requests broader scopes can be technically connected while operationally unsuitable. Keep the tests harmless. A controlled draft can verify creation when explicitly authorized, while fixtures can verify consequential boundaries. A real social publication is not necessary to establish basic client compatibility. ## Make a scoped compatibility decision Record the tested client version, endpoint, protocol path, account conditions, grant, and operations that passed. State the boundaries: perhaps reads and draft creation were verified, while generation or provider delivery remains untested. This is a more useful result than declaring a client universally compatible. It gives the team a supported path for its actual work and a clear list of checks to repeat after changes. It also prevents a successful personal experiment from becoming an undocumented promise to every customer. If an essential requirement fails, keep a manual handoff available and identify the missing capability. An assistant can still help write or review content without a working direct connection. The compatibility decision should tell people what they can reliably do today, what remains conditional, and what evidence would justify expanding the workflow. For a team decision, name the first unsupported requirement rather than presenting a vague failure score. “The client cannot complete the required public-client registration flow” gives a maintainer a concrete issue to investigate. “MCP did not work” does not. A specific gap also helps the team choose a temporary manual route without accidentally implying that the entire assistant product is unsuitable for writing or review. ## Sources - [Authorization - Model Context Protocol]() - [Transports - Model Context Protocol]() - [Caroush MCP quickstart and implementation boundaries]() ## Frequently asked questions ### Are all clients shown in the landing selector verified? No. Caroush documents specific paths for Claude Code, Codex, Cursor, and compatible remote clients. A displayed name is not proof of a tested connector or vendor endorsement. ### What OAuth capabilities does Caroush require? The current client guide lists PKCE S256, resource indicators, and dynamic public-client registration alongside the supported transport and redirect behavior. ### Is successful login enough to approve a client for use? No. Verify tool discovery, workspace context, structured results, background-state handling, and respect for approval boundaries under the intended grant. ### How should compatibility be reported? State the exact client version, conditions, and tested operations. Identify remaining gaps rather than declaring universal compatibility after a narrow test. ## About the author Garry Gaurav Sapkota builds Caroush, a workspace for creating, scheduling, and publishing social content. - [https://x.com/gauravsapkotanp]()