How to make your SaaS ready for agents (AX)

APIs, auth, docs and discovery files that AI agents can actually read and use, from your marketing site to your MCP server.

More and more of your users will meet your product through an agent: a coding assistant reading your docs, a research agent comparing your pricing, an assistant signing up and calling your API on someone's behalf. Agent experience (AX) is how well that goes. An agent cannot click through a cookie banner, solve a CAPTCHA or guess what a JavaScript widget meant to say. It reads what you publish, and it uses what you let it use.

This journey works through that in order. First you let agents in and give them something to read: server-rendered pages, llms.txt, markdown versions, structured data, a pricing page and answers to common questions. Then you make the product usable without a human in the loop: an API with a spec, authentication an agent can complete, and errors it can recover from. Last, you make your product discoverable as a tool: an MCP server with a server card, an AI catalog, and signed requests from your own agents.

The steps about content and discovery have auditors that check your monitored URL. The steps about your API and auth complete by hand.

If you only need the first part, How to make your site readable by ai agents is the shorter version.

Steps

Open a step to read it

1
Let agents in
Before an agent can read your site, it has to be allowed to fetch it. Many sites block AI crawlers and agents by accident: a bot protection setting, a firewall rule copied from somewhere, or a robots.txt that disallows everything that is not Google.
Do this
- Look at your server or CDN logs for agent user agents (ChatGPT-User, Claude-User, Perplexity-User, GPTBot, ClaudeBot, PerplexityBot) and check what status codes they get
- Decide per agent what you want: training crawlers and user-triggered agents are different things, and you can allow one and not the other
- Write that decision into robots.txt
- Check your bot protection (Cloudflare, Vercel, your WAF). Allow verified agents, or at least do not serve them a challenge page on docs, pricing and API pages
Done when the agents you want get 200 on the pages that matter, and your robots.txt says what you meant.
2
Render the content on the server
Verifies with CSR/SSR Auditor
Most agents do not run JavaScript. If your pages build their content in the browser, an agent sees an empty shell: a title, a script tag and nothing else.
The CSR/SSR Auditor fetches the page without a browser and warns when it looks client-side rendered.
Do this
- Server-render or pre-render the marketing site, docs, pricing and changelog. Next.js, Nuxt, Astro, SvelteKit and Remix all do it
- Keep client-side rendering for the signed-in app, where agents use the API instead (step 8)
- Check with curl https://your-site/pricing: the prices should be in the output
Done when the auditor passes.
3
Publish an llms.txt
Verifies with LLMs.txt Auditor
/llms.txt is a markdown index of the pages you want agents and language models to read, with a line about each. It saves an agent from guessing URLs or reading your whole sitemap. Some sites also publish /llms-full.txt with the full text in one file.
The LLMs.txt Auditor fetches /llms.txt and /llms-full.txt and checks that they exist and follow the format.
Do this
- Start with an # H1 with the product name and a > one-line summary
- Add sections with links to docs, API reference, pricing, changelog, and the guides people ask about most, each with a short description
- Generate it from the same source as your docs so it stays current
Done when the auditor passes.
4
Serve markdown versions of your pages
Verifies with Markdown Content Auditor
HTML is mostly navigation, scripts and layout. An agent reading it spends most of its context on things that are not your content. A markdown version of each page is smaller and keeps the structure that matters: headings, lists, code and links.
The Markdown Content Auditor checks that your pages have a markdown version, by URL (/pricing.md) or by content negotiation (Accept: text/markdown).
Do this
- Serve .md versions of docs and key marketing pages. Many docs tools can do it out of the box
- Answer Accept: text/markdown with markdown and Content-Type: text/markdown, and keep HTML for browsers
- Link the markdown versions from llms.txt
Done when the auditor passes.
5
Describe the product in structured data
Verifies with Schema Entities Auditor
Structured data tells agents what a page is, not only what it says: this is a software product, made by this company, with these offers. Search engines and AI answers use it to describe you correctly.
The Schema Entities Auditor looks for Schema.org entities on the page and fails when there are none.
Do this
- Add JSON-LD in a <script type="application/ld+json"> block
- On the home page, Organization (name, logo, URL, sameAs links to your profiles) and WebSite
- On product pages, SoftwareApplication or Product with offers
- On docs and blog posts, Article or TechArticle
Done when the auditor passes.
6
Make pricing easy to find and read
Verifies with Pricing Auditor
"How much does it cost?" is one of the first things an agent is asked about your product. If the answer is behind "Contact sales", a calculator widget or an image, the agent says it does not know, or guesses.
The Pricing Auditor crawls the site from your monitored URL looking for a pricing or plans page, in English or Portuguese, and fails when it finds none.
Do this
- Publish a pricing page linked from the main navigation, at an obvious URL like /pricing
- Put plans, prices, currency, billing period and limits in text, not only in images or toggles
- Add Offer structured data with price and priceCurrency (step 5)
- If pricing depends on usage, show the formula and an example
Done when the auditor finds the pricing page.
7
Answer the common questions on the page
Verifies with FAQ Auditor
Agents answer questions. The fastest way to make sure they answer questions about you correctly is to publish the answers yourself: what the product does, who it is for, how it compares, what it integrates with, how data is handled.
The FAQ Auditor looks for an FAQ page or FAQ section and fails when it finds none.
Do this
- Collect the questions sales and support hear most often
- Answer each one in a few plain sentences, on a page agents can reach without JavaScript
- Mark it up with FAQPage structured data
Done when the auditor passes.
8
Publish an API with a machine-readable spec
An agent that wants to do something in your product, not just read about it, needs an API. And it needs to understand the API without a human reading the docs first.
Do this
- Cover the actions users take most, not only the ones integrations needed so far
- Publish an OpenAPI spec at a stable URL, and link it from llms.txt and the docs
- Give every operation and parameter a description that says what it does and when to use it. Agents read these the way they read tool descriptions
- Publish the API reference as plain text or markdown as well as the interactive explorer
- Version the API and announce breaking changes in a changelog agents can read
Done when an agent can find the spec from your home page and call one endpoint correctly using only what is published.
9
Let agents authenticate without a human in the loop
Most sign-in flows assume a person: a CAPTCHA, an email link, a phone code. An agent acting for a user gets stuck on the first one, and the user gives up on your product, not on the agent.
Do this
- Let users create API keys from the dashboard in a few clicks, with a name and an expiry
- Support OAuth 2.0 with scopes, so a user can grant an agent access without handing over a key. Use the authorization code flow with PKCE for agents acting for a user, and client credentials for machine-to-machine
- Offer narrow scopes (read-only, one project) so users can give an agent only what it needs
- Show users which agents and keys have access, when they were last used, and let them revoke them
- If you have a free tier, let it be reached without a CAPTCHA-only signup, or with an API-based signup that has its own abuse controls
Done when a user can give an agent scoped, revocable access without sharing their password.
10
Return errors an agent can act on
A human reads "Something went wrong" and tries again later. An agent needs to know what went wrong and what to do: retry, wait, fix a parameter, or ask the user.
Do this
- Return structured errors with a stable code, a human-readable message and the field that caused it. RFC 9457 (application/problem+json) is a good default
- Use the right status codes: 400 for bad input, 401 and 403 for auth, 404, 409 for conflicts, 429 for rate limits
- Send Retry-After with 429 and 503, and document your rate limits
- Accept an Idempotency-Key header on requests that create or charge, so an agent can retry safely
- Paginate large lists with a cursor and say how many results there are
Done when every error your API returns tells a client what to do next.
11
Ship an MCP server and publish its server card
Verifies with MCP Server Card Auditor
The Model Context Protocol (MCP) lets assistants like Claude, ChatGPT and Cursor use your product as a set of tools, with the user's permission. A server card is a small JSON file that describes the server, its endpoint and its protocol versions, so clients can find and connect to it.
The MCP Server Card Auditor looks for cards linked from /.well-known/ai-catalog.json, then at /.well-known/mcp/server-card.json and /mcp/server-card. It validates each card against the schema and checks that it is served over HTTPS with the right media type and CORS headers.
Do this
- Build a remote MCP server over your API (step 8) with OAuth (step 9). Start with the actions agents are asked to do most
- Write tool descriptions for a model, not a developer: what the tool does, when to use it, what it returns
- Publish the server card at /.well-known/mcp/server-card.json with name, description, version and the remote endpoint
- Serve it with Access-Control-Allow-Origin so browser-based clients can read it
Done when the auditor validates the card.
12
List your agent capabilities in an AI catalog
Verifies with AI Catalog Auditor
An AI catalog (ai-catalog.json, from the Agentic Resource Discovery spec) is one index of everything an agent can use on your domain: MCP servers, APIs, agents, documents. Agents and registries read it instead of scraping your site.
The AI Catalog Auditor finds the catalog at /.well-known/ai-catalog.json, through an Agentmap: line in robots.txt, or through <link rel="ai-catalog">, then checks its headers and validates it against the schema.
Do this
- Publish /.well-known/ai-catalog.json with your publisher identity and one entry per resource: the MCP server card from step 11, the OpenAPI spec from step 8, llms.txt
- Give each entry an identifier, a type, a media type, and either a url or inline data
- Serve it as application/json over HTTPS
Done when the auditor passes.
13
Sign the requests your own agents send
Verifies with Web Bot Auth
If your product sends requests to other sites (an agent browsing for a user, a crawler, a link previewer), those sites have to decide whether to trust it. User agents can be faked, and IP lists go stale. Web Bot Auth lets your agent sign each request with HTTP Message Signatures, so a site or CDN like Cloudflare can verify it really came from you.
The Web Bot Auth Auditor fetches /.well-known/http-message-signatures-directory on your domain and checks it the way Cloudflare's validator does: a JWKS of Ed25519 keys, served with the directory media type, and signed with each key, with a signature that has not expired. It warns when the response can be cached for longer than the signature is valid.
Do this
- Generate an Ed25519 key pair for your agent and keep the private key in your secret manager
- Publish the public key in the signed directory on your domain
- Sign outgoing requests with Signature-Agent, Signature-Input and Signature headers
- Register the agent with the CDNs and sites that matter to you, such as Cloudflare's verified bots program
Done when the auditor passes. If your product sends no requests to other sites, mark this step complete.
14
Watch how agents use you
AX is not done once. Agents, protocols and user habits change every few months, and the only way to keep up is to look at what actually happens.
Do this
- Track agent traffic in your logs separately from human traffic: which agents, which pages, which API calls, which errors
- Ask the main assistants about your product now and then, and check that what they say about pricing and features is right. Fix the source page when it is not
- Read the API errors agents hit most and fix the docs or the API
- In 37 Audits, schedule the auditors from this journey to run regularly on this monitored URL
Done when you have a regular look at agent traffic and the auditors run on a schedule.

Create an account, add your site as a monitored URL and work through these steps on it.