"Agent-callable" gets thrown around like everyone agrees what it means. They don't.

I've seen "agent-ready" APIs that require a SaaS dashboard login to mint a key. I've seen "MCP-compatible" listings that 404 when an agent actually tries them. The phrase is doing real work in marketing copy and zero work as a technical claim.

So here's a checklist. Five tests. If your endpoint passes all of them, an LLM with a tool-use loop can find it, price it, call it, and parse the response without a human in the chat.

Test 1: cold curl

Open a fresh terminal. No env vars, no cached cookies, no API key. Run curl against the documented URL with the documented payload.

If you get back a useful response (or a 402 with a payment challenge an agent can satisfy), you pass. If you get 401 because the docs assume a key you've already minted in a dashboard, you fail. If the curl example in your docs has YOUR_API_KEY_HERE in it, you fail.

x402 makes this easy. 402 + Accept-Payment header is the cold-start handshake. The agent reads the price, signs an EIP-3009 authorization, retries, gets the data. No human touched anything.

Test 2: structured discovery on the page

View source on your endpoint's landing page. Look for <script type="application/ld+json">.

You want a JSON-LD block with a WebAPI or Action schema. Inputs typed. Outputs typed. Price stated in a machine-readable field, not buried in marketing copy. Bonus points for OpenAPI links and an x402 extension block.

If your only metadata is <meta name="description">, you're a website. Not an API surface.

Test 3: schemas that actually validate

Run your own input example through your own JSON Schema. Then run the response through the output schema. Both should pass without warnings. 

ajv validate -s schema.json -d examples/input.json
curl -s $URL -d @examples/input.json | ajv validate -s response-schema.json

This sounds insulting until you check. A lot of "schema-documented" endpoints fail their own examples because the docs got edited and the schema didn't. Or the schema has "type": "object" and nothing else, which validates everything and tells the agent nothing.

The bar. An agent should be able to construct a valid request from the schema alone, with no prose. And it should know, from the schema, which response fields are guaranteed.

Test 4: MCP can find it

If your endpoint isn't in any MCP catalog, a hosted agent isn't calling it. Period.

Coinbase x402 directory. Bankr. Whatever catalog your audience uses. Submit. Wait for the listing to appear. Then ask Claude or ChatGPT, with MCP enabled, to look up your endpoint by capability ("find me an API that does X"). If they can't surface it, production agents won't either.

This is the test most "agent-ready" launches skip. They ship the endpoint, write a blog post, and assume agents will read the blog post. Agents read catalogs.

Test 5: price is a number, not a sentence

$0.005 per call on your pricing page is a sentence. An agent has to LLM-parse it, and the parse might be wrong. 

HTTP/1.1 402 Payment Required
Accept-Payment: x402/usdc-base
X-Payment-Amount: 0.005
X-Payment-Recipient: 0xabc...

That's a number. The agent doesn't think about it. It just signs.

Same content, different surface. The first puts a model inference between the agent and the call. The second is a function signature.

Use the checklist

Five tests. None of them takes more than a minute. Run them against your own endpoint before you ship the "agent-callable" tweet.

And if you're a buyer evaluating a vendor that claims agent support, run the checklist on theirs. Most will fail at least two of the five. Some will fail all five and still have a "for AI agents" banner on the homepage.