Not Human Search

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

With no annotations, the description carries full burden. It discloses that a live crawler runs, lists the exact 7 signals probed, describes the return format (score and breakdown), and clarifies it has no side-effects on submissions. This goes well beyond what structured fields provide.

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, no redundancy. The first sentence front-loads purpose and mechanism; the second adds usage context and differentiates from a sibling. Every clause contributes 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 single-parameter tool with no output schema, the description is complete: it explains what the tool does, what it probes, what it returns, when to use it, and how it differs from alternatives. No gaps remain for an agent to invoke and interpret results correctly.

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% and the url parameter description is detailed (full URL vs bare domain, homepage works best, probes relative paths). The tool description itself adds no additional parameter semantics beyond that, so the baseline of 3 applies.

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 uses a specific verb 'check' with a clear resource 'any URL' and states the exact purpose: agentic-readiness. It enumerates the seven signals probed and the 0-100 score output, which fully distinguishes it from sibling tools like submit_site or verify_mcp.

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?

Explicitly states when to use: 'Use before calling an unfamiliar API to confirm it's agent-usable.' It also contrasts with submit_site, noting this tool is re-runnable without the submissions-table side-effect, making the appropriate alternative choice obvious.

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, the description carries the full burden. It discloses key behavioral traits: a 'query-free discovery receipt' is included in the result set, and eligible provider-funded actions appear separately without changing organic order. This goes beyond a simple listing and informs the agent about sponsored content handling and an unexpected receipt element.

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 exactly two sentences, with the primary purpose front-loaded in the first sentence and behavioral context in the second. There is no filler or redundancy, and every clause serves a purpose.

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?

The description effectively covers purpose, ranking, behavioral quirks, and the recommended pairing with verify_mcp. Although there is no output schema and the return format is not described, the tool is straightforward and the schema covers input parameters well, making the description adequate for selection and 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 input schema provides complete descriptions for all three parameters (limit, query, category) including enum values. The description adds no parameter-specific meaning beyond this, so with 100% schema coverage, the baseline of 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?

The first sentence explicitly states 'List sites in the index that expose a live MCP server, ranked by agentic readiness.' This provides a specific verb and resource, and the ranking criterion differentiates it from siblings like get_top_sites and search_agents. The pairing with verify_mcp further clarifies its unique role.

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 gives clear context by stating the tool is for discovery of live MCP servers and suggests pairing with verify_mcp for a probe-before-use workflow. However, it does not explicitly contrast with alternatives like search_agents or state when not to use it, so it lacks explicit exclusion criteria.

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 explains that the response includes cached llms.txt content and OpenAPI summary, and importantly details the subtle record_action_interest opportunity that may appear with a search_id, clarifying that selection alone is never interest and never contacts the provider. This is valuable behavioral context beyond the schema and helps set expectations.

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 concise and well-structured: two sentences, front-loaded with the core purpose, followed by a detailed enumeration of contents and a crucial caveat. Every clause adds information without redundancy, earning a top score.

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 no output schema, the description sufficiently explains what the response will contain (score, category, signals, cached content, summary, optional action-interest). It also addresses the edge case of search_id selection, making the tool's behavior clear for an agent to invoke correctly.

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 the schema already documents both parameters. The description adds extra semantic value by explaining the conditional behavior of search_id (newly records selection, may trigger an action-interest opportunity) and reiterates the domain input requirement. This goes beyond a baseline score of 3 by providing richer context for the optional 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 uses a specific verb ('Get') and resource ('full agentic readiness report') with an explicit scope ('for a specific domain'), listing the exact contents (score, category, 7 signal checks). It clearly distinguishes from sibling tools like check_url or find_mcp_servers by enumerating the report's unique components.

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 when to use the tool: when the full readiness report is needed. It provides context by specifying all included signals and the optional search_id behavior. However, it does not explicitly name alternatives or exclusions (e.g., 'use check_url for a quick check'), but the context is clear enough for an agent to infer.

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, and the description does not mention operational behaviors such as data freshness, caching, or response format. It does disclose the specific statistics included, which gives some transparency about content but not about side effects or performance.

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?

A single sentence lists all available stats; it is concise and front-loaded with the tool's purpose.

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 no output schema, the description enumerates exactly what is returned. The low complexity (zero parameters) means this is adequate, though it could mention whether stats are live or cached.

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 tool takes no parameters, with schema coverage 100% trivially. The description adds no parameter details, but none are needed; baseline 4 for zero params.

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 returns current index stats and enumerates specific metrics (total sites, average agentic score, top category, etc.), distinguishing it from sibling tools like get_top_sites or recent_additions that focus on lists.

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. The purpose implies use for aggregate overview, but no when/when-not or alternative references.

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 full burden. It discloses that results are always ordered by readiness score, that filtered category calls create a 'discovery receipt' supporting provider-funded actions and explicit interest, and that unfiltered browsing does not enter the demand cohort. This is substantive behavioral context, though terms like 'discovery receipt' and 'Stage 1 demand cohort' are not fully explained, which slightly reduces clarity.

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 two sentences long, front-loaded with the core purpose. The first sentence states what the tool does and the optional filter; the second adds necessary nuance about ordering and behavioral implications. 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 has no output schema and no annotations, the description covers essential aspects: purpose, optional filtering, ordering, and behavioral side effects. It does not describe the response format, but for a simple top-sites list with only two parameters, the description is largely sufficient. Minor gaps include undefined jargon and missing details about default limit behavior, but these are partially mitigated by the schema.

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 baseline is 3. The description adds semantic value beyond the schema by explaining the behavioral consequence of using the category parameter: it creates a discovery receipt and enables provider-funded actions, whereas omitting it keeps browsing free. This extra context goes beyond the schema's basic 'filter by public category' and elevates the score.

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 retrieves 'the highest-scored agent-ready sites in the index' with an optional category filter. The verb 'Get' and specific resource ('sites in the index') are explicit, and the 'optionally filtered by category' differentiates it from sibling tools like search_agents, which likely returns broader search results.

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 on when to use the tool: to retrieve top-scored sites, with an optional filter. It explains the behavioral difference between filtered and unfiltered calls (filtered creates a discovery receipt supporting provider-funded actions, unfiltered stays free), which informs when a category should be used. However, it does not explicitly mention alternatives or state when not to use this tool in favor of a sibling.

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 fully carries the transparency burden. It proactively discloses privacy guarantees (no query, contact detail, identity, network address, referrer, or user-agent is disclosed) and cost implications (neither party charged; only downstream outcome can create a provider charge). It also clarifies that the handoff receipt is privacy-safe and that declining optional disclosure is non-blocking, providing comprehensive behavioral context.

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 five sentences, each adding distinct value: the core action, the receipt/return, the optional disclosure, the privacy scope, and the cost model. It is front-loaded with the primary purpose and contains no filler or redundant restatements of annotations.

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?

The tool has a complex consent workflow and no output schema, yet the description covers the main flow, return value (provider action URL), optional consent, privacy, and cost. It could additionally document failure modes or idempotency, but for a handoff continuation tool, the description adequately prepares an agent to invoke it correctly.

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 the baseline is 3. The description adds meaning by detailing exactly what the optional controlled-intent disclosure covers ('the ticket's controlled topic, region, USD budget band, urgency, and allowlisted requirement flags'), which is not specified in the schema's generic reference to a 'bounded controlled-intent bundle'. This helps the agent understand the semantic scope of the optional consent parameters.

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 function: 'Present the exact ticket bearer returned by prepare_provider_action', after which NHS records a handoff receipt and returns the attributed provider action URL. This specific verb+resource pairing distinguishes it from the sibling prepare_provider_action by referencing it as the source, making the tool's role in the workflow unambiguous.

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 ties usage to the output of prepare_provider_action, implying the correct sequence. It also explains the optional controlled-intent disclosure and notes that declining it does not block the handoff, providing clear conditional usage. However, it does not explicitly exclude alternatives or describe when not to use the tool, only relying on the sequential dependency.

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, the description carries the transparency burden. It discloses that counts are live and the distribution shifts as the index grows, which is non-obvious and useful behavioral information. It does not detail error cases or response format, but for a simple list those are less critical.

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, no wasted words. The first sentence states the purpose and output, the second provides usage context and live-data behavior. Front-loaded and easy to parse.

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 parameterless read-only listing tool, the description is complete: it names the scope, output contents, and the dynamic nature of the data. The absence of an output schema is mitigated by the description explicitly listing the returned fields.

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?

There are zero parameters, and the schema is empty, so there is nothing to explain. The baseline of 4 is appropriate because no parameter ambiguity exists.

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 uses a specific verb ('List') and resource ('categories in the Not Human Search index'), and states the output includes site counts and average agentic scores. This clearly distinguishes it from sibling search and detail tools, which focus on individual entries or queries.

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 the tool ('before searching') and why ('understand what kinds of agent-ready services exist'). It does not mention alternatives or exclusions, but for a catalog-overview tool this is sufficient context to guide selection.

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 clearly states what the tool does NOT do (never returns the URL, never records a handoff), what it requires (receipt and attestation), what it accepts (controlled constraints only), and the cost implications. It also links to the exact consent wording. This is thorough and transparent for a tool with no annotations.

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 three sentences long and front-loaded with the core purpose. Each sentence adds distinct information: what it does, what it doesn't do, and its requirements/cost. There is no repetition or filler. It is concise yet information-dense.

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?

The description covers the tool's purpose, prerequisites, constraints, side effects, and consent wording. However, it does not describe the return value or response format, which could be relevant for an agent invoking the tool. Given that there is no output schema, a brief note on what is returned would improve completeness, but the description still provides sufficient context for safe and correct 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 already documents most parameters (67% coverage), but the description adds meaningful context beyond the schema: it clarifies that only controlled constraints are allowed and explicitly lists prohibited fields (name, email, contact details, etc.), which is not obvious from the schema. It also ties 'search_id' to a discovery receipt and 'offer_id' to a provider-funded offer, reinforcing the tool's purpose. This adds value beyond the structured 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?

The description opens with a specific verb and resource: 'Prepare a signed action ticket for a separately disclosed provider-funded offer returned beside a receipt-bearing NHS discovery result.' This immediately identifies the tool's unique function, and the explicit statement that it 'never returns the provider action URL or records a handoff' clearly distinguishes it from the sibling tool 'handoff_provider_action'.

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: it requires a discovery receipt and explicit attestation, and it states that it does not perform a handoff. This implicitly guides the agent to use a different tool when a handoff is needed, though it does not explicitly name the alternative. It also notes cost implications, which helps the agent decide whether to invoke this tool.

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, the description discloses important behavioral nuances: sorting order, and that selecting a supported category 'creates a query-free discovery receipt' with implications for provider-funded actions, while unfiltered viewing stays free and does not enter the Stage 1 demand cohort. This goes beyond a simple list operation.

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 compact at two sentences, with the first sentence directly stating the tool's function. The second sentence is dense and jargon-heavy, but it conveys necessary nuance without padding. It could be clearer but is not verbose.

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?

The tool is a simple list operation with three optional parameters, and the schema already documents defaults and limits. The description covers the core purpose and a critical side-effect of category filtering, making it sufficiently complete for an agent to decide whether to use it. It does not describe the return format, but that is not critical given no output schema and the simple nature.

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% for all three parameters, so the baseline is 3. The description adds significant meaning to the category parameter, explaining that supported categories trigger receipt creation while omitting category is 'unfiltered catalog watching' with different behavior. This enriches the schema's enum.

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 opens with a specific verb and resource: 'List agent-ready sites newly added to the Not Human Search index, sorted newest first.' This clearly distinguishes it from sibling tools like get_top_sites or search_agents by focusing on recent additions.

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 when to use this tool (for discovering newly indexed sites) and provides context about category filtering. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough to guide selection.

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, the description fully discloses behavior: it creates a private, expiring receipt, takes no provider contact, does not alter commercial metrics, and has exact v1 wording linked. It also clarifies that caller attestation is not authority to contact the provider, which prevents misuse.

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?

Four dense sentences, front-loaded with purpose, each adding essential behavioral or constraint information. No fluff or repetition of schema field names beyond what is needed.

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?

The description covers purpose, constraints, expiry, and non-effects, which is strong. However, with no output schema, it does not state the expected return value or possible error conditions, leaving a small but meaningful gap for an agent invoking the 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?

Schema covers 100% of parameters, so baseline is 3; the description adds semantic constraints by stating what is not accepted (query, contact data, free-form text, identity) and clarifying the attestation's limited scope. It also links the exact confirmation wording, giving meaning beyond the enum values.

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 opens with a specific verb ('Record') and precisely defines the object: the caller's attestation of principal interest in one controlled next step with an organically returned site. It explicitly contrasts with sibling action tools by stating it does not contact the provider or create an action ticket, making its purpose unambiguous.

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 gives clear context: it is for recording a private Stage 1 demand receipt, with explicit exclusions (no contact, no ticket, no charge, no rank change) and constraints (expires, accepts no query/contact/free-text data). It does not name an alternative tool, but the exclusions tell an agent what this tool is not for and effectively when 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 key behaviors: 'Returns an unsubscribe URL' and 'Multiple monitors per email allowed, one per domain.' However, it does not mention alert frequency, error handling, or the exact response format, leaving some behavioral aspects opaque.

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 three sentences, each earning its place: purpose, use case, and return value/constraints. It is front-loaded with the primary purpose and contains no redundant 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 simple 2-param tool with no output schema and no annotations, the description is fairly complete. It covers what the tool does, when to use it, the return value (unsubscribe URL), and constraints (multiple monitors per email, one per domain). Missing details like response structure and error cases are minor for this simplicity.

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 input schema already covers both parameters with descriptions, so schema coverage is 100%. The description adds context that domain 'no scheme, e.g. 'stripe.com'' and clarifies the relationship between email and domain, but this is supplementary rather than essential.

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: 'Register an email to get alerted when the indicated domain's agentic readiness score drops.' It uses a specific verb (register) and resource (email), and distinguishes itself from sibling read-only tools by focusing on alerting/monitoring.

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 a clear use case: 'Useful for agents tracking a dependency's agent-readiness health — e.g. an agent that relies on stripe.com's MCP surface wants to know the moment it regresses.' It does not explicitly name alternative tools, but the context strongly implies when to use it versus read-only tools like get_site_details or check_url.

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 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.

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.

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.

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.

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.

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.

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

Without annotations, the description carries full responsibility and addresses it well: it outlines the crawl process, the 7 signals checked, scoring, and the 'searchable within a few seconds if the crawl succeeds' caveat. It could add details on failure handling or duplicate submissions, but this is a submission tool with no destructive behavior, so transparency is above average.

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 three well-structured sentences: purpose, usage context, and process. Each sentence earns its place, with no redundant text. Key details like the 7 signals are efficiently embedded, making it concise and front-loaded.

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 one-parameter tool with no output schema, the description provides sufficient context: what happens on success, the signals checked, and the timing. It could mention what the API returns on failure or success, but the core workflow is well covered. The lack of an output schema raises the burden, but the description still feels reasonably 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?

The input schema already fully describes the 'url' parameter including format and best practice (homepage). The tool description itself adds no additional semantic information about the parameter. With 100% schema coverage, the baseline is 3, and the description doesn't exceed it.

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 a specific verb ('Submit') and resource ('a URL for NHS to crawl and score'). It distinguishes itself from sibling tools by focusing on adding new sites to the index, while siblings like check_url or get_site_details are for querying or verifying existing entries.

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 provides a usage condition: 'Use when you discover an agent-first tool, API, or service that isn't in the index yet.' This gives clear guidance on when to submit, but it doesn't explicitly state when not to use it or name alternative tools for already-indexed sites. The 'isn't in the index yet' implies the exclusion, and sibling names are available, so a 4 is appropriate.

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 behavioral disclosure burden. It explains the underlying mechanism ('Sends a JSON-RPC tools/list request and verifies a valid response') and the return format, which is transparent about the operation. However, it does not reveal limitations such as potential timeouts or that 'spec-compliant' is based solely on tools/list, so it stops short of a 5.

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 four sentences, each adding value: purpose, method, usage guidance, and return value. It is front-loaded with the primary action and contains 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It covers what the tool does, how it does it, when to use it, and what it returns, leaving no major gaps for an agent to invoke it correctly.

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 already provides 100% coverage of the single 'url' parameter, including a clear description. The tool description adds no extra parameter semantics beyond what the schema states, so the baseline of 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?

The description clearly states the tool's purpose: 'Actively probe any URL to check if it is a live, spec-compliant MCP server.' It uses a specific verb ('probe') and resource ('URL'), and the technical detail about sending a JSON-RPC tools/list request distinguishes it from generic URL checkers like check_url.

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 gives explicit usage context: 'Use this before depending on a third-party MCP endpoint — manifests and documentation can claim MCP support without actually serving it.' This clearly indicates when to use the tool, though it does not name alternatives or state when not to use it, which would warrant a 5.

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