Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nohumans-mcp Find me paid APIs for sentiment analysis that cost under $0.001 and have high reliability"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Find and vet paid x402 APIs and datasets before an agent spends money on them.
nohumans.directory is a registry of pay-per-call APIs that AI agents can buy with USDC. Every listing is probed for a valid payment request (a live x402 endpoint answers an unpaid request with HTTP 402), and many listings are bought with real USDC on Base: the outcome is published with its settlement transaction, including purchases that took the money and did not deliver. Placement in results is never sold.
All tools are free and read-only. No API key, no account. The directory never moves money: any payment happens in your own agent, under the seller's terms.
Website: https://nohumans.directory · Live stats: https://nohumans.directory/stats · API reference for agents: https://api.nohumans.directory/llms.txt
The server is remote: Streamable HTTP, no authentication.
https://api.nohumans.directory/mcpClaude Code:
claude mcp add --transport http nohumans https://api.nohumans.directory/mcpClients that read an mcpServers block with remote servers:
{ "mcpServers": { "nohumans": { "type": "http", "url": "https://api.nohumans.directory/mcp" } } }Clients that only run local (stdio) servers: use the nohumans-mcp
npm package, a small bridge to the same server (no dependencies, Node 18+):
{ "mcpServers": { "nohumans": { "command": "npx", "args": ["-y", "nohumans-mcp"] } } }The bridge is index.mjs in this repository: one file, no dependencies, published to npm as
nohumans-mcp. NOHUMANS_MCP_URL overrides the endpoint.
Setup lines for Cursor, VS Code, ChatGPT, Gemini CLI, the OpenAI Agents SDK and LangChain: https://nohumans.directory/integrate#connect
Related MCP server: x402-discovery
Tool | What it does |
| Search by need: |
| One listing's full record by |
| Check an endpoint |
| The aggregate demand feed: what agents search this directory for. For sellers deciding what to build or list. |
What the main fields mean (status, score, paid_verified, latest_purchase_delivered,
evidence_tier) and the rules an agent should follow before paying:
https://nohumans.directory/integrate#rules
For agents that support Agent Skills (Claude Code and others):
mkdir -p ~/.claude/skills/nohumans-directory
curl -o ~/.claude/skills/nohumans-directory/SKILL.md \
https://raw.githubusercontent.com/jalcodev/nohumans-mcp/main/skills/nohumans-directory/SKILL.mdList it at https://nohumans.directory/submit (check it free first). What it costs and what you get: https://nohumans.directory/sellers. Notes for submitters: SUBMITTING.md.
How listings are probed, bought and scored, with every correction and rule change: https://nohumans.directory/methodology
Contents of this repository: MIT. Directory data: CC BY 4.0, credit "nohumans.directory" with a link.
Search paid x402 APIs and datasets by need. Ranked: verified first, then probe score, then price. Each result carries what you choose on: status, score (0..1), evidence_tier, paid_verified (we bought it with real USDC and it delivered), latest_purchase_delivered (false = our most recent paid purchase took real USDC and did not deliver: do not pay it), has_sample (a cheap preview exists), price. Relevance comes from the query text; a specific need in plain words matches best. Zero results means nothing listed matches. Results are dated evidence, not guarantees. Returns a summary per listing; detail='full' returns every field. Free, read-only.
Inputs: limit, query, detail, category, +4 more. Returns: count, detail, results, category_expanded
Full record for one listing id: request and response schemas, sample_query, observed 402 terms (network, payTo, scheme, x402 version), reputation detail, and paid_verification (our latest real USDC purchase, with its settlement tx where proven). Useful before paying: it shows the exact request shape and current reliability. Every timestamp has an _iso twin; on-chain counts describe the seller's wallet, usually shared by several listings, not this endpoint. Free, read-only.
Inputs: id (required). Returns: id, kind, name, score, +53 more
Check an endpoint URL you already hold before paying it. Returns match 'active' with the listing's full record, 'delisted' (listed here, later removed), or 'unknown' (never checked here; absence is not a verdict either way). The record is dated evidence, not a safety rating. Free, read-only.
Inputs: url (required). Returns: note, match, detail
What agents searched this directory for, for deciding which x402 service to build or list. Terms ranked by how many distinct days they were asked, each with catalogue_top: the listings our own search already returns for it. A term being asked does not mean nothing serves it. The window ends a week behind live while the paid tier is on sale (a day when it is not; delay_hours and window_ends_at in the response say which); test traffic, sellers searching their own listings and identifying terms are excluded; floor: a term appears once at least 1 distinct non-seller client IP asked it. Client counts are IP ceilings, never buyer counts. Paged: limit (default 25), offset, next_offset. Free, read-only.
Inputs: limit, offset. Returns: note, page, top_needs, read_first, +11 more
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 4 tools
Each tool has a clear primary axis: search by need, fetch by id, resolve by URL, and read aggregate demand terms. The only friction is between get_service_details and resolve_endpoint, since resolve_endpoint also returns 'the listing's full record' for a known URL, so an agent holding both an id and a URL could hesitate between them. Descriptions do enough to resolve this in practice.
Three tools follow a clean verb_noun snake_case pattern (find_paid_service, get_service_details, resolve_endpoint). The fourth, what_agents_are_asking_for, breaks the pattern with a full question-phrase name, which is memorable and readable but inconsistent with the rest of the set.
Four read-only tools for a directory search/vetting server is tight and well-scoped, with no filler tools. It sits near the thin end of the range, and a couple of capabilities (e.g. listing/comparing) are absent rather than extra.
The discover → inspect → verify lifecycle is covered: search, detail by id, resolve an externally held URL, plus a seller-side demand signal. The obvious gap is that the surface is purely read-only — there is no tool to submit/register a listing or to actually probe/sample a paid endpoint, which the descriptions repeatedly gesture at ('has_sample', 'a cheap preview exists') without exposing.
Find and vet x402 payment APIs before your agent pays one: uptime, price, on-chain volume.
Find and live-check the paid x402 API for an agent task, ranked by real 30-day payers and price.
Receipts-verified reviews of x402 services and paid APIs, before your agent pays.
Receipts-verified reviews of x402 services and paid APIs, before your agent pays.
