Why not let the MCP client ask for confirmation instead?

Client confirmations depend on each person's settings and can be switched off. They also show the approval to the same person who asked. A server-side approval holds for every client and puts the decision with someone else.

Do approvals slow everything down?

Only for changes. Reads, searches and calculations run directly. Most questions in a company are reads, so approvals touch a small share of calls.

What stops an approved request from running twice?

Each approved call carries the idempotency key orgrelay-approval- . Connectors must execute a given key only once, so a network retry cannot double a refund or a stock change.

Human-in-the-loop for MCP

An AI agent with write tools will eventually call one at the wrong moment. A human checkpoint stops that, but only if it is designed properly. Many approval prompts are approved without being read. This page describes how OrgRelay places the checkpoint so it means something.

The mechanics for connector developers are on approvals and write tools. This page is the reasoning behind them.

Where the approval lives

There are three places to put a human checkpoint in an MCP setup:

Place	Strength	Weakness
The MCP client asks "allow this tool?"	Built in, no work	Depends on each person's settings; the asker approves their own request
The MCP server refuses writes unless a flag is set	Simple	All or nothing; no record of who decided
A separate approval step between agent and system	Decided by the owner or a named approver; consistent for every client; recorded	Needs an approval queue and a way to execute later

OrgRelay uses the third. The agent can only propose, with create_approval_request or by calling a write tool that becomes a request. Nobody can approve through MCP, because no tool for approving exists. The owner or a designated approver decides in OrgRelay's web or mobile app.

What makes an approval meaningful

A common objection is that approval prompts become theatre: people click "yes" to make the prompt go away. That happens when the approver cannot tell what they are agreeing to. OrgRelay's approval requests are built to avoid it:

One action per request. "Cancel order SO-1002", not "run these 14 steps".
Exact arguments. The approver sees the system, the tool and every parameter, for example refund: true, restock: true.
A named requester. Who asked, from which client, in which department.
An accountable person decides. Only the owner, or approvers the owner has named for that kind of request, can decide. An ordinary employee who asked cannot approve it.

Connector developers help by writing tool descriptions and result messages a person can understand. The connector spec has examples.

Re-check at execution time

Time passes between approval and execution. OrgRelay re-checks the requester's permissions when it executes. If access was revoked in the meantime, the request fails without calling the system. Connectors re-check the record's state too: an order approved for cancellation that shipped in the meantime returns conflict. Both checks are required by the security requirements.

Make execution safe to retry

Every approved call carries orgrelay-approval-<approval id> as its idempotency key. Connectors execute a key once and return the first result on repeats. Without this, a timeout followed by a retry could refund a customer twice. The self-test tool checks it with --write.

Avoid approval fatigue

If everything needs approval, nothing gets read. Keep approvals for changes:

Reads run directly. Searching documents, querying tables, listing orders.
Writes wait. Prices, stock, orders, journal entries, emails to customers, announcements.
Owners switch off write tools nobody needs. Fewer tools, fewer requests. See enterprise MCP patterns.
Mark tools honestly. A tool that only searches should be read, even if it uses POST. Over-marking writes creates noise; under-marking is dangerous. For vendor servers without annotations, OrgRelay assumes write, as explained on third-party MCP.

Examples from real connectors

Connector	Write tool	What the approver sees
WooCommerce	`orders.update_status`	The order and its new status
Stripe	`finance.refund`	The payment, amount and reason
QuickBooks Online	`finance.create_invoice`	Customer, lines and amounts of the invoice
Odoo	`purchase.create`	Supplier, lines and quantities of the purchase order
Salesforce	`customers.update_deal_stage`	The opportunity and its new stage

For buyers

Business owners usually care less about the protocol and more about the outcome: nothing changes in the company's systems without someone accountable saying yes. That is described in business terms on orgrelay.com's approvals page.

Common questions

Why not rely on client confirmations? They depend on each person's settings and let the asker approve themselves.

Do approvals slow things down? Only changes. Reads run directly.

What stops double execution? The idempotency key on every approved call.

Implement it: approvals and write tools, MCP transport.
Connect clients: Claude Code, Codex.
The rules a connector follows for write tools: connector spec.
Keep tokens and credentials tight: authentication.

Quickstart: run a template and pass the self-test in 15 minutes.
MCP overview: OrgRelay as an MCP server for staff.
Code templates: download the developer kit and four templates.
Standard tools: recommended tool names for 14 business domains.
Events: signed event push for new orders and alerts.
OpenAPI import: turn an OpenAPI or Swagger file into tools.

Human-in-the-loop for MCP

#Where the approval lives

#What makes an approval meaningful

#Re-check at execution time

#Make execution safe to retry

#Avoid approval fatigue

#Examples from real connectors

#For buyers

#Common questions

#Next

#Related pages