AI and agents#
Four ways to give an assistant or an agent this documentation, in order of how little work each one costs you. If you are wiring up a coding agent, start with the MCP server and stop reading.
MCP server#
A remote MCP server that answers questions about these pages directly. No downloads, no file handling, and nothing to keep up to date: it reads the published pages, so it changes when they do.
https://www.centapay.com/mcp
Three tools:
| Tool | What it does |
|---|---|
search_docs | Ranked search across every section. Takes an action name, a parameter, an error code or a plain question. |
get_page | One route in full, section by section, with its heading anchors. |
list_routes | Every route with its title and section count. |
Claude Code#
claude mcp add --transport http centapay-docs https://www.centapay.com/mcp
Cursor#
In ~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"centapay-docs": {
"url": "https://www.centapay.com/mcp"
}
}
}Claude Desktop#
Add it as a custom connector in settings, using the same URL. On a build that only speaks stdio, bridge it:
{
"mcpServers": {
"centapay-docs": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://www.centapay.com/mcp"]
}
}
}The URL is the only part of this that comes from us. The file locations and the config shape belong to each client, and they change independently of this page. A plain GET of the endpoint returns the server name and its tool list, which is the quickest way to confirm a client is reaching it.
The whole site as text#
llms.txt is the index: every route with one line on what it is for, so a model can route to the right page from a task description rather than an operation name. It is the file to paste when an assistant needs to know what exists.
llms-full.txt is the whole thing: all 30 routes, marketing and documentation, as one plain-text document. It is generated from the published pages, so it cannot disagree with them. Paste it when an assistant needs the content rather than the map. It is also published in four parts, one per area, for fetching a single section rather than the whole site.
Some IDE assistants read both automatically when they are present at the site root. Both are, and neither needs anything from you.
Markdown for any page#
Append .md to any documentation URL for that page as Markdown, with its headings, tables and code samples intact.
https://www.centapay.com/docs/reference.md https://www.centapay.com/docs/guides/take-a-payment.md
Useful when you want one page in a prompt rather than the whole site. The published hash vectors survive the conversion, so a digest copied from a .md file is the digest on the page.
OpenAPI and Postman#
The OpenAPI specification is what a code generator or an agent uses to construct requests rather than read about them: parameter names, types, whether a field is required, and the shape of each response. It describes the transport. It does not describe which hash formula an action signs with, and that is the part people get wrong, so an agent working from the spec alone will still need the reference.
The Postman collection carries one request per action with a pre-request script that computes the correct hash for each, which makes it the fastest way to see a signed request that works.
The API guide is the reference and the quickstart as one Markdown file, for handing whole to an assistant.
What an agent cannot know#
This is the part worth putting in front of a model, because an agent filling these gaps confidently is the failure this page exists to prevent.
- There is no sandbox host in these pages. CentaPay is pre-launch. Endpoints appear as placeholders such as
{PAYMENT_URL}because the real value is issued with your credentials, not published. An agent that invents a hostname has invented it. - Credentials are issued by hand. There is no self-service signup and no key endpoint. Anything describing one is wrong.
- Three questions are still open. Five have been answered since this page was written and are documented on troubleshooting: callback delivery retry, the delivery log, deliberate sandbox triggers, callback timeout testing, and the per-request callback URL parameter. Still outstanding: reconciliation report formats, the definitive status transition list, and the signature for
GET_TRANS_STATUS_BY_ORDER, which is escalated and unresolved. These pages say nothing about any of the three rather than guessing, and a hash construction in particular is never inferred. - Availability differs by market and nothing here is live. The coverage table is the single source for what is planned where.
If a page does not state something, the honest answer is that it is not documented. Guessing a parameter name or a hash construction costs a failed integration and an afternoon.
Questions go to [email protected].