Put human approval in front of risky MCP tools

An agent that can read a file may also be able to delete one. An MCP server that can inspect a database may also expose a write operation. Those capabilities are useful, but they need a boundary before an irreversible action runs.

In OpenAI Agents SDK, a practical pattern is to keep sensitive MCP operations behind a function tool that requires approval. The agent can request the action, but the function does not call the MCP server until a person approves that specific request. ZES publishes guides on OpenAI Agents SDK and MCP; the same separation is useful whether you are building from a tutorial or connecting your own server.

Separate the request from the action

Start by listing the operations the agent can reach. Mark actions that change or destroy state: deleting a file, writing a database row, sending a message, or changing an account setting. A read operation may not need the same approval gate, but decide based on the impact of its output and your environment.

Do not give the agent a direct route to a high-impact MCP tool and rely on the prompt to make it behave. Instead, expose a narrow function tool in your agent application. That function should validate the requested action, request approval, and only then call the corresponding MCP tool. Keep unrelated operations out of the wrapper.

For example, a file-deletion wrapper should accept a specific path, check that the path is within the permitted workspace, and call the MCP server only after approval. A database wrapper should name the permitted operation and target. Avoid a general-purpose function that accepts arbitrary SQL or an unrestricted filesystem path unless the application has a separate, strong reason to allow it.

Mark the tool as approval-required

With the Python Agents SDK, a function tool can be marked with needs_approval=True. When the agent requests that tool, the run pauses with an interruption rather than executing the function. Your application then presents the pending call to a human. The SDK handles the pause-and-resume flow; your application still has to provide the approval channel and decide who is allowed to use it.

Keep the approval check attached to the function that performs the MCP call. Do not ask the model to describe a planned deletion in one step and then accept a separate, newly generated deletion request in another. The reviewer should see the actual tool name and arguments the agent requested, such as the exact file path or database operation.

That distinction matters. A natural-language explanation can omit a parameter, and the model can change its request between steps. Approval should apply to the pending call, not to a broad statement like “clean up the old files.” If the arguments change, treat it as a new request and ask again.

Handle the interruption in the application

When a run returns an approval interruption, store the run state and send the pending request to a trusted reviewer. Show the operation, its arguments, and enough context to judge the consequences. Do not treat an agent-generated explanation as proof that the request is safe.

If the reviewer approves, mark that interruption approved in the SDK run state and resume the run. If the reviewer rejects it, reject the interruption and resume or end the run according to your application’s policy. The tool function should execute its MCP call only on the approved path. Keep approval records with the request, decision, reviewer, and result where your system’s audit requirements call for them.

Approval is not a reason to let a tool accept more than it needs. Use a server account with limited permissions, constrain paths or database targets in application code, and validate inputs again immediately before the MCP call. A bug elsewhere should not turn an approval step into unrestricted access.

Test the boundary, not just the happy path

Before connecting the agent to real data, test that a requested deletion pauses before the server is called. Check that rejection produces no side effect. Check that approval executes only the displayed arguments, and that changing those arguments requires a new approval. Also test malformed input, a timeout in the approval process, and a run that is abandoned while waiting.

Keep read-only tools available only where they are useful, and use a test server or disposable data while verifying the flow. The MCP Starter Kit from ZES includes five ready-to-deploy MCP servers and costs $9; whichever server you test with, confirm its available operations and permissions rather than assuming every tool is harmless.

The goal is not to put a person in the loop for every tool call. It is to make the boundary explicit: the agent can propose a sensitive action, a person can review the precise request, and the MCP server receives it only after approval.