Use a coding Agent to integrate Spendkit

A coding assistant can edit your Agent project. The running Agent Runtime later obtains Spendkit access and sends any authorized payment. Give these two roles separate credentials and responsibilities.

Give the coding assistant the interface contract

Start with the JavaScript, Python, Go, or C++ example closest to the developer's project. Share the inputs and outputs of every tool and the machine-readable llms-full.txt or integration.json. The live tools/list result supplies each tool's current JSON input schema. The model can read those public documents without receiving your secrets.

What the coding assistant should inspect first

1. Does your project already have MCP initialization, tool discovery, and a tool-result loop?
2. Can it acquire and refresh OAuth Client Credentials access tokens?
3. Can a trusted wallet adapter submit the exact Router transaction from the Agent's bound Payment Wallet?
4. Where are secrets stored, and how are payment outcomes recorded and reconciled?

Copyable project brief

Integrate Spendkit into this AI Agent project.
Read https://spendkit-alpha.vercel.app/docs/runtime/,
https://spendkit-alpha.vercel.app/docs/examples/,
https://spendkit-alpha.vercel.app/docs/api-quickstart/,
https://spendkit-alpha.vercel.app/docs/mcp-tools/,
and https://spendkit-alpha.vercel.app/llms-full.txt first.
Inspect the existing MCP client, OAuth refresh, tool loop, wallet sender, and secret storage.
Implement a form-encoded client_credentials request to /oauth/token, cache the Bearer token
until near expiry, and use it for MCP discovery, tools/list, and tools/call.
Parse result.structuredContent and result.isError; HTTP 200 can contain a Policy DENY.
The authenticated Agent connection selects the Policy and verified Payment Wallet.
Keep the Payment Wallet private key outside the model context and Spendkit Server.
Implement get_connection and get_policy first. Preview before authorization.
If preview or authorization is denied, stop without sending a transaction.
For an allowed payment, verify the exact returned Router transaction and its from address,
submit from the bound wallet, record its hash, then reconcile status until terminal.
Use one stable idempotencyKey per logical payment. Never blindly retry an uncertain broadcast.
Do not change spending limits, recipient rules, or token allowances without the wallet owner's action.
Start with read-only connection and preview; report what remains before a real test payment.

What the finished integration must contain

1. An OAuth client that stores the Client Secret in protected Runtime configuration and refreshes access tokens.
2. An MCP client that discovers tools, passes the assigned Bearer token, validates tool arguments, and distinguishes transport errors from tool-level DENY results.
3. A payment coordinator that preserves the intended amount, token, recipient, and idempotency key through preview and authorization.
4. A trusted wallet signer that matches the bound wallet and exact authorized Router transaction, submits once, then records and reconciles the transaction hash.

Tool-specific project instructions: Codex, Claude Code, and Gemini CLI. These are development aids; support for generic remote MCP configuration does not by itself establish Spendkit Runtime token refresh or payment submission.