Verify an OfflineCreator MCP client connection

Define success before testing the connection

Treat “connected” as a sequence of separately recorded checks, not as a single green badge. For this draft, the acceptance target is the July 28, 2026 MCP revision plus OfflineCreator’s current remote OAuth endpoint. A modern client can use server/discover to learn supported protocol versions, capabilities, and server identity; it can also send another RPC directly and handle an UnsupportedProtocolVersionError. Record the client name, exact client build, operating system, transport, configured resource URL, selected protocol version, and test time before interpreting any tool result.

This research did not run an authenticated desktop or IDE acceptance session. It verifies current public metadata, product documentation, and package documentation, then supplies a manual checklist for a future client run. Do not turn this draft into a compatibility stamp: a client can save a configuration yet still fail authorization, protocol selection, tool discovery, refresh, or revocation.

Protocol reference

MCP 2026-07-28Record the version actually used by the client; do not assume the newest documented revision was negotiated.

Acceptance status

Not executed in a named clientThe checklist is evidence-backed, but no end-to-end client result is claimed.

Verify the resource URL and authorization challenge first

Configure the recommended remote resource exactly as https://mcp.offlinecreatorstudio.com/mcp and start the client’s documented connection flow. OfflineCreator’s current first-party setup page describes this as the recommended remote OAuth connection, says the user completes Studio sign-in in a browser, and says no API key is stored in the published client file. Do not paste a fallback key into chat or append one to the URL.

The current public protected-resource metadata names this MCP resource, its authorization server, and the models, read, and generate scope identifiers. This is metadata evidence only: this pass did not retain an endpoint-response artifact, independently reproduce an authorization challenge, or prove that any client followed discovery, completed browser consent, stored a token safely, or reconnected successfully.

Pass evidence

Browser consent returns control to the clientCapture only the client-visible state and sanitized error text; never record codes or tokens.

Failure evidence

No browser, repeated 401, or callback errorKeep these as distinct outcomes because they point to different stages of discovery and authorization.

Use protocol discovery and tools/list as separate checks

After authorization, first record the server information and capabilities the client exposes. Under the current protocol, server/discover returns supported versions, capabilities, and self-reported server identity. Server identity is useful for display and diagnostics, but the specification says it is not verified and must not drive security decisions.

Next force a fresh tools/list request through the client if its interface permits it. The current tools specification requires a tool-capable server to return the tools available to the requesting client; the set may be empty and may differ according to authorization. Therefore, “the server appears in settings” is not equivalent to successful tool discovery, and an empty list is evidence to preserve rather than a reason to invent expected tools.

Discovery record

Versions, capabilities, server name and versionTreat identity fields as self-reported diagnostic information.

Tool record

Full visible tool names after authorizationSave a sanitized snapshot and note whether the client paginated or cached the result.

Build the scope matrix from observed tool lists

OfflineCreator’s live protected-resource metadata currently advertises models, read, and generate. The current MCP authorization specification says the scope in the 401 challenge is authoritative for that operation and may differ from scopes_supported. It also tells clients to request only the access needed. Record the scopes displayed during consent and any later scope challenge instead of assuming that every connection always receives all three.

The current @offlinecreator/mcp 0.1.2 package documentation lists nine tools, but it does not publish a claim-level mapping from every scope to every tool. A defensible acceptance test authorizes the smallest available set, records tools/list, adds access through the supported reauthorization flow, records tools/list again, and compares exact names. Do not infer a missing tool’s cause from its name alone.

models

Advertised scope identifierRecord the actual visible list after consent; this draft does not assign tools to the scope.

read

Advertised scope identifierTest independently from generation access when the client and consent flow permit it.

generate

Advertised scope identifierDo not invoke a paid or state-changing tool merely to prove that its name is visible.

Check models and credits without starting generation

OfflineCreator’s current package README names list_models for the launch catalog and credit costs, and get_credits for the current balance. Once both tools are actually visible, call only these read-oriented tools for the first content check. Record the sanitized tool name, whether the call succeeded, the shape of the response, and the time. Do not publish account identifiers, balances, prompts, media, authorization data, or raw client logs.

A successful list_models response and a successful get_credits response establish more than tool visibility: they show that the client can invoke those documented tools with the authorization presented on each request. They still do not establish generation access, sufficient funds for a job, stable pricing, or compatibility with another client build. If one tool is absent or fails, preserve the exact sanitized result and return to the scope matrix rather than guessing.

Read check 1

list_modelsConfirm a structured current response; do not hard-code catalog values into the acceptance result.

Read check 2

get_creditsConfirm invocation only with a test account whose balance can be handled as private data.

Retest after cache refresh, reauthorization, and revocation

A stale client view can hide a valid authorization change. The current tools specification allows tools/list results to be cached and allows the visible set to vary with authorization. If a server advertises listChanged, subscribed clients can receive a tools-list-changed notification and fetch the list again. Record whether the tested client refreshes automatically, offers a manual reload, or requires a restart; do not claim a universal reload control.

Finish with revocation as a separate destructive acceptance step. OfflineCreator’s public setup page says OAuth connections can be revoked from Settings, while the live authorization-server metadata advertises a revocation endpoint and refresh-token support. Revoke only the dedicated test connection, then retry discovery and one non-destructive read call. The expected security goal is loss of authorized access, but this research did not execute that sequence, measure propagation time, or verify the client’s token cleanup.

Evidence and publication boundary

The required last30days attempt on August 8, 2026 failed closed during preflight because the SCRAPECREATORS_API_KEY runtime secret name was unavailable. The vendored engine did not start, no planned source ran, and no telemetry artifact was produced. Zero returned items therefore describe a blocked attempt, not an absence of discussion on any community source. No community item supports a page claim, so community evidence remains insufficient.

This page preserves current primary protocol documentation and first-party product records refreshed after the blocked run. It verifies metadata, the documented 0.1.2 tool inventory, and an acceptance method, not an end-to-end result in Cursor, Claude, Hermes, Windsurf, VS Code, or another client. Keep the page draft, unreviewed, and unpublished until a dated named-client run supplies the missing observations and a successful research retrieval closes the access gap.