OAuth and CIMD
Algo Trade Analytics’s recommended MCP auth path is OAuth with metadata discovery. Capable clients should discover Algo Trade Analytics’s OAuth metadata from the MCP endpoint and use the MCP URL as the access-token resource audience.
This avoids the fragile setup that caused early failures: pasted bearer tokens, fixed Auth0 application client IDs, or pre-listed local callback URLs.
CIMD solves client registration and resource-audience discovery. It does not control how a local MCP client stores access tokens or refresh tokens after login. If a desktop client repeatedly prompts for Keychain or keyring access, debug that client credential store separately from Algo Trade Analytics’s OAuth metadata.
| Term | Meaning |
|---|---|
| MCP endpoint | The remote HTTP MCP URL copied from Algo Trade Analytics, such as a preview or production /mcp URL. |
| Resource audience | The API/resource the access token is for. For Algo Trade Analytics MCP, this is the MCP endpoint URL. |
| Protected-resource metadata | Metadata published by Algo Trade Analytics so clients can discover how to authenticate to the MCP resource. |
| Client ID Metadata Document (CIMD) | An HTTPS client_id document that describes the MCP client to Auth0. Auth0 fetches it on demand. |
| Dynamic Client Registration (DCR) | A fallback registration path for clients that require it. It is not the preferred Algo Trade Analytics user path. |
| Callback URL | A local URL owned by the MCP client during login. CIMD-capable clients should not require Algo Trade Analytics to pre-list every local callback URL. |
Expected OAuth Flow
Section titled “Expected OAuth Flow”-
The MCP client is configured with the Algo Trade Analytics MCP endpoint.
-
The client discovers protected-resource metadata from Algo Trade Analytics.
-
The client uses Algo Trade Analytics’s resource metadata to identify the authorization server and supported scopes.
-
The client presents an HTTPS Client ID Metadata Document URL as its
client_id. -
Auth0 fetches the CIMD and validates the client metadata.
-
The client starts a PKCE authorization-code login with the MCP URL as the
resourceaudience and requestsoffline_accessfor refresh-token issuance. -
Algo Trade Analytics receives access tokens scoped to MCP and bound to the Algo Trade Analytics account that completed sign-in.
What Not To Do
Section titled “What Not To Do”- Do not paste a bearer token when the client supports OAuth.
- Do not pass a fixed Auth0 application client ID for Codex/Claude primary setup.
- Do not pre-list local callback URLs for every CLI login port.
- Do not wrap the MCP URL in Markdown brackets.
- Do not use the preview endpoint as the production endpoint, or production as preview. Copy the value from the MCP Access page for the current environment.
Auth0 Requirements
Section titled “Auth0 Requirements”Algo Trade Analytics OAuth/CIMD depends on these authorization-server settings:
| Requirement | Why it matters |
|---|---|
| Client ID Metadata Document Registration | Allows clients such as Codex and Claude to present an HTTPS metadata document as client_id. |
| Resource Parameter Compatibility Profile | Keeps the MCP endpoint URL as the access-token audience. |
| Refresh token support | Keeps long-running MCP research jobs alive after the short-lived access token expires. The Authorization Server must advertise refresh_token and allow offline_access. |
| Supported MCP scopes | Allows mcp:read, mcp:research:write, mcp:candidate:write, and mcp:memory:write to be requested. |
Client Credential Storage
Section titled “Client Credential Storage”Long research sessions require two separate pieces to work:
- the authorization server must issue refresh tokens, and
- the MCP client must cache and refresh those credentials without repeatedly asking the user.
For Codex on macOS, repeated prompts for Codex MCP Credentials after clicking Always Allow point to local Keychain access behavior, not to a bad CIMD document. Use Codex’s file-backed MCP OAuth credential store or the manual bearer fallback on machines where Keychain prompts make OAuth unusable.
Why CIMD Helps
Section titled “Why CIMD Helps”CIMD lets clients register themselves without Algo Trade Analytics storing one dynamic client per local CLI/browser callback. This avoids Auth0 dynamic-client count pressure and keeps setup simpler for local tools that open callback URLs on random ports.
The result is a cleaner OAuth setup:
- no copied bearer token,
- no stored static client per local agent,
- no DCR entity buildup,
- no manual callback URL inventory,
- resource-audience tokens for the MCP endpoint.