A public library wants its AI assistant to query an external catalog service for shelf availability. A visitor may mention a patron account or a personal borrowing history while asking for a book. In OpenAI Responses API, a remote MCP tool call can require an explicit approval step before data is shared. This guide explains the approval protocol and an additional application-level privacy boundary. The catalog, requests and output examples are hypothetical and no real account information is processed.
Define what catalog questions the assistant may answer
Separate public bibliographic questions from private patron questions. Searching title, author or public edition metadata is different from checking someone’s loans, holds or account identity. Give the assistant only the minimum tools needed for a public search. Where a catalog provider also offers account updates, do not expose those tool names to the public-facing workflow by default.
Document the MCP server operator, domain, authentication method, expected data sent and allowed tool list. A server advertising a read-only search tool still needs appropriate trust assessment. A tool description is not a security guarantee. Enforce authorization on the catalog API itself; an approval dialog cannot replace server-side access checks.
Understand the default remote MCP approval boundary
OpenAI documents remote MCP support through the Responses API and an approval flow before sharing data with an external server. When an invocation requires approval, the response can contain an mcp_approval_request item with its request ID, server label, tool name and serialized arguments. This is a proposed tool call, not evidence that the remote service has been contacted successfully.
The developer can configure require_approval for all tools or selected tools, and can limit which tool names are exposed. Avoid using a blanket never-approve configuration for unknown third-party services merely to improve latency. In a library kiosk, keep approval on calls that might carry visitor information. Use the provider documentation to confirm the current options supported by the chosen model and integration.
Inspect serialized arguments before continuing
Parse the approval request arguments as structured data and validate them against a strict schema. Reject account numbers, personal addresses, authentication tokens and instructions outside the public catalog scope. Check that the proposed tool name and server label correspond to the preapproved service. A harmless-looking title query can still carry private data embedded in a free-text parameter.
A reviewer or trusted application policy should see a minimal summary of what would leave the system, such as “search title: Community Repair Handbook.” If the query contains a private borrowing record, ask the user to use the authenticated library portal instead. Do not echo the sensitive content back into analytics, error logs or a second MCP request while attempting to sanitize it.
Approve or deny the specific call, not the whole session
An approval response is associated with a particular approval-request ID. OpenAI documents sending an mcp_approval_response item with that ID and a boolean approve value, commonly chained with previous_response_id. This allows the application to continue after a decision without pretending the proposed call already happened. Check each new request independently because a later tool invocation may have different arguments.
Keep denial behavior useful. If the request is outside scope, explain that the assistant can search public catalog records but cannot access patron history in this channel. Do not create an alternate route that silently makes the rejected call with different tool credentials. Record the decision reason without storing the full private query wherever possible.
Contrast automatic calls with reviewed lookup states
The comparison graphic shows three conceptual states: an unreviewed external call, a paused approval request and a permitted public title search. It is not a screenshot of an OpenAI API trace or proof of a measured privacy improvement. A pending approval should be visually distinct from an executed query. Do not display a book as available until a valid catalog result actually confirms its state.
For a synthetic visitor query, test a public title and a private borrower account as separate cases. The first may be eligible for a narrowly scoped read-only tool; the second should not leave the kiosk for an external MCP server without appropriate authentication and consent. Record the expected mcp_approval_request and final handling for both cases in a regression fixture.
Use multiple layers of protection against injected instructions
Catalog metadata returned by external tools is untrusted content. A book description, search snippet or third-party page can contain instructions telling the assistant to call a different tool or disclose data. Treat such text as reference material, not as a new system message. Constrain tool routing in the application and filter outbound arguments before approval.
Approval is a chance to inspect what leaves your system, not a universal defense against prompt injection. Keep secrets out of model-visible prompts when possible. If an MCP server can invoke a broad set of tools, explicitly restrict allowed tools and assess the host organization. Distinguish public metadata retrieval from privileged inventory updates and patron actions.
Run a concrete approval quality checklist
The verification illustration emphasizes the server destination, outbound arguments, sensitive-field handling and call-by-call approval. Test that a server-label mismatch is rejected, a private field is denied, and an ordinary title search completes only after a valid approval. Simulate a malformed arguments object and ensure the system fails safely rather than accepting the request by default.
Also test an interrupted session and a repeated approval ID. State transitions should be idempotent in the surrounding application, avoiding duplicate catalog calls where they matter. Compare the actual response trace and audited tool invocation with what the UI tells the visitor. Never report a confirmed catalog lookup merely because the model intended to call the tool.
Deploy a constrained public-search experience
Start with a small list of trusted read-only operations and synthetic queries. Assign an owner to review server changes and tool definitions. Monitor denied requests and false blocks without retaining unnecessary personally identifying information. Provide a human librarian fallback for difficult catalog questions or inaccessible kiosk workflows.
MCP approval is valuable because it creates a visible decision before external tool data sharing. It does not grant authorization to access private records, guarantee server integrity or establish that returned facts are current. A sound implementation combines explicit approval, independent API permissions, minimal data, trustworthy sources and transparent visitor communication.
How We Research
For this November 2026 editorial review, we consulted official vendor references: OpenAI remote MCP guide; OpenAI Responses create reference; OpenAI tools guide. We mapped feature scope, input/output rules, failure conditions and developer guidance to a hypothetical community-service scenario. We did not execute paid API requests, upload private personal data, publish a real catalog record, run a security attack or measure service performance. The diagrams show original educational examples, not screenshots or recorded service results. Documentation, permissions, regional availability and service configuration can change; verify them in the current official reference and an authorized test before deployment.
Frequently Asked Questions
No. It is a pending proposed invocation that requires a decision under the configured policy.
The developer can configure some or all tools not to require approval, but sensitive external calls should retain appropriate safeguards.
It should not. Expose only permitted tools and enforce account authorization on the underlying library system.
No. Review each new approval request and its current arguments independently.
No. They are teaching illustrations and do not claim an actual MCP server was contacted.