OAuth for Financial-Data MCP Servers

Connect to the hosted Alphanume MCP server with browser OAuth, verify the account tier that actually resolved, and reserve the API-key endpoint for clients that cannot open a browser.

The primary OAuth URL is https://mcp.alphanume.com/mcp. Claude and Codex open an Alphanume sign-in page, bind the client session to the API key already attached to that account, and expose 25 read-only tools. There is no separate MCP subscription or second set of market data behind the connector.

Those tools return the same deterministic point-in-time records as the REST API. OAuth changes how the client authenticates, not what a dataset means. A model can select a tool and explain a response, while research design, point-in-time cutoffs, and validation still belong in the saved workflow.

Pick the right endpoint

All three currently serve the same tools, but new interactive configurations should use the OAuth endpoint. The key endpoint is an explicit fallback for software that cannot complete browser authorization. Keeping those URLs separate avoids the common failure where a headless client waits forever for an interactive login.

For Claude web or desktop, open Settings, choose Connectors, add a custom connector, paste the OAuth URL, and click Connect. Sign in with the same Alphanume account used for the subscription. The connector carries across Claude web, desktop, mobile, and Claude Code for that signed-in account, so Claude Code does not need a second configuration.

Connect Codex with two commands

Codex registers the remote server first and starts OAuth second. The browser handles the account sign-in, while the client stores the resulting authorization for later sessions.

codex mcp add alphanume --url https://mcp.alphanume.com/mcp
codex mcp login alphanume
codex mcp list

The final command verifies registration. It does not prove that a particular dataset date is available to the resolved account, so follow it with a small tool call. If the browser opened under the wrong Alphanume login, disconnect the client authorization and repeat the flow with the intended account. Signing in with another account resolves that account's key, tier, limits, and history.

Verify the resolved tier

A successful OAuth handshake can still lead to a data error. An account without an API key receives a clear tool-call error, and a Free account requesting older history receives 403 DATE_RANGE_RESTRICTED. That response is expected tier behavior rather than a broken connector.

Use only Alphanume MCP tools.

1. List the available Alphanume tools and confirm there are 25.
2. Call the API-status tool.
3. Inspect the Historical Market Cap tool schema.
4. Request Historical Market Cap for ticker AAPL on 2024-06-28.
5. If the call returns 403 DATE_RANGE_RESTRICTED, report that the account does not have full-history access. If it returns data, report that the historical request is available.
6. Do not infer a trading signal from this connectivity check.

check_api_status reports service status and version, not account tier. Free access covers the trailing 20 trading sessions after a one-trading-session delay at 60 requests per minute. Pro provides current data and full history at 600 requests per minute. The fixed historical request above distinguishes the entitlements without relying on tool visibility. The pricing and access page is the appropriate source for choosing the history required by a real backtest.

Use a key when there is no browser

Cursor, CI jobs, custom agents, and other headless clients should point to the key endpoint and attach the existing Alphanume API key. Keep the value in a secret store or environment injection layer, never in a committed project file.

{
  "mcpServers": {
    "alphanume": {
      "url": "https://mcp.alphanume.com/key/mcp",
      "headers": {
        "X-API-Key": "${ALPHANUME_API_KEY}"
      }
    }
  }
}

The header can instead use Authorization: Bearer alp_.... A key-based client inherits the same tier and rate limits as REST and OAuth. If a vendor does support remote OAuth, prefer the browser path because it avoids copying a long-lived key into another configuration surface.

Know what revocation changes

• Client revocation. Removing or revoking the OAuth connection in the MCP client ends that client authorization but does not revoke the REST API key.
• Account choice. OAuth resolves the key attached to the account used in the browser, so a second login can expose a different tier.
• Key rotation. Headless configurations must receive the replacement key through their secret-management path.
• Tool limits. Every data tool accepts max_rows, defaulting to 500, and a truncated response should lead to narrower filters.
• Research limits. Authentication proves access only. It does not validate joins, remove lookahead bias, or establish profitability.

Do not troubleshoot a date-range restriction by repeatedly reconnecting. Confirm the signed-in account, compare the requested date with the tier window, and preserve the exact error. A real outage and an account-policy refusal need different fixes.

Run one auditable connection test

Use the hosted MCP documentation to connect one client, run the verification prompt once, and save the endpoint, client name, account identifier, tool list, request arguments, response count, and any error code. Then disconnect and reconnect once to confirm that authorization behaves as expected. For a longer research job, move the accepted query into deterministic REST code and keep OAuth as the agent's discovery interface.

The related Codex MCP setup guide shows the client-specific path. The useful next action here is narrower: prove which account and tier the server resolved before asking an agent to design a backtest around unavailable history.