Skip to main content
The Parallax MCP server implements the MCP Authorization specification (OAuth 2.1). In a client that supports OAuth, connect the server URL and sign in through your browser. The client manages the access token for subsequent requests. When a client first connects to https://mcp.chicago.global/api/mcp:
1

Discovery

The client reads the server’s OAuth metadata from the well-known endpoints:
2

Dynamic client registration

The client registers itself automatically (no pre-provisioned client ID needed) and receives its OAuth credentials.
3

Browser sign-in

A browser window opens for you to sign in to your Parallax account and approve access. Authentication is handled by Chicago Global’s identity provider.
4

Token issued

The client receives an access token and uses it as a bearer token on every MCP request.
This flow is built in to Claude, Cursor, and VS Code. If your client only supports local stdio servers, use mcp-remote — it performs the same OAuth flow and caches the tokens locally.

Programmatic access (bearer token)

For scripts, tests, or servers that can’t do an interactive browser flow, send a bearer token directly in the Authorization header of your JSON-RPC request:
Use an MCP client or SDK for session initialization and transport handling. Depending on the response content type, the server can return JSON or Server-Sent Events (data: lines). Read the result.content of the JSON-RPC response whose id matches your request.
Treat bearer tokens like passwords. Don’t commit them to source control or expose them in client-side code. Contact parallax@chicago.global to request programmatic credentials.

CORS

The server sends permissive CORS headers and handles OPTIONS preflight, so browser- and edge-based MCP clients can connect. The OAuth and .well-known routes are intentionally reachable without a session so machine clients can complete discovery and registration.

Troubleshooting

Make sure your client supports remote MCP servers. Local-only clients need the mcp-remote bridge (see Connect a Client), which triggers the sign-in.
Your token expired or wasn’t sent. Re-authorize the connector, or (for programmatic use) obtain a valid replacement token for your Authorization header. The server supports the authorization-code grant; clients should reauthorize when a replacement is needed rather than request a refresh-token grant.
Last modified on September 21, 2026