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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). | |
| query | No | What you need, specifically: data, freshness, format, constraint. Drives relevance. | |
| detail | No | summary (default) or full: every field per listing. | summary |
| category | No | Optional filter: one of the most-populated categories. Omit if none fits; query text still finds long-tail ones. | |
| protocol | No | Only listings offering this payment protocol. Omit for any. | |
| max_price | No | Max price per call. Omit for no cap. | |
| min_score | No | Min probe score, 0..1 (0.8 = reliably passing). | |
| mpp_method | No | Only listings offering this MPP method, e.g. stripe, tempo, evm. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| detail | No | |
| results | Yes | |
| category_expanded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the annotations: ranking order, the meaning of paid_verified and latest_purchase_delivered, the warning not to pay when the latest purchase did not deliver, sample availability, and the caveat that results are dated evidence rather than guarantees. The annotations already declare read-only and non-destructive behavior, and the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with the core purpose front-loaded and no filler. Each sentence carries operational value: ranking, result fields, warning about failed paid purchases, relevance behavior, zero-result interpretation, and return detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with an output schema and rich annotations, this definition is complete enough to call correctly. It covers scope, ranking, key result fields, safety warnings, query behavior, and return modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all eight parameters. The description still adds useful meaning by explaining that query relevance comes from plain-language need descriptions and that detail='full' returns every field, but most individual filter semantics remain in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search paid x402 APIs and datasets by need.' It also describes ranking and result fields, which clearly separates discovery from sibling tools like get_service_details or resolve_endpoint without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains the search context, how query text drives relevance, and that zero results means no listing matches. It also implies detail='full' as an alternative to the summary return, but it does not explicitly name sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id: the id field of a search result, e.g. f094faea-d9d. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | No | |
| name | Yes | |
| score | No | |
| chains | No | |
| status | Yes | |
| category | No | |
| transport | No | |
| has_sample | No | |
| kind_notes | No | |
| obs_pay_to | No | |
| obs_scheme | No | |
| payto_note | No | |
| description | No | |
| mpp_methods | No | |
| obs_network | No | |
| probe_count | No | |
| endpoint_url | Yes | |
| price_amount | Yes | |
| report_count | No | |
| report_score | No | |
| sample_query | No | |
| x402_version | No | |
| evidence_note | No | |
| evidence_tier | No | |
| onchain_daily | No | |
| onchain_scope | No | |
| onchain_shape | No | |
| paid_verified | No | |
| probes_failed | No | |
| probes_passed | No | |
| response_mime | No | |
| last_probed_at | No | |
| onchain_wallet | No | |
| p50_latency_ms | No | |
| p95_latency_ms | No | |
| p99_latency_ms | No | |
| payto_sentinel | No | |
| payto_unstable | No | |
| price_currency | No | |
| request_schema | No | |
| distinct_payers | No | |
| response_schema | No | |
| observed_network | No | |
| paid_verified_at | No | |
| paid_verification | No | |
| payment_protocols | No | |
| status_changed_at | No | |
| latest_purchase_at | No | |
| verdict_age_seconds | No | |
| paid_verified_at_iso | No | |
| payto_distinct_recent | No | |
| latest_purchase_age_days | No | |
| paid_verification_latest | No | |
| latest_purchase_delivered | No | |
| onchain_unique_payers_30d | No | |
| onchain_payto_shared_listings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so 'Free, read-only' is largely redundant. However the description adds genuinely non-obvious interpretation context: every timestamp has an _iso twin, and on-chain counts reflect the seller's shared wallet rather than this endpoint — real behavioral detail an agent cannot infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with zero filler: contents first, then the decision-driving use case, then the interpretive caveats. Front-loaded and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, annotations cover the safety profile, and the one parameter is fully documented. The description fills the remaining gap — how to read timestamps and wallet-level counts — so nothing needed for correct interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema description coverage, including an example id, so the schema does the work. The description only restates 'one listing id' and adds no format or sourcing detail beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope — 'Full record for one listing id' — then enumerates exactly what the record contains (request/response schemas, sample_query, 402 terms, reputation, paid_verification). An agent can distinguish this from find_paid_service or resolve_endpoint without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful before paying: it shows the exact request shape and current reliability' gives a clear selecting condition and timing for invocation. It does not name a sibling as the alternative or state when to avoid this tool, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The endpoint URL as you hold it, including any query string. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| match | Yes | |
| detail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-derivable behavioral context: the three match outcomes, that 'unknown' means never checked rather than absent, that the record is dated evidence rather than a safety rating, and that the call is free. Rate limits or latency characteristics are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: the action and precondition come first, the possible outcomes second, and the interpretive caveat plus cost/read-only note last. Every sentence carries information an agent needs and none is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema and full annotation coverage, the description supplies the missing interpretive layer — what each match value means and how to read an 'unknown'. Nothing required to call it correctly or interpret it is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter at 100% schema description coverage, the schema already documents that the URL should be passed as held, including any query string. The description adds no syntax, normalization, or format guidance beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('check an endpoint URL') and scopes it precisely to a URL the caller already holds, which implicitly separates it from the discovery-oriented siblings like find_paid_service. It stops short of naming any sibling or the alternative to use instead, so differentiation requires inference rather than being explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Check an endpoint URL you already hold before paying it' gives a clear triggering context (pre-payment verification of a known URL), and the explanation of 'unknown'/'delisted' clarifies what the result means. No exclusions or named alternatives are given, so the agent must infer when to prefer find_paid_service or get_service_details instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Terms per page, in rank order. | |
| offset | No | Where to start; each reply gives next_offset. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| page | No | |
| top_needs | Yes | |
| read_first | No | |
| side_lists | No | |
| delay_hours | Yes | |
| terms_total | No | |
| window_days | Yes | |
| total_queries | Yes | |
| window_ends_at | No | |
| k_anonymity_unit | No | |
| k_anonymity_floor | No | |
| scripted_rotation | No | |
| distinct_client_ips | No | |
| top_category_filters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing the data window lag, the delay_hours and window_ends_at fields that reveal it, exclusion rules (test traffic, sellers searching their own listings, identifying terms), the minimum-distinct-IP floor, and critically that client counts are IP ceilings rather than buyer counts. This is exactly the interpretive context an agent needs and cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and interpretation caveats are front-loaded, and each clause carries real meaning for reading the data. It is dense, with nested parentheses and semicolon chaining, but almost nothing is filler; a lighter structure would help readability without shortening it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose output is easy to misread (rankings driven by IP-capped client counts), the description supplies the measurement caveats, window semantics, exclusion rules, and paging behavior. With an output schema already present, return-field documentation is not required, yet it names key fields anyway.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so limit and offset are already documented, and the description largely restates them plus the default (limit 25) and the next_offset convention. It adds only marginal meaning over the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states the resource precisely: aggregated search terms that agents used in this directory, plus the decision it supports (which x402 service to build or list). It is not a clean verb+resource phrasing and never names its siblings, but the sibling set (find_paid_service, get_service_details, resolve_endpoint) is unrelated enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear intended use — deciding what service to build or list — which is a genuine when-to-use signal for a demand-research tool. It adds a useful caveat ('A term being asked does not mean nothing serves it') to prevent misreading demand as a gap, but names no explicit alternatives or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0find_paid_serviceget_service_detailsresolve_endpointwhat_agents_are_asking_forScored 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.
