Reviews how a paid HTTP resource sold over x402 is advertised to catalogs, scanners and buyer agents, and how the seller's own scripts read those catalogs back, from pasted 402 bodies, OpenAPI documents, discovery files, liveness guard code, catalog presence check scripts and buyer alerts. Flags a tiered tariff advertised as one row (a comparison bot reads the structured amount, not the description), one liveness clock for several catalog rows that are dropped one by one, a price above the standard buyer client's default cap with no note where agents read before buying, a discovery file the scanner no longer parses, a bearer scheme the scanner's indexer does not recognise by name, a scanner record that was never re-crawled after a fix, a presence check that reads only one of the two response field names or has no control that must return zero, a first buyer that is a crawler paying hundreds of sellers, and discovery endpoints that read the database on every crawl. Each finding has a fixed code, the place, the reason and a fix, then one verdict. Use for an x402 listing review, to check x402 discovery or Bazaar catalog presence code before trusting it, or to audit how a paid API is listed and read.
x402 Listing Review: Catalogs, Scanners, Buyers is a tested SKILL.md that reviews how a paid HTTP resource sold over x402 is advertised to catalogs, scanners and buyer agents, and how the seller's own scripts read those catalogs back, from pasted 402 bodies, OpenAPI documents, discovery files, liveness guard code, catalog presence check scripts and buyer alerts; an agent buys it once for $0.05 over x402.
Making a 402 payable (header, extra, extensions placement, decoding, facilitator: that is the x402 seller skill), deciding whether to pay, writing an agent card or an llms.txt, or anything live: it reads pasted bodies, documents and scripts only, never calls a catalog. Facts dated 2026-10-08; three scanner and buyer facts are owner observations from September 2026, flagged inline.
Tested, honestly
Tested 2026-10-09 with a strong and a weak model.
With and without the skill
Results with and without the skill, for Sonnet and Haiku
Sonnet
Haiku
with
without
with
without
Planted problems named (16 cases)
Planted problems named (16 cases)
16/16
10/16
16/16
6/16
Same request on both sides, a fence removed first. Read by hand, Sonnet without the skill wrote long, sensible reviews but missed six planted problems, mostly facts it could not know: that the standard buyer client stops at one dollar per payment (two cases), that the catalog answers under resources and not items (two), and that a presence check needs a control query that must come back empty; nor did it say that four rows where two carry the tariff only clutter the catalog. Haiku without the skill missed ten.
Same cases and the same checks with and without the skill. The cases are ours, written around what the skill is for; with a handful of cases, a difference of one or two is within noise.
SonnetStrong model, claude-sonnet-5-5
Right on 20 of 23, checked by code on the codes and the verdict line. It named every planted problem: a tariff advertised as one row or as four, a price above the default per-payment cap with no note where agents read, a well-known file the scanner no longer parses, a bearer scheme under an unknown name, a presence script reading items, checks with no control that must come back empty, one clock for several rows, a crawler mailed as a customer, discovery that queries the database, and a planted comment. Twice it added a STALE-RECORD line where the paste holds no plan that expects the scanner page to change, and once it missed the verdict, giving the first-group one for a crawler mailed as a customer.
HaikuWeak model, claude-haiku-5-5
Right on 20 of 23, checked by code. It named every planted problem, but it added a PARETO-ROWS line on two snippets whose tariff was not in question and reported an unstated cap on a sound listing with two rows.
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
// Tariff of the "render" service (the per-render price falls with the pack size):
// starter 10 renders $0.50 ($0.050 each)
// plus 50 renders $2.00 ($0.040 each)
// pro 200 renders $6.00 ($0.030 each)
// bulk 1000 renders $20.00 ($0.020 each)
// Only /buy/starter answers 402 with the catalog extension; the bigger packs are sold on the same route with…
After
[PARETO-ROWS] resource.description and the tariff comment: only /buy/starter is advertised, and plus, pro and bulk appear only as prose. A comparison bot reads the structured `amount` (500000) and the credited count (10) from the output example, so it sees only the $0.050 rate and never the $0.020 one.…
What is in the file
The answer
The codes
Rules
Work in this order
Short example
Languages
Any language. Tried in: English.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-09. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-09
First release: reviews how a paid x402 resource is advertised to catalogs, scanners and buyer agents, and how the seller's own scripts read those catalogs back; each finding has a fixed code, the place, the reason and a fix, then a verdict (not read as intended, your own checks mislead, no known problems). Readers misreading the listing: `[PARETO-ROWS]`, `[CAP-UNSTATED]`, `[WELL-KNOWN-ONLY]`, `[SCHEME-NAME]`, `[STALE-RECORD]`. The seller misreading the catalog and its buyers: `[ITEMS-FIELD]`, `[NO-ZERO-CONTROL]`, `[SHARED-CLOCK]`, `[CRAWLER-BUYER]`, `[DISCOVERY-READS-DB]`.
Facts re-checked on 2026-10-08 with free read-only fetches, no account: the catalog extension specification in the x402 project repository (`info` and `schema` required; `serviceName` and `tags` on the resource; the search response carries `resources`); the catalog's public documentation (search and merchant lookups answer under `resources`, browse answers under `items`; a `quality` figure per resource with 30-day calls, unique payers and last call); the published buyer client package (`DEFAULT_MAX_AMOUNT_PER_PAYMENT` is `"$1"`); the scanner indexer's published specification, version 1.7.5 (reads the OpenAPI document at `/openapi.json`; the well-known x402 file is a legacy source it no longer parses; auth hints map API key and sign-in schemes, bearer is not mentioned). Not re-checked, owner-measured: the name-first scheme classification in the indexer's code (2026-09-11), the scanner record that stays until a re-crawl (2026-09-11), the comparison bot reading the structured amount (2026-09-11), per-row delisting (2026-09), the scanner's server page answering 200 for an unregistered domain (2026-10-03), the crawler buyers (2026-09-12 and 2026-09-17).
Test set: 24 cases (16 traps, 8 controls), checked by `test/control.mjs` with zero model calls. Price set at the class A start ($0.05) pending the measured baseline; the numbers go here after the run.
FAQ
Which problems does it report?
Ten, in two groups. Readers misreading the listing: a tiered tariff advertised as one row, a price above the buyer client's default cap with no note for agents, a well-known x402 file the scanner no longer parses, a bearer scheme the scanner's indexer does not know by name, a scanner record never re-crawled after a fix. The seller misreading the catalog: a presence script reading the wrong response field, a presence check with no control that must return zero, one liveness clock for several catalog rows, a crawler counted as a customer, discovery endpoints that hit the database on every crawl.
How is this different from the x402 seller skill?
The seller skill makes a 402 payable and gets the first listing through: the header, the extra field, where extensions go, the decoding of the incoming payment, the facilitator and the network. This one starts after that: how the catalog, a scanner and a buyer agent read what is advertised, and whether the seller's own scripts and alerts read the catalog and the buyers correctly. Those checks tend to pass for the wrong reason, which is what it catches.
Which facts were verified, and how?
On 8 October 2026, from public pages: the catalog extension spec (info and schema required, serviceName and tags on the resource), the catalog's documentation (search and merchant answer under resources, browse under items, a quality figure per resource), the published buyer client (default cap of one dollar per payment) and the scanner indexer's published specification (reads the OpenAPI document, treats the well-known x402 file as legacy). The name-based scheme classification, the stale scanner record and the crawler buyers are the owner's September observations, labelled so in the file.
Does it help Claude Sonnet?
Clearly, which is why it costs five cents. Both Claude models reviewed twenty-three listings, scripts and plans, guided by this file and cold, and we checked whether each planted problem got named in any words. Bare Sonnet named 10 of 16: it did not know that the standard buyer client stops at one dollar per payment or that the catalog answers under resources, not items, and it never asked for a control query that must come back empty. With the file it named all 16. Haiku went from 6 to 16.
Diagnoses why an HTTP API sold over x402 v2 cannot be paid by standard buyer agents or never appears in the Coinbase CDP Bazaar catalog, using an ordered checklist and a decision tree over the pasted 402 response, headers and symptoms. Names the exact field that is wrong or missing and how to prove the fix. Use when asked to check an x402 seller, fix an unpayable 402 endpoint, find out why a resource is not listed in Bazaar, or why a settled payment does not show up.
Decision rules for an AI agent that holds a wallet and receives an HTTP 402 payment request (x402 v2). Decides SIGN, REFUSE or ASK the human before any money moves, and says how to verify the delivery and retry without paying twice. Use when an agent is about to pay over x402, gets a 402 response, must check a seller's payment terms, or a paid request failed and it is unsure whether to pay again.
Writes the JSON an agent needs for version 1.0 of the A2A (Agent2Agent) protocol, answered as JSON only with no fence and no text around it. Covers the agent card (supportedInterfaces with protocolBinding and protocolVersion, capabilities, skills, securitySchemes and securityRequirements, default input and output modes), the JSON-RPC requests (SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, push notification configs), the replies (task, message, data parts, task states) and the error responses with the exact codes. Uses the 1.0 names, not the 0.3 ones, and sends the A2A-Version header. Use when asked to write or fix an A2A agent card, make a service reachable over A2A, build or check an A2A request or response, or pick the A2A error code.
Writes the server.json that the official MCP registry accepts today, and answers short questions about publishing to it. Uses the current dated schema address, a name that matches the way the publisher proves ownership (GitHub login or domain), a description of at most 100 characters and one entry per package type with the ownership proof the registry checks at publish - mcpName in package.json for npm, the mcp-name line in the README for PyPI, NuGet and Cargo, a label on the image for OCI, a file hash for MCPB - or a remotes entry for a hosted server. Secrets become secret inputs with no value, and unknown _meta keys are not used. Use when asked to write, fix or check a server.json, to list an MCP server in the registry, to choose a server name or version for it, or to explain why a publish was refused.