Integrating with an AI assistant

Most developers now write integrations with an assistant open. An assistant that has never seen this API will invent endpoints that sound right, and the developer finds out at runtime. Three things fix that, in increasing order of usefulness.

1. Documentation an assistant can actually read

An HTML page is mostly navigation and styling. These are the same content with none of that, at stable URLs, so an assistant that fetches one URL gets everything and nothing else.

URL	What	Why
/llms.txt	Short index	What this service is and where the real content lives. The llmstxt.org convention.
/llms-full.txt	The whole integration, plain text	Every endpoint, the webhook contract and the mistakes that break most integrations, in one file an assistant can read in a single fetch.
/openapi.json	OpenAPI 3.1	Machine-readable. Generate a typed client, import into Postman or Bruno, or hand to any tool that reads a spec.

Nothing to install and nothing to configure. Paste one of those URLs into any assistant that can browse and ask your question.

2. The MCP server

Documentation tells an assistant what the API looks like. This lets it use the API. Instead of writing code that might work, it can create a real invoice against your wallet, read what came back, and correct itself before you ever run anything.

Claude Code

claude mcp add buxapi \
  --env BUXAPI_SECRET_KEY=bux_sec_... \
  -- npx -y @buxapi/mcp

Claude Desktop, Cursor, VS Code and anything else that speaks MCP

{
  "mcpServers": {
    "buxapi": {
      "command": "npx",
      "args": ["-y", "@buxapi/mcp"],
      "env": { "BUXAPI_SECRET_KEY": "bux_sec_..." }
    }
  }
}

Get a key by creating a wallet. No account, no email. Creating a second one to develop against costs one API call, which is the point of an API with no accounts.

Tools

Tool	What it does
get_wallet	Public key, settlement mode, balances, activated pairs
list_chains	Live USD rates and the pairs actually enabled right now
create_invoice	Create an invoice and get its checkout URL
get_invoice	Status, quotes, what has been received so far
list_invoices	Recent invoices, filterable by status
cancel_invoice	Cancel an unpaid invoice
create_address	Allocate a permanent deposit address
list_addresses	Addresses allocated to this wallet
list_deposits	Deposits with credited amounts and fees
list_transactions	The ledger: every credit and debit with its reason
list_sends	Outgoing sends and their on-chain status
test_webhook	Have BuxAPI deliver a signed test event to your endpoint
verify_webhook_signature	Check a signature locally, and say why it failed
send	Move funds on-chain. Disabled unless explicitly enabled

Sends are off by default

send moves real money and cannot be undone. It is not exposed unless you start the server with --allow-sends:

"args": ["-y", "@buxapi/mcp", "--allow-sends"]

An assistant that misreads a decimal place should not be able to empty a wallet, and this particular failure has no undo. Everything else is either a read, or creates an invoice, which costs nothing and expires by itself.

The tool that saves the most time

verify_webhook_signature runs locally and makes no network call at all. Paste the raw body and the X-Buxapi-Signature header, and it says whether the signature is valid and, when it is not, which of the usual causes it is: the body was parsed and re-serialised somewhere so the bytes changed, the secret is wrong, or the signature is valid but outside the replay window.

"My webhook signature does not verify" is almost always the first one, and it is genuinely hard to see by reading code, because the JSON looks identical. This turns it into one tool call.

Building an assistant on top of BuxAPI

If you are the one shipping the AI product rather than using one, the same three surfaces apply, and /openapi.json is the one to start from. The MCP server is MIT licensed and small enough to read in one sitting if you want to fork it into your own tool namespace. Ask us if you need something the spec does not describe.