Skip to main content
One call turns the SDK into a tool surface: definitions any model can use, plus a dispatcher that executes whatever it picks. The agent gets exactly the capabilities you have — no more — and every cap stays on the contract, enforced server-side, no matter what the model does.

Wire-up

The definitions carry the usage guidance a model needs — required fields, defaults, when to ask the user — so you don’t write tool prompts yourself.

The loop

Provider-agnostic: hand the model the definitions, execute what it calls, feed the result back.

The tools

Each tool maps to the SDK method of the same name — parameters and behaviour are identical, so the reference covers both.

Setup & sandbox

Contracts

Payments

Refunds

Customers & stores

Approvals: the human stays in charge

Approving is deliberately not a tool. A send_payment or off-session collect_payment result carries a nextAction — the agent’s job is to surface its approvalUrl to the right human (the business owner for a send, the customer for a charge) and wait for the decision. The model never approves its own payment, and the credential is only ever entered on Atoa’s page. Every payment an agent makes is a normal Paymentlist_payments and get_payment give it (and you) the full audit trail.

No AI required

The tools are a thin layer over the SDK. Without a model in the loop, call the same operations directly — atoa.payment.collect(...), atoa.payment.send(...) — for identical behaviour.

Prefer MCP?

The hosted Atoa MCP server exposes Atoa’s tools to Claude, Cursor, VS Code, and any other MCP-compatible client — no SDK integration needed.