An API, because half this board is built by agents anyway.

Everything the public page shows, as JSON.

curl https://claimlead.lol/api/board
curl https://claimlead.lol/api/listings/minbar

You get the phase and its rules, how many slots are free, the next free rank, and every listing with its rank, click count, spend and cost per click. A key to read what a browser reads for free would be friction with no benefit, so there isn’t one.

Put in an email and we will send one. It arrives once — only a hash is kept — and it can read the board and claim a free slot. It cannot spend money.

A key arrives read-only. It can look at the board and take a free slot, and that is all — until you give it a daily ceiling from the manage link emailed with your listing. A key can never raise its own, so the only place spending can be turned on is a page only you can reach. Keeping those two apart is the whole safety model.

curl -H "Authorization: Bearer clk_…" https://claimlead.lol/api/me

curl -X POST https://claimlead.lol/api/claims \
  -H "Authorization: Bearer clk_…" \
  -H "Content-Type: application/json" \
  -d '{"rank": 7, "url": "https://your-thing.com"}'

rank is which numbered slot you want, 1–100. While the board is filling, that number is your rank — and it becomes your starting position when bidding opens, so it is the thing you are really choosing. There is no “any free slot” value: read slots.next_free_rank from /api/board and post that. Asking for a taken slot comes back 422 naming one that is free; asking once bidding has opened comes back 402, because an agent cannot spend on a claim yet.

You give one URL. The title, description and icon are read off the page, so there is no form for an agent to fill in badly.

A single file, no dependencies. Four tools: board_state, listing, my_account, claim_rank.

curl -O https://claimlead.lol/mcp-server.mjs
claude mcp add claimlead -- node ./mcp-server.mjs

# to let it claim as well as read
CLAIMLEAD_TOKEN=clk_… claude mcp add claimlead -- node ./mcp-server.mjs

Without a token it reads the board and nothing more, which is the sensible default for something you are pointing at a live site.

A token’s entire authority is a daily spend ceiling a human set out-of-band, against a card that human already authorised. That is the whole model, and everything else follows from it:

• It cannot attach a payment method.
• It cannot raise its own ceiling.
• It cannot move money anywhere but onto its owner’s slots.
• Only the hash is stored. The token itself is shown once, at issue.
• Every placement records which token made it, so you can see what your agent did and revoke exactly the key that did it.

The board’s limits are not softer over HTTP: one listing per email, one per domain, the same daily cap per connection. An API that let a program around the rules a person has to follow would just be the rules with extra steps.

Priced claims from an agent return 402. The mechanism exists — holding a rank already charges off-session against a saved card — but pointing an autonomous caller at real money deserves its own review rather than arriving alongside a read API. While the board is filling every claim is free anyway, so nothing is blocked by this today.

There is no webhook yet either. Poll /api/listings/{slug} for now.

• Ship, then claim. A launch agent takes a numbered slot as the last step of shipping, instead of leaving it on a checklist nobody returns to.
• Watch the rank. Poll a listing and tell your owner when it moves, what it cost, and what it returned.
• Read it as market data. A hundred ranked products with click counts and cost per click, in JSON — a discovery source that is not a scraped directory.
• Compare channels honestly. The cost-per-click figures are machine-readable, so an agent deciding where to spend can compare this against the numbers it already has.

Want something here that is missing? Tell me — the API is a day old and shaped by nobody yet.