OpenAI Responses API Remote MCP: Approvals, Filters, Tunnels

The first time I pointed the Responses API at an internal ERP MCP server, the model could see every tool the server exposed, including the ones that write stock adjustments. Nothing had gone wrong yet, but nothing was stopping it either. The MCP server was built for a desktop client where a person clicks Allow on each call. In the Responses API, that person is your code, and if you configure the tool loosely, no one is clicking anything.

This post covers the client side of the OpenAI Responses API remote MCP tool: how OpenAI reaches your server (server_url, the Secure MCP Tunnel, and the deprecated connector_id), how allowed_tools and require_approval narrow what the model can do, how to run the mcp_approval_request loop in TypeScript, and why the authorization token has to travel with every call. Every field name and behaviour comes from OpenAI's MCP guide, the tunnel guide and the typed definitions in the official Python SDK. Building the server itself is a separate topic, covered in the earlier MCP server posts on this blog.

How the OpenAI Responses API remote MCP tool works

You add a tool of type mcp to the tools array. When the model decides it needs the server, the API calls the server's tools list and records the result as an mcp_list_tools output item. When the model calls a tool, OpenAI's infrastructure, not your process, sends the request to the MCP server and records the arguments and the output in an mcp_call item. If approval is required, the call is paused and an mcp_approval_request item appears instead. These are the fields that control that behaviour:

The guide says the API works with servers that speak either Streamable HTTP or the older HTTP with SSE transport. There is no per-call fee. You pay for the tokens used to import tool definitions and for the tool calls themselves, and that is why the size of the tool list matters more than most people expect.

server_url, tunnel_id or connector_id: how OpenAI reaches the server

The key thing to understand about this tool is where the network call comes from. With function calling, your backend runs the tool. With the MCP tool, OpenAI connects to the server, so the server must be reachable from OpenAI, not just from your app. That leaves three options:

• server_url: a public HTTPS endpoint. This is the simplest option, and the right one for official servers run by the vendor, such as Stripe's own server at mcp.stripe.com, which is OpenAI's example of a trusted server.
• tunnel_id: a Secure MCP Tunnel identifier, for a server that is private, on-premises or behind a firewall. The server stays private, and a small client inside your network makes outbound connections to OpenAI.
• connector_id: the built-in connectors for Dropbox, Gmail, Google Calendar, Google Drive, Microsoft Teams, Outlook Calendar, Outlook Email and SharePoint. They still work on older models, but the field is deprecated for models released after 1 September 2026.

The connector_id deprecation will quietly break code. A request that works on gpt-5.2, the model OpenAI's legacy connector examples still use, is not guaranteed to work when you change the model string to a newer one. If you have connector_id anywhere in your codebase, the migration is to find an official remote MCP server for that service and switch to server_url, or to put your own server behind a tunnel. Do it before you upgrade the model, not as part of the same change.

Secure MCP Tunnel: reaching a server behind the firewall

Most ERP MCP servers I would connect should not be on the public internet. The Secure MCP Tunnel avoids that. You create a tunnel in the Platform tunnel settings, run tunnel-client on a host that can already reach the server, and the client long-polls OpenAI for queued MCP requests, forwards each JSON-RPC request locally and posts the response back. It needs outbound HTTPS to api.openai.com on port 443, or mtls.api.openai.com when control-plane mTLS is configured, and no inbound port at all.

# Run this inside the network that can already reach the ERP's MCP server.
# It only needs OUTBOUND HTTPS to api.openai.com:443. No inbound port opens.
export CONTROL_PLANE_API_KEY="sk-..."   # runtime API key for tunnel-client

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile erp-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-command "python /opt/erp-mcp/server.py"
# An HTTP server takes --mcp-server-url https://mcp.internal.example.com/mcp
# instead of --mcp-command.

tunnel-client doctor --profile erp-stdio --explain
tunnel-client run --profile erp-stdio
# Keep "run" alive under systemd or as a sidecar: while it is down, every
# tool call routed through the tunnel fails.

# Responses API side: tunnel_id REPLACES server_url.
# Never paste the OpenAI-hosted tunnel endpoint into server_url.
{
  "type": "mcp",
  "server_label": "erp",
  "tunnel_id": "tunnel_0123456789abcdef0123456789abcdef"
}

Before this works, two things need to be in place. The first is permissions: creating a tunnel needs Tunnels Read and Manage, while running tunnel-client or using the tunnel needs Tunnels Read and Use. These are set at the organisation level, not the project level, and the guide warns a new role can take up to 30 minutes to propagate. The second is OAuth: discovery metadata passes through the tunnel, but the authorization server itself is not tunnelled. If your identity provider is reachable only on the internal network, the OAuth flow can fail even when the MCP server is reachable. The guide suggests running the client as a Kubernetes sidecar next to the server, as a separate deployment, or as a systemd service on a VM.

allowed_tools: shrink what the model can see

allowed_tools is the most effective control in this tool, and it costs nothing to set. A tool that is not on the list is never imported, so the model cannot call it, cannot be tricked into calling it, and you do not pay tokens for its definition. OpenAI's guide notes that exposing many tools adds cost and latency. My rule is simple: list the tools by name, read-only ones first, and add a write tool only when there is a real feature that needs it.

The filter form, an object with tool_names and read_only, is convenient, but read_only works by matching the server's readOnlyHint annotation. The MCP specification says clients must treat tool annotations as untrusted unless they come from a trusted server. A third-party server that labels a delete tool as read-only would get through that filter. For a server you did not write, use explicit names. For your own server, read_only is fine because you control both the code and the annotation.

For servers with a long tool list, defer_loading set to true is the other option. It works together with tool search: the model sees the server label and description, and loads individual function definitions only when it decides to search that server. This saves tokens, but it does not limit anything. A deferred tool can still be called, so defer_loading is a way to reduce cost, not a security control, and you still need allowed_tools.

require_approval: never, always, or a filter

By default, OpenAI asks for approval before any data is shared with a remote MCP server, so leaving require_approval out gives the safest behaviour. The string never skips approvals for every tool on that server. The object form takes a never key, an always key, or both, and each one holds tool_names and optionally read_only. OpenAI's own example skips approval only for named read tools. This is the builder I use, so the policy is computed in one place and cannot drift:

import type OpenAI from "openai";

type McpTool = OpenAI.Responses.Tool.Mcp;

// Tools I have read the server code for and know only run SELECTs.
const READ_ONLY = ["get_stock_level", "get_sales_order", "list_open_invoices"];
// The one write the model may propose. A person approves every call.
const WRITES = ["draft_stock_adjustment"];

// Wrong: if READ_ONLY ever ends up empty (a typo, a feature flag), a
// community bug report says an empty "never" list produced NO approval
// requests at all, the opposite of what the object appears to say.
const wrongPolicy: McpTool["require_approval"] = {
  never: { tool_names: READ_ONLY },
};

// Right: fall back to the string form, which has only one meaning.
function approvalPolicy(skip: string[]): McpTool["require_approval"] {
  return skip.length > 0 ? { never: { tool_names: skip } } : "always";
}

export function erpMcpTool(accessToken: string): McpTool {
  return {
    type: "mcp",
    server_label: "erp",
    server_description:
      "Stock levels, sales orders and open invoices for the Jakarta warehouse.",
    server_url: "https://mcp.erp.example.co.id/mcp",
    // Not stored by the API and not echoed in the Response object,
    // so it has to be sent again on every single create call.
    authorization: accessToken,
    // Anything else the server exposes is never shown to the model.
    allowed_tools: [...READ_ONLY, ...WRITES],
    require_approval: approvalPolicy(READ_ONLY),
  };
}

The model sees four tools and can run three of them without waiting. The fourth, the write, always comes back to my code as an approval request. Combined with allowed_tools, this gives two separate limits: what the model knows exists, and what it can run without a person. OpenAI's risk section recommends exactly this: use require_approval and allowed_tools together so that every sensitive action goes through an approval flow.

The approval loop: from mcp_approval_request to mcp_approval_response

An approval request is not an error and not a callback. It is an output item with an id, the server_label, the tool name and the arguments as a JSON string. To answer it, you create a new response that references the old one with previous_response_id and sends an mcp_approval_response item with approve set to true or false. The SDK type also has an optional reason field. This is the loop, with the audit logging I would not ship without:

import OpenAI from "openai";
import { erpMcpTool } from "./erp-mcp-tool";
// tokens, audit and reviewer are your own modules: an OAuth token store,
// an append-only log, and whatever decides (a person, or a rule you wrote).
import { tokens, audit, reviewer } from "./erp-agent-deps";

const client = new OpenAI();
const MODEL = "gpt-6-astra";
const MAX_APPROVAL_ROUNDS = 3;

export async function askErp(userId: string, question: string) {
  let response = await client.responses.create({
    model: MODEL,
    tools: [erpMcpTool(await tokens.forUser(userId))],
    input: question,
  });

  for (let round = 0; round < MAX_APPROVAL_ROUNDS; round++) {
    const decisions: OpenAI.Responses.ResponseInputItem.McpApprovalResponse[] = [];

    for (const item of response.output) {
      if (item.type !== "mcp_approval_request") continue;
      // item.arguments is the exact JSON the MCP server will receive.
      // Approve the payload, not the tool name.
      const args = JSON.parse(item.arguments);
      await audit.log({ userId, server: item.server_label, tool: item.name, args });
      const approve = await reviewer.decide(item.name, args);
      decisions.push({ type: "mcp_approval_response", approval_request_id: item.id, approve });
    }
    if (decisions.length === 0) break; // nothing pending: the answer is final

    response = await client.responses.create({
      model: MODEL,
      previous_response_id: response.id,
      // The token from the first call is gone. Resend it, refreshed if needed.
      tools: [erpMcpTool(await tokens.forUser(userId))],
      input: decisions,
    });
  }

  // A failed call does not throw: it lands in the item's error field.
  for (const item of response.output) {
    if (item.type === "mcp_call" && item.error) {
      await audit.log({ userId, tool: item.name, error: item.error });
    }
  }
  return response.output_text;
}

Each part of that loop is there for a reason:

1. Parse and log item.arguments before deciding. That string is exactly what the server will receive, so it is what you are approving. Deciding by tool name alone approves whatever payload the model produced.
2. Answer every pending request in the same follow-up call. A single response can contain several MCP calls, and an unanswered request leaves that call unexecuted.
3. Rebuild the tools array on the follow-up call, including the authorization token. The token never carries over from the earlier response, and OpenAI's own approval example passes the full tool definition again.
4. Limit the number of rounds. A model that keeps proposing writes after rejections should end with a message to the user, not loop until your timeout. Failed calls do not throw: they appear in the error field of the mcp_call item, so check for them explicitly.

OAuth tokens per request, and what headers is for

The guide is explicit: the Responses API does not store the value of authorization, the value is not visible in the Response object, and you must send it with every create request. This is deliberate, because a token that is never stored cannot leak from a stored response. In practice, every follow-up call in the approval loop needs a valid token, so your token store has to refresh it between rounds. A person approving a write can easily take longer than a short-lived token lasts.

The headers field, an optional map of HTTP headers that the SDK types describe as being for authentication or other purposes, is for servers that expect something other than a bearer token, such as a tenant id or an API key in a custom header. I use it for non-secret routing values only. The no-storage guarantee in OpenAI's guide is written for the authorization field, and I would rather not assume it also covers headers.

Reading the output items: caching, cost and where data goes

Keep the mcp_list_tools item in context. The guide says that as long as it is present, the API does not fetch the tool list from the server again on each turn, and OpenAI recommends keeping it for every conversation to reduce latency. previous_response_id handles this automatically. If you manage context yourself, for example with store set to false, you have to pass that item back as input, or you pay the import latency and tokens again on every turn.

On data: with store set to true, the data sent to MCP servers is already logged by the API for 30 days unless Zero Data Retention is enabled, and the guide still recommends keeping your own log. The MCP tool works with Zero Data Retention and data residency, but those guarantees end where the MCP server begins. Data sent to the server follows the server's own retention and residency policies. For an Indonesian company with data-location requirements, the tunnel setup helps here, because the server and its database stay on your own infrastructure. Also treat URLs returned in mcp_call output as untrusted. The guide warns against fetching or embedding them unless you trust the domain, because requesting an attacker-chosen URL is itself a way to leak data.

The rule I follow now: the MCP tool should be configured for the least trust that still works. Use explicit allowed_tools names, use the never filter only for tools whose code I have read, use the string always instead of an empty list, approve the arguments rather than the tool name, and send a fresh user-scoped token on every call. The tunnel keeps private servers private. Everything else is code that has to be written on purpose.