nohumans.directory

what_agents_are_asking_for

Read-onlyIdempotent

What buyers actually searched this directory for, for an agent deciding which x402 service to build or list. Returns the aggregate demand feed: the terms asked most persistently (ranked by how many distinct days a term was asked, not by volume — volume is trivially faked and we proved it on ourselves), and the category filters they used. It reports what was ASKED, not what is missing: whether the listings already serving a term are adequate competition is a seller's judgement, not ours, and we grade those listings. Three exclusions are applied and published rather than hidden: queries under 5 characters (catalogue enumeration, once the top ten terms were the single letters a-j), searches from clients that also edit listings here (sellers checking their own rank — one accounted for 196 of 205 searches of the top term), and a floor of 3 distinct non-seller client IPs before any term appears at all. Client IPs are a ceiling on independent demand, never a count of buyers: one serverless caller presented eight IPs in a second. The window is complete but closed — it ends a day behind live, and the response says exactly when. This is a small market and the numbers are small; they are reported as they are so you can judge whether they are enough to act on.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	The exclusions, stated in words.
`top_needs`	Yes	Terms ranked by how many distinct days they were asked.
`delay_hours`	Yes	How far behind live the window ends.
`window_days`	Yes	Length of the reported window.
`total_queries`	Yes	Every search in the window, before exclusions.
`window_ends_at`	No	Unix seconds at which the window closes.
`k_anonymity_unit`	No
`k_anonymity_floor`	No	Distinct non-seller client IPs a term needs before it is reported at all.
`distinct_client_ips`	No	A ceiling on independent demand, never a count of buyers.
`top_category_filters`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 11, 2026

removedOutput schema / properties / top_lookups

Removed value: -{
-  "description": "Endpoint URLs agents asked us to resolve.",
-  "items": {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  "type": "array"
-}

Changed2 schema fields changedSep 11, 2026

removedOutput schema / properties / top_zero_result_terms

Removed value: -{
-  "description": "What agents searched for and found nothing — the gaps in this market.",
-  "items": {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  "type": "array"
-}

changedOutput schema / required

Previous value: -[
-  "window_days",
-  "delay_hours",
-  "total_queries",
-  "top_needs",
-  "top_zero_result_terms"
-]New value: +[
+  "window_days",
+  "delay_hours",
+  "total_queries",
+  "top_needs"
+]

AddedSep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only establish a safe read operation; the description goes far beyond by disclosing the ranking method (distinct days, not volume), three named exclusions with rationale, the closed window lagging one day behind live, and the IP-ceiling caveat for interpreting counts. This is exactly the interpretive context an agent needs and could not 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 is front-loaded in the first sentence and the remaining content is dense with caveats that materially affect interpretation. It is a single long paragraph with some editorial flourish ('we proved it on ourselves'), which costs a point, but nearly every clause carries substantive meaning.

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?

With an output schema present, return values need not be explained; the description instead supplies the methodology, exclusions, and window semantics required to read the numbers correctly, including a warning that the market is small. Nothing material is missing for correct use.

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?

The tool takes zero parameters, so the baseline is 4. The description nonetheless clarifies that category filters are returned as part of the feed, adding interpretive meaning without needing parameter documentation.

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 first sentence names a specific resource (the aggregate demand feed of what buyers searched this directory for) and a specific audience/decision (an agent deciding which x402 service to build or list). It is clearly distinct from the sibling tools, which are all about individual services rather than aggregate demand.

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 states the context of use clearly ('for an agent deciding which x402 service to build or list') and delineates a scope boundary ('reports what was ASKED, not what is missing'). It does not explicitly name alternatives or when-not-to-use conditions, but the target decision is unmistakable.

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

All nohumans.directory tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.