Skip to main content
Glama

nohumans.directory

by directory.nohumans

find_paid_service

Read-onlyIdempotent

Search a registry of paid (x402) APIs and datasets verified by real paid purchases — nohumans pays listed endpoints real USDC and confirms delivery. Returns ranked results: verified listings first, then by reputation score (0..1, recency-weighted probe success), then by ascending price. Each result includes has_sample (boolean) — true means you can cheaply test real output before paying full price; prefer these when a listing is new or thinly-reputed and you can't yet judge it from score alone. Use this before spending money to find services that actually work. Prefer results with status 'verified' and score >= 0.8. Zero results means no known service matches — do not invent endpoints. Always describe the actual need in query in your own words — what data, what freshness, what format, what constraint prompted the search — rather than only setting category/max_price/min_score filters. The exact wording of what you're looking for is what improves this directory over time; a bare filter with no query text tells us far less about what was actually needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results to return (default 10, cap 50).
queryNoDescribe what you actually need, in your own words and as specifically as possible — not just a topic, but the real constraint: e.g. 'sub-second latency wallet risk scoring for Base memecoins', 'EUR/USD spot rate with sub-100ms freshness', 'translate legal contracts, not casual text'. This text is what makes results relevant and is the only place that level of detail is captured — category and price are coarse filters on top of it, not a substitute for it. Only leave this empty if you are genuinely just browsing with no specific need in mind.
categoryNoOne of the 40 most-populated existing categories, most-used first. Omit and rely on free-text `query` instead if none fit well — an unmatched or long-tail category still works via text-search fallback, it just won't be offered here as a constrained choice.
max_priceNoMaximum per-call price. Omit for no cap.
min_scoreNoMinimum reputation score, 0..1. Use 0.8 to only see reliably-passing services.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
resultsYes
category_expandedNo

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description needn't repeat safety traits. The description adds valuable context: zero results means no known service matches and the agent must not invent endpoints; ranking semantics (verified first, reputation, price); and the meaning of has_sample and when to prefer sample-bearing listings. This goes beyond the annotations meaningfully.

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?

The description is fairly long but each sentence earns its place: it covers purpose, ranking order, has_sample semantics, usage timing, preferred result thresholds, zero-result behavior, and query-writing guidance. It is structured as a single block rather than bulleted, which makes scanning slightly harder, but the information density is high and it is front-loaded with the core purpose.

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?

Given the tool's complexity (ranking rules, has_sample semantics, zero-result handling, guidance to avoid inventing endpoints), the description covers the critical non-obvious behavior thoroughly. An output schema exists, so return-value documentation is not the description's job. The description plus annotations and schema provide everything an agent needs to select and invoke the tool correctly.

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 description coverage is 100%, so the schema already documents all five parameters. The description adds substantial semantic guidance beyond the schema: it explains the ranking semantics that connect to min_score, explains how has_sample ties into judging new or thinly-reputed listings, and emphasizes that query must carry the real constraint in the agent's own words rather than just a topic. It doesn't repeat parameter syntax but adds behavioral meaning.

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?

The description clearly states that the tool searches a registry of paid (x402) APIs and datasets verified by real paid purchases, with a specific ranking mechanism (verified listings first, then reputation score, then ascending price). This distinguishes it from siblings like get_service_details and resolve_endpoint, which are about getting details or resolving endpoints rather than discovering paid services.

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

Usage Guidelines5/5

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

The description gives explicit guidance on when to use the tool ('Use this before spending money to find services that actually work'), what to prefer ('Prefer results with status 'verified' and score >= 0.8'), and what to do when no results are found ('do not invent endpoints'). It also instructs the agent to always describe the actual need in `query` rather than only using filters, and explains why, which is strong usage guidance.

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

All nohumans.directory toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a distinct entry point: find_paid_service searches by need, get_service_details fetches by listing id, and resolve_endpoint checks a URL already in hand. The only close pair, get_service_details and resolve_endpoint, is clearly separated by input type and intended workflow.

Naming Consistency5/5

All three tool names follow a consistent snake_case verb_noun pattern: find_paid_service, get_service_details, resolve_endpoint. The verbs and objects clearly indicate both the action and the target.

Tool Count5/5

Three tools is a well-scoped size for a specialized read-only registry lookup server. Each tool earns its place and none feels redundant or missing.

Completeness5/5

The tool set fully covers the apparent domain: discovering paid APIs, inspecting full listing details, and pre-checking an unknown endpoint URL before spending money. There are no obvious dead ends or missing read paths for this registry's purpose.

Resources