SSearch

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

With no annotations provided, the description must carry the full behavioral burden. It discloses the fallback to Common Crawl but omits critical behaviors such as error handling, handling of non-HTML content, rate limits, or whether the page text is truncated. The phrase 'extract readable page text' implies some processing but does not specify limitations.

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 a single sentence, which is concise and front-loaded with the primary action. However, it is under-specified given the three parameters and lack of annotations. The structure is acceptable, but the brevity leaves out important context, so it does not fully earn its place.

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 no output schema and no annotations, so the description should cover return format, error conditions, and parameter effects. It only hints at the fallback behavior and says it extracts text. An agent cannot infer what happens if the URL is invalid, what max_chars does, or what the output looks like. The description is incomplete for reliable 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?

Schema description coverage is 0%, so the description must explain parameter meanings. It only obliquely references the archive_fallback parameter via 'optionally fall back to Common Crawl', but does not explicitly describe url or max_chars. The names are self-explanatory to some degree, but the description adds minimal value beyond the 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 clearly states the verb 'fetch' and the resource 'readable page text', which is specific and distinct from the sibling search tools. It also mentions the optional Common Crawl fallback, but that's behavioral rather than purpose. The purpose is unambiguous and immediately understandable.

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 no guidance on when to use this tool versus the search siblings. It does not state that this is for known URLs while search tools are for discovery. The only hint is the tool name itself, but that is not sufficient. No exclusions or alternatives are mentioned.

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, but the description discloses dev-only scope, fake-canary requirement, transient operation, and minimal return value (delivery status). It omits auth requirements, rate limits, or side effects, but for a test-only transport proof it covers the critical safety and behavior constraints.

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 brief sentences, each front-loaded: what it is, what it does, and the safety warning. No filler or repetition.

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 dev tool with no output schema, the description covers output ('only delivery status') and safety. However, it does not compensate for the fully undocumented input parameter or describe possible transport side effects, so it is 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?

The schema provides only a title for the single required 'canary' string and 0% description coverage. The description clarifies that the value must be a fake canary rather than a real credential, which adds some meaning, but it gives no format, length, or example, leaving the parameter largely unspecified.

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?

Names a specific action (forward a fake canary) and states its purpose (dev-only transport proof) plus output scope (delivery status). The sibling tools are all search/fetch utilities, so the dev-only testing niche is easy to distinguish, though 'canary' remains domain jargon.

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 limits use to dev-only transport proof and warns never to use a real credential, giving a clear context and exclusion. It does not name alternative tools, but none of the search/fetch siblings overlap.

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 of behavioral disclosure. It does convey that the output is filtered to relevant passages only, which is useful. However, it does not describe safe read-only behavior, empty-result handling, effects of max_chars/max_passages, or any limitations.

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 a single, front-loaded sentence with no filler words. 'Retrieve only' immediately conveys scope and filtering intent, and every word contributes to the core 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 four parameters, zero schema descriptions, no annotations, and no output schema, the description is too sparse for reliable invocation. An agent cannot determine the relationship between document_id and query, how the max_* parameters constrain results, or what shape the returned passages take.

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 0%, and the description does not explain query, document_id, max_chars, or max_passages. The phrase 'stored passages in a search result' hints at what document_id might refer to, and 'information you need' vaguely maps to query, but this is not sufficient to compensate for four undocumented 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 names a specific operation—retrieving only relevant stored passages from a search result—and contrasts semantically with sibling tools like get_document and fetch_page by focusing on passages rather than whole documents. It stops short of explicitly naming a sibling, so the differentiation is implied rather than stated.

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 phrase 'stored passages in a search result' implies a post-search, targeted-context use case, giving some sense of when to use it. However, there is no explicit guidance about when to prefer this over search_documents, get_document, or fetch_page, nor any stated exclusions.

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 must carry the behavioral disclosure burden. It states the retrieval intent but does not explain effects of max_chars, whether output is truncated, error behavior for unknown document IDs, or any authentication/availability constraints.

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 a single, front-loaded sentence with no filler or redundant restatement. Every word contributes to identifying the tool's core action and target resource.

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?

With no output schema and sparse annotations, the description gives a serviceable but incomplete picture. It conveys the main purpose and required input, but leaves max_chars behavior and return format implicit, which an agent may need for fully confident 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?

Schema description coverage is 0%, so the description must compensate. It adds meaning to document_id by calling it a 'known SSearch document ID,' but max_chars is not explained beyond its schema title and default. The description only partially clarifies the parameter semantics.

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 ('Retrieve') and a clear resource ('broadered stored text for a known SSearch document ID'). It distinguishes the tool from the sibling search/fetch tools by emphasizing retrieval by an already-known document ID, though it does not explicitly name an alternative.

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 phrase 'for a known SSearch document ID' implies the tool should be used when the caller already possesses the document ID, not when looking for documents. However, it does not explicitly say when not to use it or mention alternatives such as search_documents, so the guidance remains mostly implied.

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 burden. It discloses that successful misses can be promoted into the live index, which is a behavioral trait beyond the search itself. However, it does not detail side effects, permissions, or return behavior.

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, minimal, front-loads the main action clearly, 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?

No output schema and no parameter descriptions; the description leaves the return format and the exact behavior of parameters unexplained. For a 3-param tool with no annotations, this is insufficient.

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 0%, so description must compensate. It only implies query via 'Search' and vaguely references promotion for the promote parameter, but does not explain max_results or clarify how promote works. Lacks meaningful parameter guidance.

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?

States a specific verb and resource: 'Search SSearch-owned stored full-text documents.' This clearly differentiates from siblings like search_web, search_sources, and get_document by scoping to SSearch-owned full-text. The additional note about promotion further distinguishes it.

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?

Provides clear context that the tool searches SSearch-owned stored documents, implying when to use it (internal full-text) versus siblings, but does not explicitly name alternatives or exclusion conditions.

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 present, so the description carries the full burden of behavioral disclosure. 'Show' implies a read-only operation and 'plan' suggests a returned artifact rather than raw results, but the description does not state whether the search is executed, what 'normalized' means, or what the response contains.

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 a single focused sentence with no filler. The verb and resource are front-loaded, and the length is appropriate for a tool with one parameter.

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?

Despite the simple one-parameter surface, the description leaves important context undefined: what a 'normalized local search plan' is, how the query should be phrased, and what the output looks like. Combined with the absence of annotations and output schema, this is not enough for an agent to confidently invoke 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 description coverage is 0%, and the description adds only 'for a query,' which essentially restates the parameter name. It does not clarify the expected query format, scope, or constraints, so it adds little meaning beyond the 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 uses a specific verb ('Show') and names a distinct resource ('normalized local search plan'), which separates it from the sibling search tools at a high level. However, the phrase 'normalized local search plan' is jargon and is not explained, so an agent may not know exactly what artifact is returned.

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 guidance is provided about when to use search_plan versus the sibling tools search_web, search_sources, or fetch_page. There are no exclusions, prerequisites, or alternative-routing hints.

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 must convey behavioral traits. The verb 'Describe' clearly implies a read-only, non-destructive operation, which is a meaningful disclosure. It does not explicitly mention side effects or output format, but for a zero-parameter discovery tool, this is sufficient transparency.

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 a single concise sentence that front-loads the purpose. It contains no filler and every word contributes to understanding the tool's function.

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 parameters, no output schema, and no annotations, the description is fully adequate. An agent can invoke it without any ambiguity about arguments or expected behavior, making it complete for its complexity.

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 has zero parameters, and the description correctly omits any parameter details. Baseline is 4 for zero-parameter tools, and the description adds no unnecessary parameter information.

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 action ('Describe') and the specific resource ('local SSearch corpus and search backends'), making it distinct from sibling tools like fetch_page, search_plan, and search_web. It is not a tautology and gives an agent a concrete idea of what the tool returns.

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 the tool is for discovering available search sources/backends before searching, but it does not explicitly say when to use it versus siblings. There is no direct comparison to search_web or search_plan, leaving the context implied rather than stated.

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 bears the full burden of behavioral disclosure. It does reveal one useful trait: with wait_for_coverage=true, owned documents are searched and external discovery is used only on a miss. However, it says nothing about side effects, read-only guarantees, latency/cost, default behavior when the flag is false, or result format.

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 short and mostly front-loaded, but the first sentence 'Search SSearch' is redundant and adds no real signal. The second sentence packs an important behavior yet is grammatically awkward. It is concise by length but not by informational value per sentence.

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 tool with no output schema, no annotations, and six ambiguous siblings, this description is not complete. It omits return shape, how freshness affects results, default behavior when wait_for_coverage=false, and any warning about external-discovery cost or latency. An agent would need to guess or inspect other tools before safely selecting and invoking this one.

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 0%, so the description must compensate for query, fresh, max_results, and wait_for_coverage. It gives partial meaning only to wait_for_coverage, but even that is ambiguous about what happens when the flag is false. query, fresh, and max_results are left with no semantic guidance beyond their names and defaults.

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's 'Search SSearch' is effectively tautological: it never says what SSearch is or that this tool searches the web as the name implies. Compared with siblings like search_documents and search_sources, it does not distinguish its scope. Only the second sentence hints at owned-document plus external-discovery behavior, but that is still vague.

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 closest guidance is 'Set wait_for_coverage to search owned documents and, only if needed, external discovery on a miss,' which explains when to enable that flag. There is no statement of when to prefer search_web over fetch_page, search_sources, search_documents, or search_plan, and no exclusions or prerequisites. An agent must infer applicability from sibling names rather than from the description.

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