pay_order (typescript/src/shared/functions.ts, captureOrder) takes {id} and calls POST /v2/checkout/orders/{id}/capture directly — there's no confirmation/elicitation step anywhere in this repo before that call goes out, and the response (purchase_units[].payments.captures[0]) only lives in the MCP response and whatever the host app's own logs retain.
That's two separate gaps worth naming, since they're independent properties: (1) nothing here gates the call before it fires — an agent with this tool wired in can capture a real payment on function-call arguments alone; (2) even if it did have a gate, there's still no way for a third party (auditor, counterparty, regulator) to later verify what was requested and captured without trusting the MCP session or the host app.
Worked example, applying a public spec (no changes asked of this repo): https://github.com/giskard09/paypal-action-ref-anchor
It derives action_ref — a content-addressed id from {agent_id, action_type, scope, timestamp} (JCS RFC 8785 + SHA-256, argentum-core/action-ref-v1) — for a synthetic pay_order call shaped exactly per this repo's own captureOrderParameters ({id}) and the capture object shape this repo's own code reads back (functions.ts:629-636), then anchors it permissionlessly on Base mainnet (tx in the repo, independently verifiable, no owner/roles on the registry).
A companion example for a different toolkit (@tetherto/wdk-mcp-toolkit) anchors a third field, confirmation_digest, because that one does have a pre-execution approval gate. This repo's envelope only has two fields — params_digest and result_digest — because there's no confirmation step here to anchor as a third. PROVENANCE.md in the repo spells this difference out explicitly.
To be explicit about what this is: a worked example against your public source, not a claim that agent-toolkit does or should implement this, and not an ask for any change here.
pay_order(typescript/src/shared/functions.ts,captureOrder) takes{id}and callsPOST /v2/checkout/orders/{id}/capturedirectly — there's no confirmation/elicitation step anywhere in this repo before that call goes out, and the response (purchase_units[].payments.captures[0]) only lives in the MCP response and whatever the host app's own logs retain.That's two separate gaps worth naming, since they're independent properties: (1) nothing here gates the call before it fires — an agent with this tool wired in can capture a real payment on function-call arguments alone; (2) even if it did have a gate, there's still no way for a third party (auditor, counterparty, regulator) to later verify what was requested and captured without trusting the MCP session or the host app.
Worked example, applying a public spec (no changes asked of this repo): https://github.com/giskard09/paypal-action-ref-anchor
It derives
action_ref— a content-addressed id from {agent_id, action_type, scope, timestamp} (JCS RFC 8785 + SHA-256, argentum-core/action-ref-v1) — for a syntheticpay_ordercall shaped exactly per this repo's owncaptureOrderParameters({id}) and the capture object shape this repo's own code reads back (functions.ts:629-636), then anchors it permissionlessly on Base mainnet (tx in the repo, independently verifiable, no owner/roles on the registry).A companion example for a different toolkit (@tetherto/wdk-mcp-toolkit) anchors a third field,
confirmation_digest, because that one does have a pre-execution approval gate. This repo's envelope only has two fields —params_digestandresult_digest— because there's no confirmation step here to anchor as a third. PROVENANCE.md in the repo spells this difference out explicitly.To be explicit about what this is: a worked example against your public source, not a claim that agent-toolkit does or should implement this, and not an ask for any change here.