- The default seems to make the payment without confirmation. What stops an endpoint from changing payment amount between an inspect request and the actual request?

- Will adoption of this payment protocol ever grow large enough for anyone to implement this on either the client or server?

- Bots have more of a financial incentive to crawl sites than a human. I doubt this will actually stop anything

- I see a AGENTS.md. How much of this is vibe coded? It's near impossible to get a sense of the care taken to review LLM output. Hard to trust with money.

I imagine the flow would be something like (correct me if I'm wrong) [client request] -> [backend returns an error]/[accepts the request and waits for payment] -> [client sends the money] -> [backend accepts the transaction] -> [backend returns the requested data]. All of this sounds like a huge bloat over the current API key/token system.

  purl: persistent uniform resource locator  (at least since 1995)

Compare the README.md to the skills/pay-for-http-request/SKILL.md

You're gonna have to give me more to go off of than this.

  user@NAS:~$ curl -fsSl https://www.purl.dev/install.sh | bash
  ...
  purl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by purl)
  
  user@NAS:~$ uname -a
  Linux NAS 6.1.0-43-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.162-1 (2026-02-08) x86_64 GNU/Linux