nohumans-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_paid_serviceA | 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. |
| get_service_detailsA | 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. |
| resolve_endpointA | 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. |
| what_agents_are_asking_forA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.