The Complete Guide to Making Your SaaS Agent-Discoverable:
llms.txt, mcp.json, and Google ARD

Three Specs, One Problem

Here's the situation. You run a SaaS product. You have an API. Maybe you even published an MCP server. But when someone tells Claude or ChatGPT "do X with my accounting software," your product doesn't come up.

The reason isn't that your API is bad. It's that AI agents don't know your API exists — or they can't figure out what it does fast enough to choose it over a competitor.

Three new standards are trying to fix this problem. They emerged independently, from different organizations, solving different pieces of the same puzzle:

• llms.txt — proposed by Jeremy Howard (fast.ai / Answer.AI) in late 2024. A Markdown file at your website root that tells AI models what your service does. Think of it as robots.txt for the AI era.
• MCP Server Card (mcp.json) — being developed within the MCP working group. Machine-readable metadata about your MCP server: what tools it offers, how to authenticate, what it's for.
• Google ARD (Agentic Resource Discovery) — part of Google's Agent2Agent (A2A) protocol initiative. A way for agents to discover and use APIs at runtime, without a human reading docs first.

Each of these has its own website, its own community, and its own adoption curve. Nobody has written a guide that explains all three in one place and helps you decide what to implement. That's what this article is.

The Agent Discoverability Stack

These three standards aren't competing. They operate at different layers of the same stack:

llms.txt sits at the bottom. It's the broadest — any website can have one, regardless of whether you have an MCP server or API. It answers: "What does this service do?"

mcp.json is the middle layer, specific to MCP. If you've published an MCP server, this file tells agents and registries what your server offers. It answers: "What tools does this MCP server have?"

Google ARD is the top layer, focused on runtime API discovery between agents. It answers: "How can another agent use this API right now, without reading docs?"

You don't need all three on day one. But understanding where each fits helps you plan.

llms.txt — Making Your Website AI-Readable

What it is

llms.txt is a plain text file written in Markdown, placed at the root of your website. When an AI model or agent visits your site, it can read this file to quickly understand what your service does, what its key features are, and where to find documentation.

The analogy to robots.txt is deliberate. Just as robots.txt tells search engine crawlers how to interact with your site, llms.txt tells AI models how to understand your service. But where robots.txt is restrictive ("don't crawl this"), llms.txt is informative ("here's what we do").

Why it matters

AI models have a context window. They can't read your entire website, documentation, and blog to figure out what you do. llms.txt gives them a pre-digested summary — the equivalent of a human reading your "About" page and top-level docs in 30 seconds.

Without llms.txt, an AI model relies on its training data (often months old) and whatever it can scrape from your homepage. With llms.txt, it gets a current, authoritative description straight from you.

How to implement it

Create a file at yoursite.com/llms.txt with this structure:

# InvoiceFlow

> InvoiceFlow is a cloud invoicing platform for small businesses.
> Create, send, and track invoices. Automate payment reminders.
> Integrates with Stripe, QuickBooks, and Xero.

## Key Features

- [Create Invoices](https://invoiceflow.com/docs/invoices): Generate PDF invoices with line items, tax, and payment terms
- [Payment Tracking](https://invoiceflow.com/docs/payments): Track payment status and send automated reminders
- [Integrations](https://invoiceflow.com/docs/integrations): Connect with Stripe, QuickBooks, Xero, and 20+ accounting tools
- [API Reference](https://invoiceflow.com/docs/api): RESTful API for programmatic invoice management

## Getting Started

- [Quickstart Guide](https://invoiceflow.com/docs/quickstart): Create your first invoice in 5 minutes
- [Authentication](https://invoiceflow.com/docs/auth): API key and OAuth2 setup
- [MCP Server](https://invoiceflow.com/docs/mcp): Connect AI agents via MCP

Key principles:

• Start with a one-liner. The blockquote (> line) is your elevator pitch. AI models read this first.
• Use action words. "Create, send, and track invoices" — not "invoice management solution."
• Link to real docs. Every bullet should have a URL. The AI can follow these if it needs more detail.
• Keep it short. llms.txt should fit in a model's context window comfortably. Under 500 lines.

llms.txt vs llms-full.txt

The convention includes an optional companion file: llms-full.txt. This is the expanded version — full documentation content, detailed API references, example code. The agent reads llms.txt first to decide if the service is relevant, then fetches llms-full.txt for deep implementation detail.

Start with llms.txt. Only create llms-full.txt if your docs are complex enough to warrant it.

MCP Server Card (mcp.json) — Metadata for Your MCP Server

What it is

MCP Server Card is a proposed standard for machine-readable metadata about an MCP server. If llms.txt describes your website to AI models, mcp.json describes your MCP server to agent platforms and registries.

Think of it as package.json for MCP servers. One file that tells everything: who made this server, what it does, what tools it exposes, how to authenticate, what transports it supports (stdio, HTTP+SSE, Streamable HTTP), and what version it's on.

Why it matters

Right now, MCP server metadata is scattered. Your server's name and description live in the server manifest. Your authentication requirements live in your README. Your tool list lives in the code. There's no single, machine-readable file that an agent or registry can fetch to understand everything about your server.

When mcp.json stabilizes, it will be the file that registries like Smithery, Glama, and the Official MCP Registry read to categorize, index, and present your server to agents.

What to expect in the spec

While the final specification is still being drafted, early implementations and working group discussions point to these fields:

{
  "name": "invoiceflow-accounting",
  "displayName": "InvoiceFlow",
  "description": "Create, send, and track invoices for small businesses. Supports PDF generation, payment reminders, and integration with Stripe, QuickBooks, and Xero.",
  "version": "1.2.0",
  "author": {
    "name": "InvoiceFlow Inc.",
    "url": "https://invoiceflow.com"
  },
  "repository": "https://github.com/invoiceflow/mcp-server",
  "transports": ["stdio", "streamable-http"],
  "authentication": {
    "type": "oauth2",
    "docsUrl": "https://invoiceflow.com/docs/auth"
  },
  "tools": [
    {
      "name": "create_invoice",
      "summary": "Create and send a PDF invoice to a client"
    },
    {
      "name": "list_invoices",
      "summary": "List all invoices with optional status filter"
    },
    {
      "name": "track_payment",
      "summary": "Check payment status and send reminders"
    }
  ],
  "categories": ["accounting", "invoicing", "billing"],
  "pricing": "freemium",
  "rateLimits": {
    "requestsPerMinute": 60
  }
}

Google ARD — Agentic Resource Discovery

What it is

ARD (Agentic Resource Discovery) is Google's approach to letting AI agents discover and use APIs at runtime. Where llms.txt is a static file and mcp.json is server metadata, ARD is a protocol — a way for one agent to ask another "what can you do?" and get a machine-readable answer, live.

ARD is part of Google's broader A2A (Agent-to-Agent) initiative, which defines how AI agents communicate with each other. The core idea: agents shouldn't need a human to read API documentation. They should be able to discover, negotiate, and use APIs through standardized machine-to-machine protocols.

Why it matters

llms.txt and mcp.json are fundamentally static — you write them once, update them when features change. ARD is dynamic. An agent can query an ARD endpoint and get the current list of available capabilities, including any that were added since the last static file was published.

For SaaS companies operating at scale with rapidly evolving APIs, this matters. If you deploy a new feature on Monday, ARD-compatible agents can discover it on Monday. With llms.txt, the file needs to be manually updated.

What to do about it now

ARD is the earliest-stage of the three standards. For most SaaS companies, the immediate action is:

• Ensure your API has a clean OpenAPI (Swagger) specification. ARD builds on existing API description standards. If your OpenAPI spec is well-written, you're already partially prepared.
• Watch the A2A protocol development. Google's A2A GitHub repo tracks the evolution.
• Don't build for ARD yet unless you're in the Google Cloud ecosystem and have a direct need. Focus on llms.txt and your MCP server descriptions first.

Side-by-Side: Which Standard Does What

Case Study: Shopify's Full-Stack Approach

Shopify's May 2026 MCP integration is the clearest example of comprehensive agent discoverability in practice.

What Shopify did:

• MCP as a platform feature. Not a third-party plugin or community project — Shopify built MCP support directly into the platform. Any Shopify store can be accessed by AI agents through their official MCP server.
• llms.txt on their docs site. Shopify deployed llms.txt on their developer documentation, giving AI models a structured summary of the Shopify platform, API capabilities, and developer resources.
• OpenAPI spec maintained. Their existing REST and GraphQL APIs have well-maintained specifications, positioning them for ARD-style discovery when the protocol matures.
• Tool descriptions optimized for agent search. Their MCP tools use task-oriented descriptions ("List all products in the store," "Create a discount code") rather than API-endpoint descriptions ("GET /admin/api/products.json").

The result: when a developer tells Claude "add a 20% discount to my Shopify store," Claude can find and use the Shopify MCP server reliably. The entire stack — from llms.txt understanding to MCP tool selection to API execution — works together.

Implementation Priority: Where to Start

If you're a SaaS company reading this and wondering what to do Monday morning, here's the priority order:

Priority 1: Fix what you already have (Today)

Before adding new files, fix the discoverability signals you already control:

• If you have an MCP server: rewrite your server description and tool descriptions using the patterns from our Tool Search guide
• If you have an API: ensure your OpenAPI spec has clear, task-oriented operation descriptions
• Check your current Agent AEO grade on KanseiLink

Priority 2: Deploy llms.txt (This week)

This is the highest-return, lowest-effort action. One Markdown file, 30 minutes of writing. It immediately improves how every major AI model understands your service. Follow the template above.

Priority 3: Prepare for mcp.json (This quarter)

Don't write a mcp.json file yet — the spec isn't stable. Instead, prepare the content:

• Write clear one-line summaries for each of your MCP tools
• Document your authentication requirements in a structured way
• Categorize your service (accounting? CRM? communication?)
• When the spec stabilizes, you'll be able to generate the file in an hour

Priority 4: Monitor Google ARD (This year)

Unless you're building specifically for Google Cloud agent ecosystems, ARD isn't actionable yet. The best preparation is maintaining a clean OpenAPI spec and following A2A protocol development.

How to Measure If It's Working

Deploying these files is step one. Knowing whether they're working is step two.

What you can measure today

• llms.txt access logs. Check your server logs for requests to /llms.txt. AI model crawlers (GPTBot, ClaudeBot, Google-Extended, PerplexityBot) will show up. If they're fetching the file, it's being read.
• MCP server selection rate. If you have analytics on your MCP server (via MCPcat or similar), track how many agent sessions include your server. Compare before and after description optimization.
• Agent AEO grade. KanseiLink rates your service on an 8-tier scale (AAA to D) based on agent discoverability. Track this over time to see if your optimization is working.

What you can't measure yet (and why it matters)

• search_miss — when agents looked for you but didn't find you. This is the blind spot. Your server logs won't show requests that never arrived. KanseiLink's Agent AEO analysis is designed to fill this gap — tracking the space between "an agent needed a service like yours" and "your server received a request."
• Cross-platform coverage. Are you discoverable on Claude's Tool Search? On OpenAI's Agents SDK? On Cursor? Each platform has its own discovery mechanism. Multi-surface monitoring is still in its infancy.

FAQ

Do I need an MCP server to benefit from llms.txt?

No. llms.txt works at the website level. Even if you only have a REST API and no MCP server, deploying llms.txt helps AI models understand what your service does. When a user asks ChatGPT or Claude about your product category, a well-written llms.txt increases the chance your service is accurately described in the response.

Is llms.txt the same as robots.txt?

No. robots.txt controls crawler access ("don't index these pages"). llms.txt provides information ("here's what we do"). They serve complementary purposes. You can have both on the same site, and you should — robots.txt to manage crawling, llms.txt to manage understanding.

Will Google use llms.txt for search ranking?

Google has not confirmed using llms.txt as a ranking signal for traditional search. However, Google's AI Overviews (Gemini-powered search results) can use llms.txt to better understand your service. For AI-generated search results — which is where the search market is heading — llms.txt is increasingly relevant.

What if mcp.json changes after I implement it?

That's exactly why the advice is "prepare your content, don't write the file yet." The description text, tool summaries, and categorization you prepare now will be valid regardless of format changes. When the spec stabilizes, assembling the JSON file from prepared content takes minutes.

Can llms.txt hurt my search ranking?

No. llms.txt is a separate file that search engines can index but treat as supplementary content. It doesn't replace or interfere with your existing SEO. Think of it as adding a new channel of discoverability, not modifying an existing one.

What about Schema.org and JSON-LD — do those matter for agent discoverability?

Yes, especially for AI-powered search. Schema.org structured data (Article, FAQPage, HowTo, Product, SoftwareApplication) helps Google AI Overviews, Bing Copilot, and Perplexity extract and cite information from your pages. This complements llms.txt — Schema.org structures individual pages, llms.txt provides a site-level overview.