nohumans.directory

by directory.nohumans

Overview Discussions Admin

Server Details

We buy from x402 endpoints with real USDC and publish delivery outcomes. Check before you spend.

Ownership verified

Status: Healthy
Uptime: 100.0% over 74 days
Last Tested: 2026-10-31 12:54
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: jalcodev/nohumans-mcp
GitHub Stars: 0
Server Listing: nohumans-mcp

TDQS

A4.1/5.0

Scored 2026-10-30 10:05 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: search listings, inspect a listing by id, validate an endpoint URL, and view aggregate search demand. Although get_service_details and resolve_endpoint both can return full records, their inputs and purposes are clearly separated in the descriptions.

Naming Consistency3/5

Three tools follow a readable verb_noun pattern (find_paid_service, get_service_details, resolve_endpoint), but what_agents_are_asking_for is a long conversational phrase that breaks the convention. The set remains understandable, but naming is mixed.

Tool Count5/5

Four tools are well-scoped for a read-only directory: discovery, detail inspection, endpoint validation, and demand analytics. Each tool earns its place and there is no redundant bulk.

Completeness4/5

The set covers the core discovery workflow from search to listing detail to endpoint validation, plus demand insight. Minor gaps remain, such as no explicit browse/list-all operation, but agents can work around this through search.

Available Tools

4 tools

find_paid_serviceFind a paid serviceA

Read-onlyIdempotent

Inspect

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), 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.

Output Schema

Name	Required	Description
`count`	Yes
`detail`	No
`results`	Yes
`category_expanded`	No

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive, open-world, so the bar is lower. The description still adds real value beyond them: the ranking order (verified, then probe score, then price), that it is free, and the epistemic caveat that results are 'dated evidence, not guarantees.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and resource, and every clause carries information. It is dense to the point of being slightly run-on in the field list, but there is very little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not document return shapes, yet it still explains the evidence model and the summary-vs-full distinction. Only gaps are pagination behavior beyond the limit maximum and whether the ranking is stable across calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above it by explaining that result fields (status, score, evidence_tier, paid_verified, has_sample, price) are what you filter and rank on, and that detail='full' expands each listing beyond the default summary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search paid x402 APIs and datasets by need') plus the ranking contract, which is not derivable from the name alone. An agent can tell this apart from the sibling get_service_details, which is about inspecting one listing rather than discovering many.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: query text drives relevance, 'a specific need in plain words matches best,' and 'zero results means nothing listed matches.' It stops short of naming alternatives explicitly, though 'detail=full returns every field' implicitly routes around a separate detail call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_service_detailsGet a paid service's full recordA

Read-onlyIdempotent

Inspect

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.

Output Schema

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
`verdict_age_seconds`	No
`paid_verified_at_iso`	No
`payto_distinct_recent`	No
`paid_verification_latest`	No
`onchain_unique_payers_30d`	No
`onchain_payto_shared_listings`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds genuine context: observed 402 terms, the _iso timestamp twins, and the warning that on-chain counts describe the seller's shared wallet rather than this endpoint. That last caveat is exactly the kind of trap-preventing detail annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph, front-loaded with the scope ('Full record for one listing id') before the payload inventory. Every sentence carries information, though the enumeration of fields is long enough to border on list-dumping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description nonetheless flags the shared-wallet caveat and the _iso timestamps an agent could otherwise misread. Complete for a one-parameter read tool, with no unused gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single id parameter is fully documented in the schema, so baseline is 3. The description only reinforces that the id is a listing id sourced from a search result — helpful, but nothing the schema does not already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full record for one listing id') and enumerates the payload contents (request/response schemas, sample_query, 402 terms, reputation, paid_verification), which clearly separates it from find_paid_service and resolve_endpoint. It never names a sibling explicitly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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 concrete decision context for when to reach for this tool. It does not state when not to use it or point at the sibling that would replace it, so it is clear context without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_endpointCheck an endpoint URL before payingA

Read-onlyIdempotent

Inspect

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.

Output Schema

Name	Required	Description
`note`	No
`match`	Yes
`detail`	No

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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_are_asking_forWhat agents are asking forA

Read-onlyIdempotent

Inspect

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.

Output Schema

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

TDQS

A4.1/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.