Not Human Search

Search the Agentic Web

search_agents

Search for websites, APIs, and services that AI agents can actually use. Results are ranked by agentic readiness score (0-100) based on llms.txt, OpenAPI specs, ai-plugin.json, structured APIs, and MCP server availability. Use this to discover payment APIs, job boards, data sources, or any web service your agent needs to call.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max results (default 10, max 20)
`query`	No	Keyword query (e.g. 'payment API', 'weather data', 'job board')
`has_api`	No	Only return sites with a documented structured API
`has_mcp`	No	Only return sites that expose an MCP server
`category`	No	Filter by public category (ai-tools, developer, data, finance, ecommerce, jobs, security, health, education, communication, productivity, news). Audit-only buckets may appear in /api/v1/categories as other or spam, but are not promoted as discovery inventory.
`min_score`	No	Minimum agentic readiness score 0-100 (higher = more agent-ready)
`has_openapi`	No	Only return sites with a published OpenAPI / Swagger spec
`has_llms_txt`	No	Only return sites that publish an llms.txt file (LLM-first site summary)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that results are ranked by an agentic readiness score based on llms.txt, OpenAPI specs, ai-plugin.json, structured APIs, and MCP server availability. This goes beyond the bare minimum, though it doesn't mention auth, rate limits, or return format details.

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?

The description is three concise, information-dense sentences. It front-loads the core purpose, then explains the ranking mechanism, and finally gives concrete usage examples. No fluff or redundancy.

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?

The description covers the tool's purpose, ranking behavior, and example use cases. With 8 parameters and no output schema, it provides enough context to understand how to use the search effectively. It doesn't explain the return structure, but for a search tool, the result being a ranked list is reasonably implied. The schema handles parameter details.

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 description coverage is 100%, so the baseline is 3. The description adds context around the ranking score and use cases but doesn't provide parameter-specific semantics beyond what the schema already documents for query, min_score, has_mcp, etc. It neither enhances nor degrades the schema's clarity.

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 the tool searches for websites, APIs, and services usable by AI agents. It uses a specific verb ('Search') and resource ('agentic web'), and distinguishes itself from sibling tools like find_mcp_servers by covering all agent-usable services, not just MCP servers.

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?

The description explicitly says 'Use this to discover payment APIs, job boards, data sources, or any web service your agent needs to call,' giving a clear use case. However, it does not explicitly mention when NOT to use it or provide alternative tool names, so it stops short of a 5.

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

All Not Human Search tools Inspect

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.3/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between check_url and get_site_details (both provide readiness reports) and between search_agents and find_mcp_servers (both return indexed sites). The descriptions clarify the differences, but an agent could still pick the wrong one without careful reading.

Naming Consistency4/5

The tools mostly follow a verb_noun pattern (check_url, get_stats, submit_site), but recent_additions deviates by using an adjective_noun form, and handoff_provider_action uses a noun-like verb. These minor inconsistencies are readable but not fully uniform.

Tool Count5/5

With 14 tools, the set is within the ideal range for a service of this scope. Each tool covers a distinct aspect of discovery, verification, monitoring, and provider actions, without feeling bloated or too sparse.

Completeness5/5

The tool surface covers the full lifecycle: searching (search_agents), browsing (find_mcp_servers, get_top_sites, recent_additions), retrieving details (get_site_details), verifying (check_url, verify_mcp), submitting (submit_site), monitoring (register_monitor), and the provider action workflow (prepare_provider_action, handoff_provider_action, record_action_interest). No obvious gaps or dead ends.

Resources

Need Help?