OpenAI MCP integration

OpenAI MCP and Codex: Connect Remote MCP Servers to OpenAI Tools

Understand the different MCP paths across Codex, ChatGPT-hosted connections, and the Responses API before configuring a remote server.

10 min readEducational field noteReviewed 2026-08-26
For
OpenAI developers and Codex users connecting an MCP server to a coding, agent, or API workflow.
Problem
OpenAI MCP documentation spans different host and API surfaces, so a configuration that works in Codex is not automatically the same as a Responses API tool definition or a ChatGPT connection.
Useful outcome
Choose the right OpenAI MCP surface, configure the smallest useful connection, and keep credentials, approvals, and data handling explicit.

The route

Name the OpenAI surface before you name the server.

Codex configuration, ChatGPT remote MCP tools, and API-level MCP integrations share concepts but have different setup and policy boundaries.

Step 01
Connect
Choose the client and transport
Step 02
Authorize
Review scope, credentials, and approvals
Step 03
Call
Use the smallest useful tool route
Step 04
Verify
Inspect the result and recover exceptions
Codex configuration, ChatGPT remote MCP tools, and API-level MCP integrations share concepts but have different setup and policy boundaries.

Workflow context: Codex / OpenAI API / Responses API / Remote MCP / OAuth / Bearer auth

Separate the three connection contexts.

Codex can connect to local and remote MCP servers through its client configuration and expose them to a coding workflow. ChatGPT can use remote MCP-backed tools through supported product surfaces. The Responses API can include MCP tools as part of an API request, where the application owns the surrounding orchestration and data policy.

These are related but not interchangeable. The host, configuration file, credential flow, approval behavior, and data retention path can differ. Start the article by naming which surface each example addresses so a reader does not copy a valid command into the wrong environment.

Connect a remote server with a narrow contract.

Choose a read-only or easily verified tool for the first call. Confirm the endpoint, authentication method, resource audience, scopes, and server instructions. For Codex, review the active MCP configuration and available tools before asking the agent to act. For API usage, make the tool definition and application-side approval policy visible in code.

Do not store a broad personal credential in a shared project configuration. Use environment variables or the documented OAuth flow, keep secrets out of prompts and logs, and decide whether the remote server receives user data, source code, or customer records.

  • Use a separate credential for development and production.
  • Review available tools before enabling write-capable actions.
  • Treat the remote server as a third-party data processor.

Verify the tool result and the approval boundary.

A successful connection only proves that messages can move. Test the tool with a known input, inspect the returned evidence, deny an action that should require review, and simulate an expired or insufficient credential. If the server's result is used in a later action, keep the verification step visible.

For coding workflows, distinguish reading a repository, proposing a change, and writing or publishing a change. For API workflows, distinguish model-selected tools from application-approved actions. The server should enforce its own permissions even when the host adds a second approval layer.

Document the exact surface and date reviewed.

OpenAI and Codex capabilities evolve, so record which documentation, client version, and configuration shape the guide was checked against. Avoid promising support for a product or transport that is only available in a particular surface or plan.

A durable integration article explains the invariant: MCP connects an OpenAI host or API to an external capability, while the host and application still own trust, approval, and data decisions.

Reference material

Start with the platform documentation.

This field note is an educational guide. Platform behavior, availability, permissions, and plan limits should always be checked against the current vendor documentation.