[feature] Support pre-registered public OAuth clients in MCP configuration

[ekroon]

The problem

Some OAuth-protected MCP servers rely on a pre-registered public OAuth client. They expect the MCP client to use a supplied client ID with PKCE, without requiring a client secret or Dynamic Client Registration.

Executor already supports this through its backend API. A working connection can be created using:

1. executor.mcp.addServer
2. executor.coreTools.oauth.clients.create
3. executor.coreTools.connections.createHandoff
4. Browser OAuth authorization
5. executor.coreTools.connections.refresh

No direct database editing is required.

However, the current web UI does not expose an equivalent flow for configuring an existing public OAuth client without a client secret. The setup also cannot be represented as one declarative MCP configuration.

Users must therefore discover and execute several low-level API calls in the correct order. The resulting integration, OAuth client, and connection are stored as separate mutable records, making the setup difficult to discover and reproduce across machines.

Proposed shape

Expose the existing API functionality through the web UI and declarative MCP configuration.

One possible configuration shape:

{
  "type": "http",
  "url": "https://example.com/mcp",
  "oauth": {
    "clientId": "existing-public-client-id",
    "publicClient": true,
    "scopes": [
      "example:read"
    ]
  }
}

Executor should:

1. Register the MCP integration and public OAuth client together.
2. Use PKCE without requiring a client secret.
3. Request only the explicitly configured scopes.
4. Start the normal browser authorization flow when an account is added.
5. Store and refresh the resulting OAuth grant using the existing credential infrastructure.
6. Discover and register the connection's tools after authorization.

The web UI could expose the same fields when adding an OAuth-protected MCP integration:

• Client ID
• Public client
• Explicit scopes

Ideally, Executor could also import this information from common mcpServers configuration formats

Alternatives

• Continue using the existing backend API calls manually.
• Build a bootstrap script that performs the API calls in order.
• Create a new confidential OAuth application through the existing UI and provide a client secret.
• Add provider-specific presets containing known public OAuth client configuration.

The API and scripting alternatives work, but are less discoverable and reproducible. Creating a confidential OAuth application is unnecessary when the MCP integration already provides a suitable public client.

Related issues such as #859 and #1330 cover OAuth MCP setup and recovery problems, but do not appear to cover exposing the existing public-client API functionality through the web UI or declarative MCP configuration.

Where it belongs

Not sure

Before you submit

• I searched the open issues for a duplicate.