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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses that the tool saves to disk, respects out_dir with a default fallback, returns {path, content_type, bytes} as JSON, and returns an Error string on failure. It does not explain the 'unlock ladder' mechanism in detail, but the reference to read_url provides enough 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 three tightly packed sentences with no filler. The core action and return shape come first, usage guidance follows, and failure behavior ends the description. Every sentence earns 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?

For a two-parameter tool with an output schema, this description provides enough context to select and invoke the tool correctly: what it downloads, where it saves, what it returns, and how it differs from grab_site. The only mild gap is that 'same unlock ladder as read_url' presumes familiarity with read_url's behavior, but siblings are available for that 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 coverage is 0%, so the description must compensate. It explains url as a direct URL to one asset file and out_dir as the save destination with current-directory fallback. It does not specify filename derivation or accepted URL schemes, but it adds meaning beyond the bare parameter names.

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 action (download), a specific resource (a single asset file by direct URL), and the concrete outcomes (save to disk, return JSON). It also distinguishes itself from grab_site by explicitly stating it is for one file rather than a whole page's assets.

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 when to use this tool ('for one specific file by its direct URL') and names the alternative for the opposite case ('to pull a whole page's assets at once use grab_site instead'). This gives an agent clear routing guidance without requiring schema inspection.

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 it does well: it discloses zero arguments, no web requests, and the return format including per-line ok/warn/error status and fix hints. It could also explicitly mention that it makes no changes to the system, but the health-report framing makes that reasonably clear.

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 sentences with no filler: purpose, usage guidance, and behavioral details are each packed efficiently. Critical information is front-loaded in the first sentence and the usage guidance is precise.

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 zero-argument diagnostic tool with an output schema and no annotations, the description covers everything needed: what is checked, when to invoke it, that it is read-only, and what the response looks like. No meaningful gap remains.

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, so the schema already fully communicates the input contract. The description reinforces this with 'Takes no arguments,' removing any ambiguity, which justifies a strong score despite the lack of parameter detail.

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 and resource: 'Report the health of this searchts install' and enumerates exactly what is covered (unlocker tiers, search providers, platform integrations). It is immediately distinguishable from sibling tools like read_url and web_search, which perform web actions rather than local diagnostics.

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 the tool: 'Use this first when another searchts tool fails or before relying on an optional capability.' It also clarifies what the tool does not do ('performs no web requests'), which prevents misuse relative to the sibling web 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?

With no annotations, the description carries full behavioral burden. It discloses the fetch mechanism, the disk-saving behavior (out_dir or default folder), the optional page.md side effect, and the 'Error: ...' failure return. This is strong transparency for a download/capture 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 yet complete: it front-loads the core purpose, then gives routing guidance, parameter behavior, and error handling. Every sentence earns its place, with no repetition of schema defaults or 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?

For a multi-step tool with no annotations and no schema parameter descriptions, this description covers what, when, how, parameter side effects, save location, and failure mode. The output schema handles the manifest structure, so the prose does not need to enumerate return 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?

Schema description coverage is 0%, so the description must compensate. It explains read=true (saves page text as page.md), out_dir semantics including the default 'searchts-grab-<host>' folder, and the url parameter is self-evident from 'Grab a page'. An agent can set all three parameters correctly from this text.

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 the resource (a page), the specific actions (fetch through the unlock ladder, download assets, extract palette/fonts, return a manifest JSON), and explicitly contrasts with fetch_asset for single files. The phrase 'a whole page's design/assets at once' clearly anchors its scope and differentiates it from siblings.

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 gives explicit when-to-use guidance ('Use this for a whole page's design/assets at once') and an explicit alternative for a different case ('for a single known file use fetch_asset'). The read flag condition is also explained, so an agent can decide correctly.

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 and does so thoroughly. It discloses the unlocker ladder, the stop-at-first-success behavior, stripping of invisible/control characters, prompt-injection fencing with a warning line, and the fact that failures return an 'Error: ...' string rather than an exception.

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 dense but every sentence earns its place: purpose, when to use, return format, and failure behavior. It is front-loaded with the core action and then organizes supporting details logically without repetition or fluff.

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, the description is complete: it covers the decision to call it, the internal escalation behavior, output format, sanitation, security handling, and error behavior. There are no major gaps an agent would need filled to select or invoke this tool 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?

There is only one parameter, url, and the schema provides no property description. The description compensates by explaining the URL is for a web page and by pointing the agent to 'call this tool on that URL' from a blocked snippet. It does not spell out URL formats, but the intent is clear enough for a single self-describing 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 names a specific verb and resource: 'Read one web page as clean Markdown,' and clearly distinguishes itself from plain HTTP fetch and web_search snippets. However, it does not explicitly differentiate itself from sibling tools like fetch_asset or grab_site, relying on the reader to infer those boundaries.

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 when-to-use conditions: blocked HTTP fetch, bot-walls, client-side rendering, or a blocked/thin/empty web_search snippet. It even states a direct directive: 'Do not answer from a blocked snippet — call this tool on that URL.' This is clear, actionable routing guidance.

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?

Even though no annotations are provided, the description carries the full burden and does so well. It discloses provider behavior (keyless DuckDuckGo default, optional SearXNG/Exa/Brave/Tavily), deduplication with reciprocal-rank fusion, and the exact failure return format: "an 'Error: ...' string when every provider fails." It also warns that snippets are not the page, a meaningful behavioral caveat.

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 behavior, then provider details, then usage guidance, then return format. Every sentence carries operational value, including the direct "Do not answer from the snippet" rule. It is detailed without being bloated.

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 simple (2 parameters, 1 required) and the description covers provider fallback, usage boundaries, and error behavior. It explicitly names the sibling to call for follow-up reading, and because an output schema exists, the description does not need to detail the return format further.

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 missing parameter documentation. It implicitly covers query by describing the search use case, but it never explicitly explains max_results or how it shapes the returned list. The parameter names and the default value of 5 carry most of the meaning, so the description adds only marginal value here.

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: "Search the web across multiple providers and return a ranked, de-duplicated list of results." It clearly distinguishes this tool from read_url and the other siblings by defining its output as a search result list rather than page content. The phrase "Use this to discover URLs" reinforces the intended purpose.

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 when-to-use guidance: "Use this to discover URLs or answer open-ended questions before reading pages." It also provides a clear exclusion: "if you need the content, or a hit is 403/429/challenge/thin, call read_url on that URL." This tells the agent exactly when to prefer a sibling tool.

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