The toolkit exposes money-movement actions (payments, refunds, payouts) to agents. I maintain EMILIA's open Receipt Required rail (Apache-2.0): a small, opt-in gate so a money-movement tool refuses to run unless a named human signed an authorization receipt for that exact action and amount — the agent-era equivalent of dual control.
The four-step behavior (CI-verified):
- missing receipt →
428 Receipt Required
- valid, action-bound receipt → runs
- same receipt replayed → refused (one-time consumption)
- forged receipt → refused
Disabled by default, no lock-in — purely additive. There's a runnable payment-server example that gates release_payment end-to-end. Open to a PR behind an opt-in flag? Happy to author it.
Spec + guide: https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/guides/RECEIPT-REQUIRED-MCP.md
The toolkit exposes money-movement actions (payments, refunds, payouts) to agents. I maintain EMILIA's open Receipt Required rail (Apache-2.0): a small, opt-in gate so a money-movement tool refuses to run unless a named human signed an authorization receipt for that exact action and amount — the agent-era equivalent of dual control.
The four-step behavior (CI-verified):
428 Receipt RequiredDisabled by default, no lock-in — purely additive. There's a runnable
payment-serverexample that gatesrelease_paymentend-to-end. Open to a PR behind an opt-in flag? Happy to author it.Spec + guide: https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/guides/RECEIPT-REQUIRED-MCP.md