An agent-ready SaaS in 2026 answers five plain questions: can a machine read the docs, can an agent do things, can it log in safely, can it understand price and pay, and can it check who the vendor is.
Published 2026-06-08 · Last reviewed 2026-06-08
A SaaS tool can score 90% or higher on a public “agent-ready” scorer and still be useless to an actual agent. That sounds like a contradiction. It is not. The public scorers grade the marketing website: can a bot find the page, read the text, and respect the rules. They do not test the part that matters once an agent tries to get work done. They do not test the login. They do not test the way the agent calls the tool. They do not test whether the agent can read the price and pay. The score measures the front door. The agent needs to get inside.
That gap is the whole point of this article. If you are evaluating tools and you are not a protocols expert, you need a way to spot the gap without taking a vendor’s score at face value. Below is a checklist of five plain questions a buyer actually asks, with real named examples for each, and a five-minute test you can run on any vendor yourself.
This is honest by design. The shortlist of tools that pass all five questions is genuinely thin, so this is not a ranked “top 10.” It is criteria plus real examples per question, and clear notes on where almost nobody has shipped. Two related guides sit underneath this one: the website side is covered in How to make your website agent-ready in 2026, and the diagnostic walkthrough is in Is your site agent-ready? The audit checklist and what the tools miss.
Why a high “agent-ready” score can still mean useless
The public scorers grade the wrong surface for a SaaS. Cloudflare’s Agent Readiness score, the most cited one in 2026, has four scored buckets: discoverability, content, bot access control, and capabilities. It also runs a commerce check, but that check does not count toward the score. Every one of those graded buckets is about the website an agent reads. None is about the product an agent has to operate.
Here is the difference in one line. A marketing site is a body of content. A SaaS is a unit of work. When an agent visits a publisher, its job is to read and quote. When an agent uses a SaaS for a person, its job is to log in, pick the right action, do it inside a permission limit, pay if needed, and report back. Reading the homepage is the easy part. Everything that follows is the part the scorers skip.
So a tool can ace the page and fail the job. Picture a SaaS that scores 92% on a public scorer. Its docs are clean, its content is crawlable, its bot rules are tidy. Then an agent tries to log in and hits a login flow that only works if a human clicks through a dashboard and copies a secret. The agent stops there. The 92% was real. It just measured the lobby, not the rooms.
Question 1: Can a machine read the docs?
Start here because it is the cheapest thing for a vendor to get right, so a miss tells you a lot. Roughly 300,000 domains were studied in SE Ranking’s 2025 review of llms.txt files (SE Ranking, 2025), which shows the practice is spreading even where its ranking benefit is unclear. For a buyer, the question is simpler: can an AI read these docs as clean text, or only as a styled web page built for human eyes?
Clean docs mean an agent does not have to fight through page layout to find an answer. The strong signal is documentation an AI can pull as plain text, plus a machine-readable description of any API. Stripe is the clearest example. It publishes a docs surface built for AI to read and ships a full machine-readable API description. Cloudflare’s developer docs come from a plain-text source and expose raw text per page. Vercel and Cursor publish docs a coding assistant can read without untangling HTML.
None of these vendors did anything exotic. They invested in good documentation before “agent-ready” was a phrase, and that investment now pays off twice. (For an honest look at one popular docs-for-AI practice, see does llms.txt actually work.)
Question 2: Can an agent actually do things, not just read?
This is the question that separates a brochure from a tool. Reading docs is passive. Doing things means there is a real way for an agent to call the product and make something happen. In 2026 the common answer is an MCP server, short for Model Context Protocol, which is the de-facto way to let an agent see a tool’s actions and run them through one connection. A clean, stable API counts too.
The named examples here are concrete. GitHub ships its own MCP server covering issues, pull requests, repositories, and code search. Stripe ships an agent toolkit and MCP server. Atlassian runs a remote MCP server for Jira and Confluence. Linear and Notion each ship their own MCP servers. Cloudflare went further and built a place to host MCP servers, plus its own. The pattern is clear: the strong vendors put a first-party calling surface next to their normal API.
A coding assistant that can call a first-party MCP server beats a tool with a fancier “capabilities” badge but no working backend. The badge is a promise. The MCP server is a tool an agent can use today. When you evaluate, weight the working artifact over the manifest.
Question 3: Can an agent log in on a user’s behalf, safely?
This is the question the public scorers skip entirely, and it is where most tools quietly fail. The job is narrow: can an agent log in for a person, with limited permissions, and without a step only a human can do? Many tools still require someone to open a dashboard, create an app, and copy a secret by hand. An agent cannot do that, so the login becomes a wall.
A safe agent login has three traits a buyer can feel. The agent gets limited permissions, not the keys to everything. The agent can register and refresh itself without a person clicking through a console. And there is no human-only step in the path, no QR code, no fingerprint scan, sitting between the agent and the action.
This is the row that quietly decides everything. Plenty of tools have clean docs and a real MCP server but still stop dead at login, because the only documented path assumes a person at a keyboard. Limited-permission logins are common now. Logins an agent can set up on its own are still rare. GitHub offers fine-grained tokens scoped per resource. Linear, Notion, Stripe, and Atlassian all offer limited-permission logins. The self-setup piece is the differentiator, and few ship it cleanly.
Question 4: Can a machine understand the price and pay?
A real payment standard for agents now exists, which is new. Stripe and Tempo launched the Machine Payments Protocol on 18 March 2026, letting an agent start a payment through Stripe’s existing PaymentIntents API. So the question is fair to ask: can a machine read the price on the page, and is there a documented way for an agent to pay within limits the user sets?
There are now three named rails worth knowing. The Stripe and Tempo Machine Payments Protocol (18 March 2026) is the one most SaaS buyers reach first. AP2, Google’s Agent Payments Protocol, was announced on 16 September 2025 and donated to the FIDO Alliance on 28 April 2026, with 60-plus partners including Mastercard, Visa, American Express, and Worldpay. There is also x402, a Coinbase-originated crypto rail now hosted by the Linux Foundation’s x402 Foundation since 2 April 2026. Pick the rail your customers actually use.
The other half of this question is spend limits. A good tool lets an agent read and respect caps: a per-action limit, a daily limit, a ceiling the user sets once. That way the user is not re-approving every small transaction, and the agent cannot run up a surprise bill. Machine-readable pricing plus a documented agent-payment path is a strong pass. One of the two is partial. Neither is a fail.
Question 5: Who is the company behind the tool, and can an agent check them?
Almost nobody fills this row, and the public scorers do not grade it. The question is the one a careful person asks before handing over real work: who is the company behind this tool, and can an agent representing me verify them before committing money or data? In 2026 no major SaaS publishes a clean, human-readable identity an agent can check this way. It is the thinnest part of the whole picture.
A few partial approaches exist. One vendor that talks about this publicly is Salespeak (Palo Alto), which presents itself as reachable by other agents, though that framing comes from Salespeak’s own blog, so treat it as a vendor claim rather than a settled standard. On the protocol side, there are emerging conventions for naming the operator behind an agent, covered in How A2A Agent Cards work. The honest read is that this row is unsolved across the SaaS field, and a check that pretends otherwise is doing the vendor a favor.
This identity question is the gap Tobira works on, alongside protocol-side naming approaches. A Tobira handle gives the company behind a tool a public profile other agents can check, with a step where both sides confirm who they are before either acts. It complements a clean MCP server, a safe login, and machine-readable pricing. It does not replace any of them. For the longer version of why a readable site is not the same as an addressable company, see Your website is agent-readable. That is not the same as agent-addressable..
A five-minute test you can run on any vendor
You can run all five questions yourself in about five minutes, with no account. Here is the plain version of each test.
Can a machine read the docs?
Open the docs and look for a machine-readable API description and a raw-text version of any reference page. Many sites let you add .md to a doc URL or offer a “View Markdown” toggle. If the docs are styled web pages only, with no plain-text export, that is a fail, and it tells you the vendor skipped the cheapest work.
Can an agent do things?
Search for “[vendor name] MCP server.” Check whether the result is the vendor’s own (under their GitHub or a vendor subdomain) or a community copy. A first-party result is a strong pass. A community copy is usable but not a vendor commitment.
Can an agent log in safely?
Open the login or authentication doc and read how an app gets set up. If the only path is “create an app in the dashboard, copy the client ID and secret,” an agent cannot do that on its own. If the docs mention an agent registering itself, that is the strong side. (The precise term to search for is in the technical notes below.)
Can a machine understand the price and pay?
Look at the pricing page source for machine-readable price markup, then search the docs for “Machine Payments Protocol,” “AP2,” or “agent payment.” Readable price plus a documented agent-payment path is a strong pass. One of the two is partial.
Can an agent check the vendor?
Search the vendor’s site for a public, agent-checkable identity or a recognized handle on an agent network. A hit is a pass. A miss is the normal 2026 finding, and naming it honestly is the right call.
Under the hood (for the technical reader)
Skip this section unless you want the exact specifics. Here are the precise artifacts behind each plain question.
- Docs. Clean Markdown or MDX rendering, a current OpenAPI or AsyncAPI description linked from docs and response Link headers, an
llms.txtindex at the docs root, and Schema.org JSON-LD on high-traffic reference pages. To verify, suffix a doc URL with.mdor look for raw-Markdown output. - Doing things. A stable REST or GraphQL API with idempotent writes as the floor, a first-party MCP server as the strong artifact, and an A2A Agent Card at
/.well-known/agent-card.json(A2A v1.0.1, 28 May 2026) if the SaaS itself acts as an agent. WebMCP is a W3C Web Machine Learning Community Group Draft, in Chrome origin trial from early June 2026, so still leave its box unticked. - Login. OAuth 2.1 with scoped tokens as the floor. The differentiators are dynamic client registration (RFC 7591), authorization server metadata (RFC 8414), and protected-resource metadata (RFC 9728), which together let an agent register and discover endpoints without a human pre-registering it. Okta ships dynamic client registration as a standard option. Search auth docs for “dynamic client registration,” “RFC 7591,” or a
registerendpoint. - Pricing and payment. Schema.org
ProductandOffermarkup on the pricing page, or a documented pricing endpoint. Payment rails: Stripe and Tempo Machine Payments Protocol via the PaymentIntents API (18 March 2026), Google AP2 (donated to the FIDO Alliance 28 April 2026), and x402 (Linux Foundation x402 Foundation, 2 April 2026). Confirm the marked-up price matches the checkout. - Identity. Candidate artifacts include an ENSIP-27 record at
/.well-known/agent.json, an A2A Agent Card with a named operator, and an agent-network handle.
FAQ
What is the difference between an agent-ready website and an agent-ready SaaS?
An agent-ready website is graded on how an AI can read and respect what the site publishes. An agent-ready SaaS is judged on whether an agent acting for a person can call the tool, log in safely with limited permissions, understand the price, and pay. The docs overlap. The product side (login, the way an agent calls the tool, payment) is the part the website scorers do not measure, which is why a SaaS can score high and still be useless to an agent.
Does shipping an MCP server make my SaaS agent-ready?
It answers one of five questions, not all of them. A first-party MCP server is a clear way for an agent to do things, but a tool with an MCP server and a login that still needs a human to set it up, with no machine-readable pricing and no vendor identity an agent can check, is still missing three of five rows. Treat an MCP server as one strong signal, not proof the whole tool is ready.
How can an agent pay for a SaaS on a user’s behalf?
Through a payment rail built for agents. Stripe and Tempo launched the Machine Payments Protocol on 18 March 2026, which runs through Stripe’s PaymentIntents API. Google announced AP2 on 16 September 2025 and donated it to the FIDO Alliance on 28 April 2026, with 60-plus partners including Mastercard, Visa, and American Express. There is also x402, a Coinbase-originated crypto rail now hosted by the Linux Foundation’s x402 Foundation since 2 April 2026. Pick the rail your customers actually use.
Why can a SaaS score 90% on a public agent-readiness scorer and still be useless to an agent?
Because the public scorers grade the marketing website, not the product. Cloudflare’s Agent Readiness score has four scored buckets covering discoverability, content, bot access control, and capabilities. It checks the website an agent reads, not the login an agent must complete, the way it calls the tool, or how it pays. A tool can ace the page and still block an agent at the door, which is the gap this checklist is about.
What does an honest agent-readiness check for a SaaS look like?
Five quick checks anyone can run without an account: can a machine read the docs, is there a first-party MCP server or clean API, can an agent log in with limited permissions without a human-only step, is the pricing machine-readable with a documented agent-payment path, and is there a vendor identity an agent can verify. Most 2026 SaaS passes two or three. A check that names the misses openly is more trustworthy than one claiming a perfect score.
Sources
- Cloudflare, Agent Readiness score and Agents Week 2026: https://blog.cloudflare.com/agent-readiness/
- Cloudflare, Is It Agent Ready? (URL Scanner): https://isitagentready.com/
- AgentReady.org community open specification: https://agentready.org/
- A2A protocol specification, v1.0.1, 28 May 2026 (Linux Foundation): https://a2a-protocol.org/latest/specification/
- Model Context Protocol specification and reference servers: https://modelcontextprotocol.io/
- Stripe and Tempo, Machine Payments Protocol (18 March 2026): https://stripe.com/blog/machine-payments-protocol
- Stripe, Building with LLMs (machine-readable documentation reference): https://docs.stripe.com/building-with-llms
- Stripe Agent Toolkit and MCP server: https://github.com/stripe/agent-toolkit
- GitHub MCP server: https://github.com/github/github-mcp-server
- Atlassian Remote MCP Server: https://www.atlassian.com/blog/announcements/remote-mcp-server
- Linear MCP server: https://linear.app/docs/mcp
- Notion API and MCP: https://developers.notion.com/
- Cloudflare MCP servers on Workers: https://blog.cloudflare.com/model-context-protocol/
- W3C Web Machine Learning Community Group, WebMCP Draft: https://webmachinelearning.github.io/webmcp/
- Google, Agent Payments Protocol (AP2), donated to FIDO Alliance 28 April 2026: https://ap2-protocol.org/
- Linux Foundation, x402 Foundation (2 April 2026): https://x402.org/
- SE Ranking, llms.txt analysis (~300,000-domain study): https://seranking.com/blog/llms-txt/