How We Took Lumière PayCheck From 27 to 80 on Agent Readiness in One Day

AI agents don't find software the way people do. They don't scroll a homepage; they look for small machine-readable files in predictable places. Yesterday we ran lumierepaycheck.org through isitagentready.com, a free scanner that checks a site against the emerging agent standards, and scored 27 out of 100. By the evening we were at 80, "Level 5: Agent-Native." Here is exactly what we added, what each piece does, and what we deliberately skipped.

Why it matters for an x402 company

Lumière PayCheck checks x402 endpoints before an AI agent pays them. Our users are agents as much as people. If an agent can't discover our MCP server, our API or the right way to call us, it pays an endpoint without checking first, which is the exact problem we exist to prevent. So being easy for agents to find isn't a nice-to-have for us; it's distribution.

Discovery: telling agents where things are

Link headers on the homepage. Every response from our homepage now carries a Link header (RFC 8288) pointing to our API catalog, OpenAPI spec, docs, MCP server card and llms.txt. An agent that only fetches the homepage learns where everything else lives.

An API catalog at /.well-known/api-catalog (RFC 9727): a small linkset that says where the API description, documentation and health check are.

An ARD manifest at /.well-known/ard.json (Agentic Resource Discovery): one file listing what an agent can use here, our MCP server, our REST API and our paid x402 routes, each with a few example queries such as "is this x402 endpoint safe to pay."

A DNS record. DNS for AI Discovery lets an agent find services through DNS alone. We added one SVCB record at _mcp._agents.lumierepaycheck.org pointing at our MCP server. Our zone was already signed with DNSSEC through Cloudflare, so this took two minutes.

MCP: describing the server before anyone connects

An MCP Server Card. This file describes an MCP server (name, purpose, URL, supported protocol versions) so directories and agents can index it without connecting first. The format is still a draft and has moved: the current proposal puts it next to the endpoint (/mcp/server-card) and lists no tools, while older drafts and scanners read /.well-known/mcp/server-card.json and expect the tool list. We serve both. The tool list is generated from the live server, so it can't drift out of date.

Teaching agents how to use us

An Agent Skill. We publish one skill, check-x402-before-paying, listed in /.well-known/agent-skills/index.json with a SHA-256 digest. It's a short instruction file an agent can install: when you get a 402 quote, send the URL, amount and payTo wallet to our free check-payment endpoint, pay only if the answer is allow, and report back afterwards. Of everything we added, this is the piece we expect to matter most, because it turns "PayCheck exists" into "here is the habit."

WebMCP on the homepage. Our "check an endpoint" form now carries WebMCP attributes, so a browser-based agent can use it as a tool directly instead of guessing at the page.

Content and crawler rules

Markdown for agents. A request for our homepage with Accept: text/markdown now returns a clean markdown summary instead of HTML, the same content as our llms.txt.

Content Signals in robots.txt. We declared search=yes, ai-input=yes, ai-train=yes. We want assistants to know PayCheck exists and to recommend it. The bulk data itself has a paid route, so crawlers that want all 116,000 endpoint grades can buy them over x402 at /v1/catalog instead of scraping pages one by one.

What we skipped, and why

The remaining failures are OAuth discovery, OAuth Protected Resource metadata and auth.md. They tell an agent how to sign in, and PayCheck has nothing for an agent to sign in to: the checks are free and keyless, and paid routes use x402, where the payment is the access. Publishing sign-in metadata for a login that doesn't exist would send agents looking for it and failing. If we later let teams connect their PayCheck workspace inside Claude or ChatGPT, those files will come with that feature.

The scanner also reports that it didn't detect x402 on our site, which is a little ironic. It looks for a 402 response on the homepage and on /api; our paid routes live under /v1. We're not going to make our homepage charge visitors to pass a check.

The checklist

If you run an API or an MCP server, these are the cheapest wins, roughly in order of effort:

• Content-Signal line in robots.txt (one line)
• Link headers on your homepage (one header)
• Accept: text/markdown on your homepage, reusing your llms.txt
• /.well-known/api-catalog pointing at your OpenAPI spec
• An MCP Server Card at both locations if you run an MCP server
• One Agent Skill that teaches the single most important call to your API
• An ARD manifest listing what you offer
• A DNS-AID record if your DNS is already DNSSEC-signed

Most of these are a few dozen lines each. The hardest part is knowing they exist.

You can check any x402 endpoint for free at lumierepaycheck.org, or add our skill and MCP server to your agent so it checks before every payment.