Skip to main content
This documentation is written for agents as first-class readers, and it exposes machine-readable surfaces so agents never have to scrape HTML. Every page carries a retrieval-ready description, self-contained sections, exact values, and stable URLs.

​
Plain-text indexes

Use llms.txt to discover which page answers a question, then fetch that page. Use llms-full.txt when you want the whole corpus in context at once.

​
Markdown for every page

Append .md to any docs URL to get the page as raw Markdown instead of HTML:
Markdown variants preserve headings, tables, and code blocks — the parts agents need — without navigation chrome.

​
Two MCP servers, two jobs

Cactal exposes two MCP servers. They answer different questions, and agents commonly connect to both. Use the docs MCP when the question is “how does Cactal work” — publishing semantics, field types, error handling, limits. Use the product MCP when the task is “do it” — create the website, publish the draft, roll it back. See Connect over MCP for product MCP setup. Connect the docs MCP with a plain Streamable HTTP entry — no headers required:
Docs MCP client config
The product API exposes documentation search and read operations over HTTP; the product MCP surfaces them as docs_search and docs_read like every other public operation. An agent connected only to the product MCP can therefore plan against the docs and act through the same connection. The docs MCP remains the zero-auth option for research-only workloads.
Do not point a product workload at the docs MCP or vice versa. The docs server has no access to your resources, and the product server does not answer documentation questions.

​
Contextual menu

Every documentation page has a contextual menu with agent-oriented actions:
  • Copy page — copy the page as Markdown for pasting into a prompt.
  • View as Markdown — open the .md variant of the page.
  • Open in ChatGPT / Claude / Cursor — start a session with the page preloaded as context.
  • Connect MCP — get the docs MCP server configuration for your client.

​
The OpenAPI spec

The API reference is generated from a public OpenAPI spec, downloadable from the API reference introduction. The spec is produced from the live endpoint registry, so it cannot drift from the deployed API. Beyond paths and schemas, each operation declares x-cactal-required-capability — the capability an API key needs to call it. Agents can use this to predict, before calling, whether a given key can perform an operation. See Authentication for how roles expand to capabilities.

​
Choosing a surface