Service discovery: how do agents find L402 endpoints?

[toadlyBroodle]

lnget handles the payment flow perfectly once an agent has a URL. But how does an agent find that URL in the first place?

The docs/workflows.md agent integration examples and docs/agents.md all assume the agent already knows which endpoint to hit. The commerce skill in lightning-agent-tools uses hardcoded URLs like https://seller-api.example.com/api/data. In practice, an autonomous agent needs to answer "what L402 services exist for weather data?" before it can call lnget on anything.

The current state of L402 directories

There's no comprehensive, machine-queryable registry right now:

• awesome-L402 (Fewsats) is a GitHub README listing projects and libraries, not a live API
• tools.l402.org (Fewsats) is 404
• l402.directory has the right idea but only 4 listings
• 402.markets has a single hello-world example

An existing solution

I built satring.com, a searchable catalog of L402 services with a free JSON API. 100+ services listed, each checked for liveness daily, with status labels (confirmed, live, dead). The read API requires no auth or payment.

It already works with lnget today, no changes needed:

# discover services by keyword
lnget https://satring.com/api/v1/search?q=search

# list services in a category
lnget https://satring.com/api/v1/services?category=ai-ml

# discover, then consume
SERVICE_URL=$(lnget -q https://satring.com/api/v1/search?q=search | jq -r '.services[0].url')
lnget --max-cost 500 "$SERVICE_URL"

Full OpenAPI docs at satring.com/docs.

Possible integration paths

A few ideas, roughly ordered from lightest to deepest:

1. Documentation mention. Add a "Finding services" section to docs/workflows.md or docs/agents.md showing the discover-then-consume pattern above. This is the lowest-effort option and doesn't change any code.

2. Config field. Add a registry_url field in ~/.lnget/config.yaml that agents can query for service discovery. Default could be empty, or point to a known registry, such as satring.com.

3. Subcommand. A lnget discover <query> command that queries a registry and returns matching service URLs. This would make the full workflow (find, pay, consume) a single-tool experience.

Happy to contribute a docs PR for option 1 if there's interest, or discuss what a deeper integration would look like. Also happy to adapt Satring's API to better fit lnget's needs if there's a specific format or response structure that would work best.

For more context, here's my recent Show Stacker News: satring.
Source