---
title: OpenAI MCP Tool Approvals for Customer AI Agents | Remqa
url: https://remqa.com/blog/openai-mcp-tool-approvals
updated: 2026-11-05
---

[Home](https://remqa.com/) / [Blog](https://remqa.com/blog) / OpenAI MCP Tool Approvals for Customer AI Agents

FDE implementation

# OpenAI MCP tool approvals: a rollout guide for customer AI agents

Build OpenAI Responses API MCP approvals around exact tool arguments, customer permissions and private data sharing before enabling consequential actions.

Remqa · November 5, 2026 · 5 min read

**Short answer:** For MCP tools in the OpenAI Responses API, use require_approval to control approval requests and allowed_tools to restrict the tools imported into a request. Review the requested tool and arguments before returning an mcp_approval_response. Keep customer authorization and execution checks in your application and server, because tool filtering and approval do not replace them.

- MCP approval can protect data sharing as well as actions that change records
- Each approval applies to one tool call, not the whole customer workflow
- An imported tool allowlist does not replace server authorization
- Recheck the exact target and arguments before an approved action executes

By the Remqa engineering team · Last updated November 5, 2026

A customer approves an agent's plan to update one CRM record. The next tool call targets a different account with a larger set of changes. A generic approval banner cannot tell the operator whether the action still matches the plan. Before a customer rollout, define exactly what approval covers, what data leaves the application and which checks run at execution.

## Start with the Responses API approval boundary

OpenAI's Responses API supports MCP tools that connect a model to external servers. Its guide describes approval as the default before data is shared with a remote MCP server. The require_approval setting controls that flow. The values always and never make the distinction explicit, and selective configuration can skip approval for named tools.

These are Responses API controls, not a promise that every MCP client or every agent framework has identical behavior. Check the API, model and integration your product actually uses. The workflow controls below are recommended application design, not features automatically supplied by a protocol connection.

| Control | What it addresses | What still needs application logic |
| --- | --- | --- |
| allowed_tools | Which server tools are imported | Who can access each customer record |
| require_approval | Whether a call needs approval | Who may approve and what the screen shows |
| mcp_approval_response | Response to a particular approval request | Stale state, changed targets and customer policy |
| Server authorization | Access enforced at the destination | Correct customer context and scope selection |

## Filter tools before the model chooses an action

The allowed_tools parameter limits which tools are imported from a server. Use it to present the smallest set needed for the task. A support assistant searching documentation does not need a tool that deletes customer records. Keeping that tool out of the request makes the intended scope easier to review and test.

Do not mistake the import filter for server authorization. Your backend should still verify the authenticated customer, acting user and permitted resources. A record identifier supplied by a model is a proposed target. Resolve and authorize that target through trusted application context rather than trusting the identifier alone.

## Treat private reads as data sharing

A tool does not need to write data to cause a disclosure. A search query sent to a remote server might contain a candidate's email, an internal document excerpt or customer account details. Review what leaves the model request and who receives it. A read-only label says little about whether those arguments are appropriate.

OpenAI recommends separating public research from private record access. For example, gather public facts in a request that has only public search available. Pass the relevant facts into a separate request limited to internal retrieval. Your implementation should avoid carrying private records into later public searches or URLs.

> **Approve the data transfer, not just the verb.** A search of public documentation and a search containing confidential customer details can use the same tool name while creating very different risks.

## Build the approval screen around exact arguments

When approval is requested, the Responses API returns an mcp_approval_request item with the tool name, server label and arguments. Review the requested tool and arguments before continuing. The application responds with an mcp_approval_response that references the returned approval request identifier. OpenAI describes each approval as applying to one tool call.

For customer use, translate the arguments into an operator-readable preview without hiding important fields. Show the destination service, customer, target record and proposed change. For a data-sharing action, show the categories of information being sent and the receiving server. Keep the underlying arguments available for a technical reviewer where appropriate.

Bind your own approval record to the acting user and exact proposed operation. If the target or arguments change, request fresh review. A general instruction to finish onboarding should not silently become permission to perform every tool action that might help.

## Recheck state when approval is used

An approval can sit in a queue while the underlying record changes. Add an application policy for expiration and stale state. Before execution, confirm that the reviewer remains authorized and that the destination record still matches the approved operation. If another user changed the relevant fields, show the difference rather than overwriting it unnoticed.

Keep this check in the execution path. A review screen that validates the target but a worker that later accepts arbitrary arguments leaves a gap. Test the actual handoff between the approval event and the server action, including delayed jobs and restarted workers.

## Handle denied and uncertain calls deliberately

A denied action should stop that proposed operation. Give the user a clear result and a way to revise the request. Do not ask the model to find a different tool that achieves the same rejected outcome. Log the decision using record identifiers and redacted arguments rather than copying sensitive payloads into general support logs.

A connection error after a write attempt can leave an uncertain result. Before retrying a consequential action, reconcile destination state through an authorized read or an operation record your integration maintains. Approval does not make a duplicate write safe. Our [AI agent runbook guide](https://remqa.com/blog/ai-agent-runbook-handoff) covers the ownership and recovery work that follows deployment.

## Run a customer-specific approval test

1. Confirm that only the intended tools are imported into the request.
2. Request a sensitive action and inspect the exact approval item and customer-facing preview.
3. Deny the action and verify that the destination remains unchanged.
4. Change the target after review and confirm that your application requires fresh approval.
5. Remove the acting user's permission before execution and verify that the action is blocked.
6. Simulate a delayed or uncertain result and check reconciliation before any retry.
7. Inspect outgoing read arguments for private information sent to an unintended server.

Write down the observed result for each case. These checks should be part of [customer acceptance testing](https://remqa.com/blog/ai-agent-acceptance-testing), not a screenshot of a confirmation dialog. Use an agreed test setup and records that will not disrupt real customer work.

## Common rollout mistakes

- Copying require_approval never from a public documentation example into a private workflow.
- Approving a plan while hiding the tool's actual destination and arguments.
- Treating allowed_tools as a customer access-control system.
- Keeping one approval valid after the record or proposed action changes.
- Retrying an uncertain write because the earlier call had approval.
- Recording full private payloads in logs without a defined access and retention policy.

## How Remqa helps with MCP customer rollouts

Remqa provides [forward deployed engineers](https://remqa.com/forward-deployed-engineers) for AI integrations and customer implementations. Work can include a narrow tool surface, approval screens, execution checks and tested recovery paths. Bring one real customer task and the systems it touches. The first design decision is which calls can run automatically and which need a person to see the exact operation.

## Questions people ask.

**Q: Does OpenAI require approval for remote MCP calls?**
The Responses API MCP guide describes approval as the default before data is shared with a remote MCP server. The require_approval configuration can require approval or skip it. Review the actual configuration used by your application.

**Q: What is the difference between allowed_tools and require_approval?**
allowed_tools filters the server tools imported for the model to use. require_approval controls the approval flow for calls. Neither is a replacement for authorization enforced by your application and the destination server.

**Q: How does an application approve an MCP tool call?**
An approval request appears as an mcp_approval_request output item. Review its tool, server and arguments, then send an mcp_approval_response referencing the approval_request_id. Each approval applies to one call.

**Q: Can read-only MCP tools expose private information?**
Yes. A read tool can receive a query containing private customer information, which shares that input with its server. Review the data sent to the server, not just whether the tool changes records.

**Q: Should all customer MCP tools use require_approval never?**
No. A public documentation search and a customer data export have different consequences. Define a narrow policy for each tool and data flow, and retain approval for sensitive actions and sharing.

Book a free 30-minute call with an engineer: https://calendly.com/meghanaj-connect/30min