This guide was prepared with AI assistance using the linked documentation. Code examples are illustrative; verify them against your environment and current API documentation before use.
Start with the action, not the server
An MCP server may expose a harmless document lookup alongside tools that change records. Approving the connection without inspecting the available tools makes it hard to tell what the agent can actually do.
Inventory the methods, data they can read, and actions they can take. Assign an owner and decide which user or service identity will authorize each call.
Understand connection choices
OpenAI's Responses API supports remote MCP servers and Secure MCP Tunnel for connecting local or private servers. The provider documentation describes how to list and filter available tools and handle approval requests.
A public endpoint and a privately connected server have different network exposure, but both need authentication and a review of the data they can access. Verify the server operator and its deployment before connecting production data.
Set approvals by risk
Read-only lookup, a draft update, and an external payment do not have the same consequences. Decide which operations can run automatically, which need a reviewer, and which should not be exposed to the agent at all. The Responses API supports approval configuration; consult the current guide for the exact request shape.
An approval should describe the intended action and relevant arguments. After a reviewer approves, validate that the executed call is still the same one and that the user's access is current.
Filter the tool set
Expose a narrow set of methods for a given task. If the agent only needs to find a policy, omit tools that update the policy or send messages. Limit the credentials used by the server itself.
This example is an application-level allowlist, not an MCP client implementation. Your service must still check identity, argument values, and approval state.
const allowedForPolicySearch = new Set(["search_policies", "get_policy"]);
function isAllowedTool(toolName: string): boolean {
return allowedForPolicySearch.has(toolName);
}Expect untrusted tool results
A tool response can contain user-generated or external text. Treat it as data, even if it arrives through a trusted connection. Do not let a retrieved instruction expand permissions, change an approval requirement, or determine which secrets are sent elsewhere.
Record enough metadata to investigate calls while avoiding sensitive payloads in logs. Decide how long logs and approvals remain available and who can inspect them.
Exercise the approval path
Test an allowed lookup, a denied tool, an approval rejection, an expired approval, and an attempted argument change after approval. Also test revocation while a session is open.
Your release checklist should include a rollback or disable switch for the connection. If you cannot identify the responsible server owner or permission scope, keep the integration out of production.
Walk through a read and a write
Suppose a policy assistant has a `search_policies` method and a separate `publish_policy` method. The search workflow can expose the first method to an authorized reader. Publishing needs a different permission and an explicit approval process defined by the application.
Before requesting approval, show the reviewer the document, proposed change, and destination. Bind the approval to that specific operation and its arguments. If the document, destination, identity, or permissions change before execution, the application should recheck and obtain whatever approval its policy requires.
An approval response is not a replacement for access control at the MCP server. The server should still verify that the authenticated principal can execute the method when the call arrives. Treat a refusal or expired approval as a normal outcome the assistant can explain to the user.
Operate and retire the connection
Maintain a short inventory with the server owner, endpoint, exposed methods, credential scope, approval policy, and incident contact. Review it when the server adds a method or changes its permissions. Tool discovery is useful, but newly discovered methods should not automatically enter every agent's allowed set.
Test a compromised or unavailable server in a non-production environment. A malformed response should not be treated as a developer instruction, and an outage should not make the agent claim that a write completed.
When retiring a connection, disable its use, revoke credentials through the relevant owner, and check that background sessions can no longer call it. Keep only the audit material required by your retention policy. A rollback plan should identify who can disable access and how quickly it takes effect.
Sources and further reading
Documentation reviewed November 9, 2026. Verify current model support, limits and pricing before implementation.
