Skip to main content
Instead of using stdio, you can run the server as a persistent HTTP service. This enables multi-user scenarios and remote deployment.

Transport Types

Stateless Mode

For Kubernetes deployments or environments where session state should be ephemeral, use the --stateless flag with streamable-http transport:
The --stateless flag is only supported with streamable-http transport. Using it with stdio or sse will result in an error.

Basic Setup

IDE Configuration:

Multi-User Authentication

Both transport types support per-request authentication where each user provides their own credentials.

Authentication Methods

Server Setup for Multi-User

1

Run OAuth Setup (if using OAuth)

2

Start HTTP Server

3

Configure Environment

OAuth Discovery + DCR for MCP Clients

When ATLASSIAN_OAUTH_PROXY_ENABLE=true, the HTTP service exposes OAuth discovery and DCR endpoints so MCP clients can onboard users through spec-aligned OAuth:
  • /.well-known/oauth-protected-resource
  • /.well-known/oauth-authorization-server
  • POST /register
  • GET /authorize
  • POST /token
  • callback route derived from ATLASSIAN_OAUTH_REDIRECT_URI
Use this for remote clients like ChatGPT/Codex that expect discovery + DCR.
The DCR client’s redirect_uri must be different from the OAuth proxy’s own IdP callback. If a client tries to register the proxy callback as its redirect URI, registration is rejected with invalid_redirect_uri to prevent a callback loop.

Multi-Cloud Support

For multi-tenant applications where each user connects to their own Atlassian cloud instance:
  1. Enable minimal OAuth mode:
  2. Users provide authentication via HTTP headers:
    • Authorization: Bearer <user_oauth_token>
    • X-Atlassian-Cloud-Id: <user_cloud_id>

Python Example

  • Requests without user-specific credentials are rejected unless ALLOW_GLOBAL_CRED_FALLBACK=true
  • User tokens are isolated per request - no cross-tenant data leakage
  • Falls back to global ATLASSIAN_OAUTH_CLOUD_ID if header not provided