OpenAI remote MCP

discord-mcp serve --http exposes a stateless Streamable HTTP MCP endpoint at /mcp. It is intended for an HTTPS reverse proxy and remote clients such as the OpenAI Responses API and Codex. The endpoint uses MCP SDK v2, negotiates stable MCP 2026-07-28, and keeps a stateless 2025-era path for current OpenAI and existing MCP clients. Local stdio remains the default transport.

Security model

This first remote deployment model deliberately keeps the Discord bot under the caller’s control. One deployment uses one Discord bot token and one shared bearer token:

• DISCORD_TOKEN authorizes calls to Discord.
• DISCORD_MCP_ACCESS_TOKEN authenticates a remote MCP client to this server.
• Every authenticated caller acts with the same Discord bot permissions. Use Discord roles, channel overrides, MCP_CATEGORIES, and confirmation controls to keep that bot’s scope small.

It is not a per-user Discord identity system and does not expose OAuth metadata or a ChatGPT connector flow. Do not distribute a shared bearer token to people who should have different Discord access.

Caution

Put this endpoint behind HTTPS before making it reachable outside the host. Terminate TLS at a reverse proxy, preserve the Authorization header, and make sure request logs redact it. The CLI defaults to 127.0.0.1 specifically so it is not public by accident.

Run the endpoint

Generate a high-entropy bearer secret of at least 32 characters and keep it separate from the Discord bot token. Then start the server on the loopback interface for your reverse proxy:

export DISCORD_TOKEN="Bot YOUR_DISCORD_BOT_TOKEN"
export DISCORD_MCP_ACCESS_TOKEN="replace-with-a-long-random-secret"
discord-mcp serve --http --host 127.0.0.1 --port 3000

Your proxy should publish https://discord-mcp.example.com/mcp and forward it to http://127.0.0.1:3000/mcp. Requests without a matching Authorization: Bearer <DISCORD_MCP_ACCESS_TOKEN> header receive 401.

The same listener exposes an authenticated GET /healthz readiness probe. It returns {"status":"ok"} after required startup checks and the HTTP listener have completed startup (including bot identity verification when DISCORD_EXPECTED_BOT_ID is configured). It applies the same bearer and loopback Host/Origin checks as /mcp; it is a process-readiness signal, not a Discord liveness check. Keep the bearer on the proxy health probe and do not publish an unauthenticated health route.

The server rejects bodies larger than MCP_HTTP_MAX_BODY_BYTES (4 MiB by default) with 413, and fast-rejects work above MCP_HTTP_MAX_IN_FLIGHT (16 by default) with 503 plus Retry-After: 1. Configure the reverse proxy with connection/header/body timeouts and a caller-aware rate limit as well; the in-process bulkhead is not a per-user quota.

The transport is stateless: each MCP request builds an isolated server runtime, with no Mcp-Session-Id. Modern clients use MCP 2026-07-28; 2025-era clients use the SDK’s stateless compatibility path. That makes independent Responses API calls safe from MCP session-state crossover and permits load balancing. Discord Gateway subscriptions are intentionally not available with serve --http; use the local stdio transport for those.

OpenAI Responses API

Pass the public HTTPS endpoint as a deferred MCP tool and add OpenAI’s hosted tool search. The model initially sees the server identity instead of all 209 schemas, then loads only the tools it needs. Keep the server itself on the default MCP_TOOL_SURFACE=full for this path: combining caller-native tool search with the server fallback would add an unnecessary second discovery step.

Keep approval enabled for this write-capable third-party server, then restrict the tool list as your workflow matures.

const response = await openai.responses.create({
  model: 'gpt-5.6',
  input: 'Summarize the latest messages in the engineering channel.',
  tools: [
    {
      type: 'mcp',
      server_label: 'discord',
      server_url: 'https://discord-mcp.example.com/mcp',
      authorization: `Bearer ${process.env.DISCORD_MCP_ACCESS_TOKEN}`,
      require_approval: 'always',
      defer_loading: true,
    },
    { type: 'tool_search' },
  ],
});

OpenAI documents tool_search for GPT-5.4 and later. It preserves the model’s cache by injecting discovered tools at the end of context and can defer a whole MCP server rather than placing every tool definition in the initial prompt. Review each tool’s risk before lowering approval or adding it to an allowlist. The Responses API does not store the MCP authorization value in the Response, so the caller must supply it on every Responses API creation request. See the official MCP and Connectors guide.

Codex and ChatGPT desktop

Codex supports remote Streamable HTTP MCP servers. Add this to the Codex configuration on the client machine, where DISCORD_MCP_ACCESS_TOKEN is set:

[mcp_servers.discord]
url = "https://discord-mcp.example.com/mcp"
bearer_token_env_var = "DISCORD_MCP_ACCESS_TOKEN"

Codex’s current MCP configuration documents tool allow/deny lists and client caching, but not a caller-side defer_loading switch. For local stdio Codex or another MCP host without native tool search, set this in the server environment:

[mcp_servers.discord.env]
MCP_TOOL_SURFACE = "progressive"
ALLOWED_GUILDS = "111122223333444455"

The model will see the direct build_discord_server, guild_blueprint_apply, and guild_blueprint_evidence architecture lifecycle when guild architecture is authorized, plus mcp_tools_search, mcp_tools_read, mcp_tools_write, and mcp_tools_destructive. The front door is a progressive alias of canonical guild_blueprint_plan; each search match for other tools names the exact dispatcher whose host-visible annotations match that tool’s risk. Searches return compact matches by default. A single match already carries its schema; for multiple matches, the model searches the chosen exact tool name before dispatching, or requests detail: "full" when it needs several contracts together. The dispatcher rejects a tool sent through the wrong risk route, then applies the same authorization and safety middleware as a direct call.

In the ChatGPT desktop app, Codex MCP servers are managed from Settings → MCP servers. Add the same HTTPS endpoint through that surface when your account or workspace makes custom MCP servers available. The bearer-token v1 here is usable from Codex configuration and the Responses API; a plug-and-play per-user ChatGPT OAuth/connector experience requires a separate OAuth design.

See the Codex configuration reference for remote MCP credentials and headers, and the OpenAI tool search guide for caller-native deferred loading.

Operating checklist

1. Use HTTPS; validate public Host/Origin; redact Authorization at the proxy.
2. Store both tokens in a secret manager, not a checked-in .env file.
3. Start with narrow ALLOWED_GUILDS and MCP_CATEGORIES allowlists plus a Discord test guild.
4. Keep OpenAI tool approval on until the workflow has been reviewed.
5. Set proxy timeouts and caller-aware rate limits; tune the server body and in-flight ceilings only from measured demand.
6. Configure an audit sink and monitor its transport: "http" events.

For the exact environment-variable contract, see Access and scope. For command flags, see the CLI reference.