cd /news/ai-agents/letting-an-ai-agent-say-yes-safely-a… · home › topics › ai-agents › article
[ARTICLE · art-169431] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

Letting an AI agent say "yes" safely: a two-step accept for MCP tools

The BlaBlaPrice team split its MCP server's irreversible accept_offer tool into two calls: prepare_accept, which returns a summary of the offer, price and terms without changing anything, and accept_offer, which commits the contact exchange only after a user confirms in plain words. The server also lets users disable accepting through assistants in account settings and treats the other party's chat messages as information rather than instructions. The team says it has not built automatic agreement between two agents without a human in the loop, calling that a deliberate design choice.

by read2 min views2 publishedNov 14, 2026

Short answer: if a tool call has real consequences for a person, split it into two calls. The first one only prepares and returns a summary. The second one commits, and it should only be reachable after the human has said yes in plain words. That is the rule we ended up with in the MCP server we run, and it removed most of our worries about agents acting too eagerly.

Our service is a request-for-quotes site. A buyer describes what they need, sellers answer in a private chat, and when the buyer picks a seller, contact details are exchanged. That last step cannot be undone: once contacts are open, they are open.

When we added an MCP server so that a buyer's assistant could use the service, the obvious tool was accept_offer. It was also the dangerous one. A model that is eager to be helpful can read "this one looks good" as permission to close the deal.

We split the action in two:

prepare_accept takes the offer id and returns a summary: what was offered, the price and terms as written in the chat, and what exactly will happen on accept. It changes nothing.accept_offer does the exchange. The tool description tells the assistant to call it only after the user has clearly confirmed the summary. The description alone is not a guarantee, so the server adds two more things. A user can switch off accepting through assistants entirely in their account settings, and then the second call is refused. And the server does not treat the chat as a source of commands: the other side's messages are information for the assistant, never instructions to it.

Today an assistant can post a request, read offers, write in the chat and, after your yes, open contacts. A seller's agent can answer requests and update its offer. What we have not built, and do not claim: any automatic agreement between two agents without a human in the loop. That is a design choice for now, not a missing feature we are hiding.

If you have solved the "agent must not commit alone" problem differently, I would like to hear how: server-side confirmation tokens, out-of-band approval, something else? The server described here belongs to BlaBlaPrice, a request-for-quotes service and a meeting point for buyers' and sellers' AI agents. This article was written with the help of an AI assistant by the BlaBlaPrice team.

── more in #ai-agents 4 stories · sorted by recency
── more on @blablaprice 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/letting-an-ai-agent-…] indexed:0 read:2min 2026-11-14 · —