Skip to main content

ChatGPT Setup

Use this guide when connecting a ChatGPT-compatible MCP client/runtime to Zerq endpoints.

Surface selection​

  • Choose Gateway MCP for API invocation use cases.
  • Choose Management MCP only for tightly controlled operator workflows.

Endpoint and auth summary​

SurfaceEndpoint exampleRequired headers
Gateway MCPhttps://api.example.com/mcpAuthorization, X-Client-ID, X-Profile-ID
Management MCPhttps://api.example.com/api/v1/mcpAuthorization (OIDC bearer)

Local/Desktop MCP config template​

For ChatGPT MCP-capable local/desktop runtimes, use this server configuration pattern (or map the same fields in UI forms):

{
  "mcpServers": {
    "zerq-gateway": {
      "url": "https://api.example.com/mcp",
      "transport": "streamableHttp",
      "headers": {
        "Authorization": "Bearer <GATEWAY_TOKEN_OR_JWT>",
        "X-Client-ID": "<CLIENT_ID>",
        "X-Profile-ID": "<PROFILE_ID>"
      }
    },
    "zerq-management": {
      "url": "https://api.example.com/api/v1/mcp",
      "transport": "streamableHttp",
      "headers": {
        "Authorization": "Bearer <OIDC_ACCESS_TOKEN>"
      }
    }
  }
}

If your client UI asks for fields individually, map them as:

  • Server URL -> url
  • Transport -> streamableHttp
  • Headers -> same Authorization / X-Client-ID / X-Profile-ID values

Session handling rules​

  • Call initialize first.
  • Persist returned Mcp-Session-Id.
  • Send session header for all subsequent calls.
  • End session with DELETE when finished.

Practical rollout plan​

  1. Start with read-only tool access.
  2. Validate logs and policy behavior under expected load.
  3. Add write-capable tools only after approval gates are in place.
  4. Create separate credentials for staging and production.

Common pitfalls​

  • Reusing a stale session ID after restart.
  • Sending client/profile headers to management MCP.
  • Using production profile limits that are too permissive for agent traffic.