MCP server: in-conversation approval (surface 'ask the human' through the chat)

[nmrtn]

Problem

Through the MCP transport, blacktea can currently only auto-approve or reject. The two human-approval channels both break in an MCP context:

• approval: "console" writes the prompt to stdout, which corrupts the JSON-RPC stdio stream the MCP transport owns.
• approval: "callback" needs onApprovalNeeded, which the MCP server doesn't wire (and can't sensibly wire — there's no human function to call from inside a spawned subprocess).

So the "ask the human first" flow — the entire middle tier of the policy model — is unavailable exactly where it's most natural: a chat interface where the human is sitting right there.

Evidence (live test, 2026-05-28)

Tested blacktea-mcp inside Hermes Agent on a real server. Asked the agent to fetch a paid endpoint. Policy auto-approved only under $0.001; the endpoint charged $0.01, so the policy correctly rejected. The agent then said, verbatim:

"Approve manually — the policy should have prompted you to approve"

The agent expected an in-chat approval prompt and there was no mechanism to produce one. The model's own behavior surfaced the gap. For personal-agent platforms (Hermes, OpenClaw) this is the missing piece between "auto-approve everything small" and "reject everything big."

Design options

Option A — two-tool pattern (recommended)

When the policy returns approval-needed, pay does NOT throw. It returns a structured pending result:

{
  "ok": false,
  "status": "approval_required",
  "intent_id": "intent_abc123",
  "amount": 0.01,
  "currency": "USDC",
  "recipient": "https://...",
  "reason": "above auto-approve limit",
  "expires_at": "2026-05-28T10:15:00Z"
}

The agent relays this to the human in chat ("This costs 0.01 USDC, approve?"). A new approve_payment tool takes the intent_id. When the human says yes, the agent calls approve_payment, and blacktea completes the settle using the staged intent.

Works on every MCP host. Maps cleanly to the existing PaymentIntent model. Explicit, no protocol-version dependency.

Option B — MCP elicitation

Use the MCP elicitation capability (server requests input from the user through the client). Cleaner single-call UX, but host support varies and Hermes/OpenClaw elicitation support is unverified. Could be a later enhancement on top of Option A.

Option C — notification + poll

pay returns pending, agent polls a payment_status tool. Clunkier; only worth it if A and B both prove infeasible.

Recommendation

Ship Option A. It's the lowest-common-denominator that works in Hermes, OpenClaw, Claude Desktop, and Cursor today.

Relationship to #3

#3 is out-of-band approval via a separate CLI process (blacktea approve <id> from a different shell) — the tightest trust boundary, for high-stakes wallets where the agent must never be in the approval path.

This issue is in-conversation approval through the same agent chat — the best UX for personal agents where the human and the agent share one interface.

They're complementary, not competing. Different trust models for different users. A mature blacktea supports both and lets the policy choose: approval: "out_of_band" vs approval: "chat".

Priority

Not blocking v0.1.0, but this is THE feature for the Hermes/OpenClaw positioning. The personal-agent launch story is "your agent asks before it spends" — and right now, through MCP, it can't ask. High priority for the post-launch v0.1.x line.

[rpelevin]

Option A looks like the right low-common-denominator path.

One thing I would make explicit in the pending result is the decision object that survives the chat turn. The approval_required response should not only say "ask the human"; it should create an intent/decision boundary that can later prove exactly what was approved.

For a payment tool, I would expect the pending object or follow-up approval record to bind:

• MCP server and tool;
• intent_id;
• amount, currency, recipient, and target endpoint;
• actor/principal;
• reason and policy threshold crossed;
• expiry;
• params hash;
• final route: allow, revise, human_review, or stop.

That keeps "the human said yes in chat" from becoming a vague transcript claim.

I have a small synthetic MCP risk-gate proof for this approval-before-dispatch shape here:

https://github.com/neurarelay/relay-action-card/blob/main/docs/mcp-risk-gate.md

No real payment, no MCP host claim, no downstream execution. The useful part is the receipt boundary around the pending action.

[nmrtn]

Thanks, this is a good push.

Option A actually shipped in v0.1.0/0.1.1: pay no longer throws on approval-needed. It returns a staged result and the MCP server exposes approve_payment / reject_payment keyed by intent_id, so the in-chat "ask first, settle only after yes" flow works on Hermes, OpenClaw, Claude Desktop, and Cursor today.

Strong agree on your main point: "the human said yes" should be a verifiable boundary, not a transcript claim. What the staged intent + audit log already bind:

• intent_id
• amount, currency
• recipient_wallet + recipient_url (the target endpoint)
• intent (the agent's own stated reason for the spend)
• rule_fired (the policy threshold that was crossed)
• audit chain: approval_staged → approval_received {approve|deny} → payment_completed|payment_denied, all keyed by intent_id

So most of your list is there. The gaps you named are the right ones, and a couple are already tracked:

• expiry: today the MCP server uses a fixed 1h TTL; the policy's own timeout_seconds should drive it instead. On the list.
• params_hash: not done, and I want it. Hashing the exact request (url + method + body + amount) into the staged intent closes the gap between what the human approved and what actually settles. Good catch.
• actor/principal: not modeled yet. Matters once more than one agent or human shares a wallet.
• "revise" as a route (counter-offer a lower cap instead of a binary yes/no) is interesting, hadn't considered it.

One deliberate narrowness today: the decision lives in the audit log (a stream), not a single structured receipt. Pulling it into one queryable approval record is the natural next step and lines up with what you're describing.

I'm closing this since Option A is shipped, and I opened #5 for the "approval decision record / receipt boundary" so it doesn't get buried here. Would love your input on the schema there. Thanks for the proof doc, reading through it now.

[nmrtn]

Closing as completed: Option A (in-conversation approval) shipped in v0.1.0/0.1.1. Follow-up on the verifiable decision record tracked in #5.