Theo reports Opus generates unusable MCP authentication flows

• Opus repeatedly proposed unusable MCP authentication paths, according to theo’s report, including a browser flow that overlooked remote machines.
• The fallback added a script, device-code entry, and a manual completion handoff in his follow-up.
• An agent-written guide later made the MCP endpoint clickable, drawing another objection from Theo.

A device-code client polls for completion, making a separate human completion message a needless handoff. MCP access tokens also travel in an HTTP authorization header, never in the URL.

Opus repeatedly made assumptions that produced nonworking MCP authentication paths, Theo said in his initial report. When he challenged its assumption that the tool could open a browser, the model proposed a device-code flow with a script installer.

The callback problem is concrete: MCP’s official OAuth walkthrough uses http://127.0.0.1:8090/callback as its example redirect. With the browser on a laptop and the callback listener on a remote machine, that address points back to the laptop.

Theo subsequently rejected making the machine run scripts to generate authentication material. The model agreed to change its proposal so the server would create the token and the agent would only run curl.

Device authorization is an established OAuth mechanism for clients without a suitable browser. Under RFC 8628, the flow has three main stages:

1. The authorization server issues a device code, a user code, and a verification URL.
2. The user opens that URL on another device and approves access.
3. The client polls the token endpoint until authorization succeeds, fails, or expires.

The script installer and manual notification in Theo’s account of the proposal are additional workflow choices, rather than requirements of that protocol.

After saying he was working on the problem, Theo supplied an outline for a guide he could give future agents. Its first draft suggested publishing an HTML link labeled “MCP endpoint” on a service’s official site, prompting his objection to making the URL clickable.

The visible excerpt describes endpoint discovery. MCP’s documented authorization sequence distinguishes that server address from the browser’s consent destination:

1. The client contacts the MCP endpoint without a valid token and receives 401 Unauthorized.
2. Protected Resource Metadata identifies the authorization server.
3. Authorization-server metadata supplies its authorization_endpoint and token_endpoint.
4. The browser opens the authorization endpoint; the client exchanges the returned code and sends authenticated requests to the MCP endpoint.

MCP also has an OAuth Client Credentials extension for machine-to-machine access without interactive user approval. It uses application-level credentials: a client ID and secret, or a signed JWT assertion.

That authenticates the application using its own credentials rather than obtaining a user’s delegated authorization. The extension specification makes support optional, so this flow depends on implementation support rather than being available at every MCP endpoint.