MCP client capability matrix for media generation
Compare documented transport, OAuth, stdio, tools, resources, and reload behavior while marking client acceptance as not run.
Connect OfflineCreator with OAuthCapability matrix dated August 8, 2026
This is a documentation-backed matrix, not a successful-client list. Cursor, Claude Code, and VS Code each document MCP tools, resources, remote HTTP, and local stdio in different ways, but this research pass did not run a fresh OfflineCreator connection in any of them. Cursor and VS Code also document MCP Apps, which is a client rendering feature rather than proof that OfflineCreator returns an app. Every row therefore carries an acceptance status of not run.
Pin protocol evidence separately from client documentation. The MCP 2026-07-28 revision removed protocol-level sessions and the initialize handshake, added per-request version and capability metadata, and made server/discover mandatory for servers. None of the fetched client pages states that a named client build has passed an OfflineCreator acceptance run against that revision.
- Cursor
- Docs: stdio, SSE, Streamable HTTP, OAuth, tools, prompts, resources, MCP AppsAcceptance: not run. Build: unrecorded. Update path for a custom server: update local files and restart Cursor.
- Claude Code
- Docs: stdio, HTTP, deprecated SSE, OAuth on HTTP, tools, prompts, resourcesAcceptance: not run. Build: unrecorded. list_changed refreshes capabilities; remote reconnect is automatic, stdio reconnect is not.
- VS Code / Copilot
- Docs: stdio, HTTP, tools, prompts, resources, MCP AppsAcceptance: not run. Build: unrecorded. Configuration changes require a server restart; automatic restart is experimental.
Acceptance ledger: what is proven and what is open
Protocol documentation and client feature pages establish documented capability, not interoperability. A publishable acceptance row still needs the exact client build, operating system, transport, negotiated protocol revision, authentication result, discovered tool and resource counts, reload observation, test date, and an attached trace or reproducible checklist.
The modern-versus-legacy boundary is the highest-risk failure mode. A modern-only server and a legacy client fail. A dual-era client can probe a server and fall back to legacy semantics when transport-specific detection identifies a legacy server; a dual-era server instead selects modern or legacy behavior from how the client opens. Record the actual revision observed on the wire instead of inferring it from a client's marketing page or from the presence of an MCP settings screen.
- 2026-08-08 / Cursor
- Documentation verified; acceptance not runNo client build, OAuth trace, discovery count, media tool call, resource result, or reload observation.
- 2026-08-08 / Claude Code
- Documentation verified; acceptance not runNo client build, negotiated revision, OfflineCreator OAuth trace, or nine-tool discovery confirmation.
- 2026-08-08 / VS Code
- Documentation verified; acceptance not runNo client build, OAuth result, server restart observation, tool count, or resource-list result.
Media-generation scope and surface
OfflineCreator's public endpoint metadata advertises models, read, and generate OAuth scopes. Its current package documentation for version 0.1.2 lists nine MCP tools for model discovery, balance checks, generation submission, image upload, status, bounded waiting, output retrieval, cancellation, and recent jobs.
That server-side tool list does not prove that a client displayed all nine tools, enforced the expected scope filter, rendered an image result, or exposed MCP resources. For acceptance, capture tools/list and resources/list separately, then record which operations are visible under each granted scope before spending credits on a generation.
- models
- Expected discovery scopeVerify model-related tools in the client rather than relying on the server README.
- read
- Expected read scopeVerify credits, job status, outputs, and history according to the discovered registry.
- generate
- Expected generation scopeConfirm the human-approved test budget before calling a paid media-generation tool.
Choose transport before comparing clients
Cursor documents stdio, SSE, and Streamable HTTP. Claude Code recommends HTTP for remote servers, supports stdio, and marks SSE deprecated. VS Code documents local command servers and remote servers with type http under a servers object. These schemas are not interchangeable.
For OfflineCreator, test the recommended Streamable HTTP OAuth endpoint first, then test the @offlinecreator/mcp stdio fallback only if the client supports launching a local process. Do not mark transport parity merely because both configurations can be entered; discovery, authentication, reconnect, and output handling must each pass.
- Remote-first
- https://mcp.offlinecreatorstudio.com/mcpDocumented product route; fresh client acceptance remains open.
- Local fallback
- @offlinecreator/mcp over stdioDocumented package route; requires separate process startup and credential handling checks.
Verify OAuth and reload as separate gates
Cursor documents OAuth for remote SSE and HTTP transports. Claude Code documents OAuth 2.0 for HTTP servers, token refresh after a 401, and re-authentication through its MCP controls. OfflineCreator publishes browser OAuth as the recommended remote route and advertises header bearer tokens for its protected resource.
A browser redirect completing is only one gate. The acceptance trace must also show the client reconnecting with authorization, discovering the expected scoped tools, surviving a configuration reload, and making a harmless read call before any generation. If a tool list remains stale, record whether the client received a change notification, restarted the server, or required a full application restart.
Continue with the client you can test
Use the setup directory to choose another client, or follow a narrower client page when you need configuration syntax and a future acceptance record.
Editorial boundary
This page owns a dated cross-client documentation matrix and a visible ledger of acceptance gaps. It does not own each client's setup walkthrough, promise universal compatibility, or treat documented features as tested behavior. Every branded-client row remains explicitly not run because no acceptance session established transport, OAuth, tools, resources, reload behavior, and the negotiated 2026-07-28 protocol revision together.
Refresh the source-backed capability rows monthly and add tested results only from reproducible named-build records. Until then, the useful comparison is which client controls and schemas are documented and which interoperability questions remain open, not a ranking of compatible clients.