Not Human Search

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's 'on-demand', 'runs live', returns specific outputs ('score 0-100 with per-signal breakdown'), and has no side-effects unlike submit_site. It could mention rate limits or authentication needs but covers most operational aspects.

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

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

The description is front-loaded with the core purpose, followed by operational details and usage guidance. Every sentence earns its place by adding distinct value: first defines the tool, second explains what it does, third provides usage context, and fourth distinguishes from alternatives. No wasted words.

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

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

Given the tool's moderate complexity (live crawling, scoring), no annotations, and no output schema, the description does well by explaining the 7 signals checked, the scoring range, and the verification workflow. It could specify the exact format of the 'per-signal breakdown' output to be fully complete, but covers most essential context.

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

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 minimal parameter semantics beyond the schema's detailed url description, mentioning 'Homepage works best' and what NHS probes, but doesn't significantly enhance understanding of the single parameter.

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

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

The description clearly states the tool's purpose with specific verbs ('check', 'runs', 'returns') and resources ('URL's agentic-readiness', 'NHS 7-signal crawler'). It distinguishes from sibling submit_site by noting it's 're-runnable without the submissions-table side-effect', making the distinction explicit.

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

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

The description provides explicit guidance on when to use this tool ('Use before calling an unfamiliar API to confirm it's agent-usable') and when to use alternatives ('ideal for verify-before-use workflows' vs submit_site's side-effects). It also specifies the ideal context ('Homepage works best') and target use case.

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

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

No annotations are provided, so the description carries the burden. It hints at live checks and ranking by agentic readiness, but lacks details on side effects, authentication needs, or data freshness.

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

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

Three concise sentences front-loading purpose and usage, with no redundant or unnecessary words.

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

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

Covers purpose and usage well for a simple tool with optional params, but lacks description of output format (e.g., fields returned) since no output schema is provided.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds no significant extra meaning beyond the schema's descriptions.

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

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

The description clearly states it lists sites with live MCP servers ranked by agentic readiness, and distinguishes from siblings like verify_mcp or search_agents by focusing on discovery of MCP endpoints.

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

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

It explicitly states when to use ('when your agent needs to discover callable MCP endpoints') and pairs with verify_mcp for a workflow, but does not explicitly state when not to use it.

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

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 the tool retrieves a report including cached content and summaries, suggesting it may fetch precomputed data. However, it lacks details on permissions, rate limits, data freshness, or error handling, which are important for a tool that likely queries external resources.

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

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

The description is front-loaded with the core purpose and efficiently lists all components in a single, dense sentence. Every part adds value without redundancy, making it highly concise and well-structured for quick understanding.

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

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

Given the tool's complexity (involves multiple signal checks and cached data) and lack of annotations or output schema, the description is moderately complete. It outlines what the report contains but does not cover behavioral aspects like response format, latency, or failure modes, which could be important for agentic use.

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

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 the single 'domain' parameter. The description adds value by specifying the domain is for a readiness report and listing what the report includes, but does not provide additional syntax or format details beyond the schema. With only one parameter, the baseline is high, but the description compensates slightly with context.

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

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

The description clearly states the specific action ('Get') and resource ('full agentic readiness report for a specific domain'), listing all components included (score, category, 7 signal checks, cached content). It distinguishes from sibling tools like 'get_stats' and 'search_agents' by focusing on a detailed domain report rather than aggregated statistics or agent searches.

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

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

The description implies usage for retrieving comprehensive readiness data for a domain, but does not explicitly state when to use this tool versus alternatives like 'get_stats' (which might provide broader statistics) or 'search_agents' (which might find agents). No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.

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

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

No annotations exist; description states it 'returns current stats' but doesn't disclose data freshness, caching behavior, or performance implications. Basic transparency but lacks depth.

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

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

Single, front-loaded sentence that efficiently conveys purpose and output scope. Every phrase adds value; no wasted words.

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

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

No output schema, but description lists all expected fields, making the return structure fairly clear. Could mention response format (e.g., JSON) but adequate for a simple stats tool.

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

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

Tool has zero parameters, so baseline is 4. Description adds value by enumerating the returned fields, giving meaning beyond the empty schema.

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

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

Description uses specific verb 'get' and resource 'stats', listing concrete fields (total sites, average agentic score, etc.). Clearly distinguishes from siblings like get_site_details or get_top_sites which focus on single sites or rankings.

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

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

No explicit guidance on when to use this tool versus alternatives like get_top_sites or check_url. Context is implied for an overview, but no exclusions or criteria provided.

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

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

No annotations provided. The description mentions ranking by agentic readiness score and that it is a read operation, but lacks details on rate limits, caching, authentication needs, or pagination behavior beyond the limit parameter.

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

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

Two targeted sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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

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

For a simple list tool with two parameters and no output schema, the description covers purpose, filtering, and ranking. It lacks mention of return format or whether results are paginated, but the schema handles limit constraints.

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

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 both parameters. The description adds usage context ('domain like finance or developer') but does not significantly improve understanding beyond the schema's parameter descriptions.

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

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

The description clearly states the verb 'Get', the resource 'highest-scored agent-ready sites', and optional filtering by category. It distinguishes from siblings like search_agents and list_categories by focusing on top scores rather than search or category listing.

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

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

The description says 'Use this to discover the most agent-ready services overall or in a specific domain' and gives category examples, implying when to use it. However, it does not explicitly compare to alternatives like search_agents when search queries are needed.

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

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

No annotations provided, so description carries full burden. It discloses that counts are live and distribution shifts as index grows, indicating dynamic read behavior. No destructive hints needed.

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

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

Two concise sentences: first states functionality, second adds usage context and behavioral note. No filler or redundancy.

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

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

No output schema, but description mentions return includes site counts and average agentic scores. Simplicity of the tool (zero params) means this is sufficient.

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

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

Tool has 0 parameters. Per guidelines, baseline is 4. No param details needed.

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

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

Description explicitly states listings of categories with site counts and average agentic scores. Verb 'list' and resource 'categories' are specific, and tool is clearly distinguished from siblings like search_agents and get_site_details.

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

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

Description advises using this to understand agent-ready services before searching, providing clear context. While it doesn't explicitly state when not to use or name alternatives, the intent is clear and helpful.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool lists sites (read operation), sorts by newest first, and focuses on 'agent-ready' sites. However, it doesn't mention potential limitations like rate limits, authentication needs, or what 'agent-ready' specifically means beyond the examples given.

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

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

The description is appropriately sized and front-loaded with the core purpose in the first sentence. Every sentence earns its place: first states what it does, second provides concrete examples of what it discovers, third gives specific use cases. Zero wasted words.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is reasonably complete. It explains the tool's purpose, sorting behavior, and use cases well. However, without annotations or output schema, it could benefit from more detail about return format or what constitutes 'agent-ready' beyond the examples.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (days for look-back window, limit for max results). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('list', 'discover', 'tracking') and resources ('agent-ready sites', 'Not Human Search index'). It distinguishes from siblings by focusing on 'newly added' sites sorted by recency, unlike find_mcp_servers (general search) or get_top_sites (popularity-based).

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

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

The description provides clear context for when to use this tool ('weekly agent digests', 'tracking ecosystem momentum'), but doesn't explicitly state when NOT to use it or name specific alternatives among siblings. It implies usage for discovering recent additions rather than comprehensive searches.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it registers for alerts, returns an unsubscribe URL, and allows multiple monitors per email (one per domain). However, it lacks details on alert frequency, conditions for triggering alerts, or error handling.

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

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

The description is appropriately sized and front-loaded, with every sentence adding value: the first states the purpose, the second provides usage context and an example, and the third covers behavioral details like return value and constraints. There is no wasted text.

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

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

Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, usage, and key behaviors, but lacks details on output (beyond the unsubscribe URL mention) and potential errors or limitations, which could be important for agent invocation.

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

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

The schema description coverage is 100%, so the schema already documents both parameters (email and domain). The description adds minimal value beyond the schema by implying the domain format ('no scheme') and context for email use, but does not provide additional syntax or format details.

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

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

The description clearly states the tool's purpose with specific verbs ('register an email to get alerted') and resources ('domain's agentic readiness score'), distinguishing it from siblings like get_site_details or submit_site by focusing on monitoring and alerting rather than retrieval or submission.

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

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

The description provides clear context for when to use this tool ('useful for agents tracking a dependency's agent-readiness health') and includes a concrete example ('e.g. an agent that relies on stripe.com's MCP surface'), but it does not explicitly state when not to use it or name specific alternatives among the sibling tools.

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

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

No annotations provided, so description carries full burden. It discloses ranking by agentic readiness score (0-100) and mentions signals used (llms.txt, OpenAPI, etc.). Missing details on pagination, ordering, rate limits, or authentication, but behavior is adequately described for typical search use.

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

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

Two sentences, zero fluff. First sentence defines purpose, second adds ranking detail and examples. Efficiently structured with front-loaded information.

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

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

For a search tool with 8 parameters and no output schema, the description explains ranking and scope but omits details on result fields or structure. Agent may need to infer output format. Adequate but not fully complete.

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

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

Schema coverage is 100% with parameter descriptions already present. The tool description adds overall context and examples but does not provide additional semantics beyond what the schema offers. Baseline 3 is appropriate.

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

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

Description clearly states the tool searches for agent-usable websites, APIs, and services, with a specific verb ('Search') and resource ('Agentic Web'). It distinguishes from siblings by focusing on discovery of resources rather than individual checks (e.g., check_url, find_mcp_servers).

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

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

Description provides explicit use cases ('payment APIs, job boards, data sources') and implies when to use the tool (discovery). However, it does not explicitly contrast with sibling tools or state when not to use it, though the purpose is clear enough to infer differentiation.

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

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

With no annotations provided, the description carries full burden and does well by explaining the crawl process, what signals NHS checks, the scoring computation, and the indexing outcome. It mentions the time frame ('within a few seconds') and success condition ('if the crawl succeeds'), though it doesn't detail potential failure modes or rate limits.

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

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

The description is efficiently structured with two sentences that each earn their place: the first explains the core action and use case, the second details the process and outcome. There's no wasted text, and information is front-loaded appropriately.

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

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

Given the tool's complexity (submission with crawling, scoring, and indexing) and no annotations or output schema, the description provides substantial context about the process and outcome. It explains what happens after submission but doesn't detail the scoring methodology or what 'agentic signals' specifically entail.

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

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 doesn't add meaningful parameter information beyond what's already in the schema's description field, which already explains URL format requirements and best practices.

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

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

The description clearly states the tool's purpose with specific verbs ('submit for NHS to crawl and score') and identifies the resource ('URL'). It distinguishes from sibling tools like get_site_details, get_stats, and search_agents by focusing on submission rather than retrieval or search operations.

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

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

The description explicitly states when to use this tool ('when you discover an agent-first tool, API, or service that isn't in the index yet'). It provides clear context about the tool's purpose and distinguishes it from alternatives by focusing on initial submission rather than subsequent operations.

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

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

With no annotations provided, the description carries the full burden and does well by explaining the tool's behavior: it actively probes via a JSON-RPC tools/list request and returns a structured result with verification status. It doesn't mention error handling or rate limits, but covers the core operation adequately.

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

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

The description is front-loaded with the core purpose, followed by implementation details and usage context, all in three efficient sentences with zero wasted words, making it highly concise and well-structured.

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

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

Given the tool's moderate complexity (probing external endpoints), no annotations, and no output schema, the description does a good job by explaining the verification process and return format. It could mention potential errors or timeouts, but it's largely complete for its purpose.

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

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 the 'url' parameter fully. The description adds no additional parameter details beyond what the schema provides, meeting the baseline score of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('probe', 'check', 'verify') and resource ('URL', 'MCP server'), distinguishing it from sibling tools like get_site_details or register_monitor by focusing on endpoint verification rather than data retrieval or registration.

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

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

It explicitly states when to use this tool ('before depending on a third-party MCP endpoint') and provides context about why ('manifests and documentation can claim MCP support without actually serving it'), offering clear guidance on its intended scenario.

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