MCP with ChatGPT and the OpenAI API: Remote Servers, Safely

An MCP server answers JSON-RPC 2.0 requests. For tools, the two methods that matter are tools/list, which returns each tool's name, description, and JSON Schema for its input, and tools/call, which runs one. Servers can also expose resources (read with resources/read) and prompt templates.

The current specification defines two standard transports:

• stdio: the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages over stdin and stdout. This is how local tools run in Claude Code or Gemini CLI.
• Streamable HTTP: the server is an independent process with one endpoint (for example https://example.com/mcp) that accepts POST and GET, optionally streaming with server-sent events. It replaced the older HTTP+SSE transport from the 2024-11-05 protocol version.

Hosted products such as ChatGPT and the Responses API connect to your server over the network, so the server must be reachable over HTTPS. A stdio server on your laptop is not reachable by them unless you put it behind a tunnel or redeploy it as a Streamable HTTP service. WebSockets are not one of the standard transports.

In ChatGPT, a custom MCP server is added through its plugin interface. As of OpenAI's current quickstart (checked October 2026), the flow is:

1. Open the plugins page in ChatGPT, select the plus button, and choose Add custom MCP server.
2. Enter a name and the server URL (your HTTPS MCP endpoint), and choose the authentication the server uses.
3. Read and confirm the risk warning, then create it as a plugin.
4. Install it from your personal plugins, start a chat in the mode the quickstart names, type @, and select your plugin.

Test it the way the quickstart suggests: ask for something that should call exactly one tool with specific arguments, then try invalid inputs and requests that should not trigger the tool at all. The second half catches the more common failure, a tool called when it should not be.

Because this part of ChatGPT keeps changing (earlier versions called these connectors and apps, and access has varied by plan), check OpenAI's current plugin documentation before writing internal instructions for your team.

For your own applications, the OpenAI Responses API accepts an MCP server as a tool of type mcp:

1{2  "model": "<model>",3  "tools": [4    {5      "type": "mcp",6      "server_label": "docs",7      "server_url": "https://example.com/mcp",8      "allowed_tools": ["search_docs", "get_page"],9      "require_approval": "always"10    }11  ],12  "input": "Find the rate-limit section and summarise it."13}

What happens on a request, according to OpenAI's guide:

• The API imports the server's tools and adds an mcp_list_tools item to the output. While that item stays in context, the tool list is not fetched again each turn. allowed_tools limits what is imported.
• Before data is shared with the server, the API by default produces an mcp_approval_request item. Your application answers with an mcp_approval_response item in the next request. require_approval can be set to "never" or to an object that skips approval only for named tools.
• Each tool invocation creates an mcp_call item recording the arguments and output.

For authenticated servers, pass an OAuth access token in the tool's authorization field. The API does not store it, so you send it on every request. The API supports servers using Streamable HTTP or the older HTTP+SSE transport, and a secure tunnel option for private servers.

OpenAI's own guide is direct about remote MCP servers:

• Exfiltration. A malicious server can exfiltrate sensitive data from anything that enters the model's context, not just what you send it explicitly.
• Unverified servers. Remote servers have not been verified by OpenAI. Prefer official servers hosted by the service provider (OpenAI's example is Stripe's own server) over third-party aggregators.
• Prompt injection. Malicious servers may include hidden instructions, in tool descriptions or in tool output, that try to redirect the model.

The controls follow: keep require_approval on for sensitive actions, use allowed_tools, and log the data sent to MCP servers. On your own server, apply least privilege: read-only database roles for query tools, OAuth scopes limited to what each tool needs, rate limits, and an audit log of every tools/call with the caller's identity.

A query tool that accepts raw SQL deserves special care. Even against a read replica, it can read any table the role can, and the model may construct queries you did not anticipate. Prefer narrow tools (get_order(order_id)) over general ones (query_database(sql)), and enforce limits in the server, not in the description.

1. Build a minimal MCP server with one read-only tool (for example lookup_status(order_id)) using an official MCP SDK, served over Streamable HTTP at /mcp. Validate the Origin header and require a token.
2. Expose it over HTTPS (a deployed service or a tunnel).
3. Call it from the Responses API with type: "mcp", allowed_tools: ["lookup_status"], and require_approval: "always". Handle the mcp_approval_request in a small script and approve it.
4. Add the same URL as a custom MCP server in ChatGPT and invoke it with @.
5. Try a prompt that should not call the tool, and one with an invalid order ID.

Pass criterion: both clients called the same server, your script saw and answered an approval request, and the tool refused the invalid input with a clear error rather than guessing.