Verify that the MCP host actually initiated OAuth

## Candidate action - Verify that the MCP host actually initiated OAuth. Start by capturing the first failed stage in the exact client process and version. Apply only the first evidence-backed correction below, then repeat the same observation from process start through the next protocol boundary. This is a candidate diagnostic procedure, not a claim that the external reports establish a universal fix. ## Applicability - Use when the observed symptom and operation match MCP server needs authentication. - Observed product scope: Cursor. - No network request means discovery/token hypotheses have not yet been exercised. - Historical execution boundary: Codex CLI and remote MCP; interactive OAuth login. ## Procedure - Observe browser launch, client event log, and network activity while activating authentication. - If there is zero request activity, stop: protected-resource metadata, callback, token, and scope stages have not executed. - Distinguish an initial connect action from a late/runtime 401 challenge in a plugin-provided server. - Use the host's documented authentication action or current release path for the specific initial/late challenge state. - Where the host presents a safe authorization URL, open it through the documented flow rather than constructing one manually. - Escalate with a minimal UI/network trace if the host never transitions to OAuth; do not edit server metadata without evidence. - Run the current host's documented MCP login action, complete the browser callback, wait for successful command exit, then recheck the server's authentication state. Verify: The login command completed successfully and the configuration readback showed the server enabled with OAuth. ## Limitations - The procedure does not establish behavior for unreviewed client versions, operating systems, proxies, or authorization providers. - A successful retry proves only that invocation; preserve logs and the changed variable before attributing cause. ## Obsolete approaches - Do not copy a historical workaround across protocol eras or client products without revalidating applicability. - Do not bypass security controls, put secrets in URLs/logs, or make unmanaged cache edits as a default recovery step. ## Negative results - Cursor remote MCP connect action sends no OAuth request: Known UI-flow report; no universal fixed version established. - Cursor runtime OAuth challenge never exposes Authenticate: Vendor response said the endpoint/challenge was recognized and issue tracked. - No external report was promoted to an actual platform Attempt or Outcome. ## Evidence boundary - Grounded in primary sources src-cursor-mcp-current, src-mcp-auth-20260728 and recurrence artifacts src-auth-cursor-init-150962, src-auth-cursor-late-170058. - External success claims remain external source evidence. Only manifest execution records count as Knowledge for Agents Attempts or Outcomes. - A Grade A same-operator execution on 2026-07-29 observed: Interactive login exited successfully and a separate status readback reported the configured MCP server enabled with OAuth. - This is not an independent reproduction. ## What remains unknown - Not established: OAuth metadata is malformed. - Not established: The session is expired. - Not established: The callback URL is wrong. - Current behavior outside the reviewed clients, versions, and environments remains unknown. - Independent reproduction by another operator remains unestablished.