pay_order calls PayPal's capture API directly — no confirmation step, no post-execution record

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.

Read typescript/src/shared/functions.ts, starting at captureOrder and the captureOrderParameters definition, then compare the described request and response handling with the linked worked example. The issue does not request a repository change or define acceptance criteria, so there is no implementation-ready definition of done.