Journey coverage and review

Open the interactive mockup.

Ownership and limits

Platform owns server response status/categories, safe messages, channel gates and fixed tool results. ChatGPT owns client presentation and WorkOS owns hosted authentication/consent. Client replies, connection labels, buttons and provider forms are illustrative; they do not establish exact vendor behavior, integration or endorsement. The mockup calls no service and signs in no user. All identities and endpoints are fictional; no credentials are stored. Review controls persist only the theme preference. Scenario/state links contain no user data. The connection's example name and URL remain in the current journey's memory and reset on restart or reload; they are not saved as real client configuration.

Coverage

Review questions

Review DataDescriber's proposed permission model, allowed and denied outcomes, server-owned messages, and rules for recovery, withdrawal and dependency failure. The yellow notes identify a functional decision or outcome to assess; they are not application instructions, explanations of vendor screens or requests to design ChatGPT/WorkOS UI. Omit a note where there is no distinct DataDescriber review point. Next step is only for progressing through the example, without previewing another scenario's content.

Verify the selected client/version separately: it may hide, paraphrase or replace HTTP error bodies. Vendor presentation and registration/sign-in compatibility remain integration evidence, not UI behavior controlled by this specification. Mockups cannot prove backend authorization, production accessibility or real WorkOS/ChatGPT compatibility.

Original-flow comparison — 2026-10-21

Compared the migrated package with the newer saved working copy from the MCP session, docs/changes/2026-10-02-remote-mcp/mockups/mockup.html. All eight scenario IDs/order, thirty states, twenty-five action/timer transitions, 750ms settling, criteria references and server-owned response contracts match the original. This was the baseline before the setup refinement below; all thirty screen texts also matched. The setup refinement added one explicit saved-configuration state, bringing it to thirty-one states and twenty-six transitions before the recovery refinement below. The original setup-to- authentication edge is refined into Save, then Authenticate. Other original edges and the remaining scenarios' server outcomes remain unchanged. The duplicate greeting at the end of scenario 1 is removed as described below.

Browser inspection exercised all thirty original states and the added saved- configuration state through their controls, including:

• Connection consent, cancellation, retry and restart; the read scenario owns the greeting.
• Read/write success, read-only write denial, missing read permission and disabled tenant; each preserved its original message, status and recovery boundary.
• Expired authentication, cancelled reconnect, retry and successful renewal.
• Unavailable access lookup, repeated retry and the completion page.
• Back/Forward, deep-state reload, cancellation of pending work on Guide, and preserving example form edits while zooming or collapsing guidance.

These are prototype/runtime checks, not backend tests, human acceptance or proof of a real WorkOS connection. The Product acceptance results remain pending.

Connection fields and intentional abstraction

The supplied client screenshot shows Name, transport Type, URL, an optional bearer token environment variable, static headers and headers sourced from environment variables. The setup screen now follows those field labels and grouping, with example Name/URL, selected Streamable HTTP transport and a Save action. Token/header fields remain empty for this WorkOS OAuth journey. Explanations about endpoints and authentication belong in the viewer's instructions, outside the vendor-owned UI. No real token or custom authorization header is requested; arbitrary field/row editing and transport switching are not modeled.

OpenAI documents HTTP URL configuration, optional token/header overrides and stored OAuth as distinct settings; configured bearer tokens and authorization headers are tried before OAuth. This prototype selects the OAuth path, rather than introducing a static-token authentication alternative. See OpenAI MCP configuration.

Save leads to the client server list without authenticated access. Its explicit Authenticate action starts the WorkOS consent/cancel path. This is the intentional change to the original flow, keeping configuration distinct from successful authentication. The WorkOS consent/cancel edges and server response contracts are unchanged. Scenario 1 now ends at completed authentication in settings; scenario 2 owns the read-permission tool. A successful provider flow is not itself proof of tool access. The model does not validate arbitrary endpoints, register a server or implement the vendor's configuration UI. Exact save/connect timing and field availability must be verified in the selected client/version. OpenAI's OAuth flow keeps protected-resource discovery, provider sign-in/consent and authenticated tool requests separate; a saved endpoint alone is not proof of usable access.

Provider surface review — 2026-10-21

The former purple WorkOS card was inherited from the source mockup, not verified against the deployed provider. It incorrectly appeared inside the ChatGPT shell. All client-header workspace labels are now removed. Provider states instead show a separate browser surface with an illustrative AuthKit address; they contain no ChatGPT application header. The address is fictional and no browser navigation or real authorization is performed by the mockup.

The connection consent layout is now informed by WorkOS's published OAuth application consent example. AuthKit's hosted UI flow redirects the user to provider-hosted authentication and then returns to the client. The example assumes an existing provider session and initial application consent. Names, account data and permission descriptions are illustrative; actual requested scopes, branding, wording, organization choice and sign-in methods are unverified.

The expired-authentication journey depicts hosted sign-in separately. It assumes the previous consent remains valid: WorkOS normally skips repeat consent for the same user/application unless scopes or organization access change. It does not depict re-consent as a way to repair a missing Platform permission. Both provider states retain their existing continue/cancel transitions and return to the client afterward (settings after initial authentication, chat after recovery). The mockup's historical consent action ID also completes sign-in recovery; it does not assert a fresh grant in that journey.

This is comparison with documentation, not verification of DataDescriber's actual WorkOS tenant/configuration or a guarantee about browser tab versus window choice. Capture the configured live flow before accepting exact provider UI fidelity.

Client settings examples — 2026-10-22

The supplied client screenshots show a saved MCP server in the Plugins → MCPs list, with an enabled toggle, registration mode Auto and an explicit Authenticate action. Scenario 1 follows that sequence, rather than starting OAuth with a chat greeting. Cancellation returns to the saved server row for another Authenticate attempt; completion returns there without repeating scenario 2's tool result. Enabling a server and authenticating are distinct from authorization to use its tools.

The Auto menu also offers Client ID metadata document (CIMD) and Dynamic client registration (DCR). These are observed client choices, not a verified WorkOS configuration decision. The schematic list now omits registration modes, settings icons, enablement toggles, plugin tabs and Add. It shows only the server name and Authenticate (or authentication status). Names edited during setup remain in the server row until restart/reload.

The third supplied screenshot depicts Cloudflare's browser-hosted authorization page. It confirms the context switch in that example; its scope choices, client identity, local callback and wording are not copied into WorkOS. The actual DataDescriber provider/client compatibility and registration mechanism remain to be verified. The supplied provider example identifies its requesting app as Codex; the existing ChatGPT-labeled mockup remains an illustrative client journey, not a claim that every OpenAI client has the same settings or OAuth behavior.

Recovery through the same server list

Scenario 7 offers MCP settings after the expired-token response, then uses the same server-list Authenticate action as scenario 1. It also shows the observed Reconnect notice as a direct entry to the same sign-in flow. The package has thirty-two states and twenty-eight transitions. Cancel returns to the saved server list with Authenticate available; it does not restore access. Successful hosted sign-in retains the original recovery outcome: the client retries the harmless greeting and displays its fixed result. Exact navigation labels and automatic request retry remain illustrative client behavior. This adds no fresh application consent or Platform permission, and preserves the 401 challenge and the remaining scenarios' server response contracts.

Specification and client presentation alignment — 2026-10-22

Product, Architecture, Program design, Delivery plan and Verification now describe Save, server-list Authenticate, browser-hosted sign-in and the separate read tool consistently. Interactive recovery uses the same saved server and Authenticate action. Cancellation, valid-consent reuse and client-owned request retry are explicit; real-client evidence and Product acceptance remain pending.

The schematic server list retains the same ChatGPT header as setup, including saved, authenticating, authenticated and cancelled states and recovery settings. Save and Authenticate share the same outlined button style and right alignment. The invented “DataDescriber access check” heading and tenant label above the chat are removed from all chat-introduction blocks. Conversation messages, tool results, server response contracts and scenario transitions are preserved. The client logo identifies the illustrative surface; it does not make the mockup an exact vendor UI.

Scenario descriptions explain the starting situation and the purpose of the example. Next step instructions contain only the action for the current screen: use its control, wait while a request runs, or advance/restart after an outcome. They do not repeat the description or ask the reviewer to use Send after its button has disappeared. All eight descriptions and thirty-two state instructions follow this split; the scenario graphs, product screens and results are unchanged.

Technical response reference

Nine focused reviewer notes cover functional outcomes or product decisions; twenty-three notes on setup, waiting or vendor-owned steps are omitted. The protocol contracts are retained here; client wording and layout remain illustrative and require verification in the selected client. The coverage table above retains the acceptance-criterion mapping.

Permission and tenant denials do not run the requested handler, emit an OAuth insufficient-scope challenge or trigger repeated consent. Ordinary read-only discovery omits the write tool; the denied-write scenario deliberately invokes it directly. Expired authentication includes the protected-resource metadata challenge; renewal/sign-in belongs to the client. Tenant disabling is shown after the bounded access snapshot expires: authentication remains reachable, previous access may persist until the configured maximum age, and no revision-file propagation is involved. Dependency failure cannot prolong expired authority; Try again repeats the same fixed outage in this prototype.

Runnable HTTP response test

Use the response reference implementation for the single-file HTTP fixture, start commands, test cases, limitations and real-client observation record. This experiment is separate from the interactive mockups.

Client response observations — 2026-10-22

The owner-run HTTP error trials show success and all five HTTP error cases in one conversation. The screenshot summarizes the whole sequence as observed in the client UI. It shows the assistant's replies, not raw tool responses or a guaranteed presentation contract.

The owner subsequently supplied English screenshots using the exact prompt try probe_response. The reference has since been corrected to expose the specified hello_read and hello_write tools. The ready composers, sent prompts and tool labels use try hello_read for read scenarios and try hello_write for write scenarios. The success, raw-401, denied-read, denied-write, tenant-disabled and temporary-outage replies reproduce the visible English text apart from those tool-name corrections, including the recorded correlation IDs. A later two-tool read-denial capture supplies the current read-denial screen, including mcp_read_required and its administrator guidance. The write denial uses the later two-tool capture, with the no-change statement and administrator guidance but no visible reason code or correlation ID. The generic hello_read returned: Authentication required. reply replaces the invented 401 explanation. A separate reconnect notice uses the observed title, explanation and Reconnect action; MCP settings remains available for the saved-server Authenticate path.

These are captured replies for the recorded prompt and trial, not a guarantee of wording in future conversations. The correlation IDs are copied examples from those individual requests; a running server generates new IDs. The write-success demonstration was not included in the original error screenshots. A later two-tool success trial shows both named tools in the same conversation. The successful read reply now copies hello_read returned: “Hello.”; the write reply copies hello_write succeeded: MCP write permission was verified. No data was changed. In the corrected reference, success supports both tools in one server run, while http403-write call refuses hello_write and still permits hello_read. The server-owned messages and permission rules remain unchanged.

Later 401 captures with both corrected tool names show the same client Reconnect notice. The hello_read reply is Authentication required.; the hello_write reply additionally states that no data was changed. Scenario 7 uses the captured read-tool reply. Both captures are retained in the response reference attachment.

The later missing-read trial shows mcp_read_required for both hello_read and hello_write. It confirms the fixture's prerequisite relationship in the client: write use also needs read access. In that capture, administrator guidance is repeated only in the read-tool reply, illustrating that the client may omit part of a server message.

The write-only denial trial shows a successful hello_read followed by a denied hello_write. Scenario 4 includes the successful greeting as conversation history before the write request. Its denial copies that capture, including “to enable access”; the client omitted both the reason code and correlation ID in this particular reply.

The two-tool tenant-disabled trial shows tenant_mcp_disabled for both tools, with administrator guidance and no visible correlation IDs. Scenario 6 copies the read-tool reply and its separate explanatory paragraph, replacing the earlier generic-tool capture.

The two-tool temporary-failure trial shows HTTP 503 and mcp_access_unavailable for both tools, each with a separate correlation ID. Scenario 8 copies the read-tool reply, including quotation marks around the explanation and the captured ID. Both observed replies suggest trying again later, without an authentication prompt.

Reconnect continues into the proposed hosted sign-in journey. The reference server has no OAuth provider, so successful sign-in, client return navigation and automatic retry remain illustrative rather than validated by these error trials. The owner also restored success, dismissed the reconnect notice and successfully used the tool again in the same chat. That demonstrates retrying the fixture without Reconnect, not credential renewal; the mockup must not imply that simply dismissing a notice repairs genuinely expired credentials.

Asset sources

• workos.svg: unchanged header wordmark served by WorkOS, retrieved on 2026-10-20.
• chatgpt.jpg: unchanged app icon from the OpenAI-published ChatGPT app, publisher OpenAI OpCo, LLC, retrieved through Apple's official lookup on 2026-10-20. ChatGPT/OpenAI marks belong to OpenAI; brand guidance. The logo identifies the depicted client.