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

With no annotations provided, the description carries the full behavioral burden and does so: it discloses the unlock ladder shared with read_url, the save location resolution (out_dir, then SEARCHTS_MCP_OUT_DIR, then the working directory), the no-overwrite guarantee, and the failure mode ('Error: ...' string). These are precisely the traits an agent cannot infer from the schema.

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?

Dense and front-loaded: purpose first, then the sibling routing rule, then save semantics, then failure mode. Every clause carries information, though the out_dir clause is long enough that a reader must parse it twice to extract the default-vs-override behavior.

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?

An output schema exists, so the description need not define return values, yet it still names the {path, content_type, bytes} shape as a convenience. Combined with the save/overwrite/failure disclosure, an agent has everything needed to call this correctly for a two-parameter 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%, so the description must compensate for both parameters and it does: url is framed as the file's direct URL, and out_dir is explained as a relative folder inside the working directory with an env-var fallback and a defined default (the working directory itself). This adds substantial meaning beyond the bare schema titles.

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 (download) and resource (a single asset file), enumerates concrete types (image, PDF, font, CSS), and explicitly distinguishes itself from the grab_site sibling. An agent can tell immediately this is the single-file fetch, not the bulk page grab.

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?

Gives an explicit selection rule: 'Use this for one specific file by its direct URL; to pull a whole page's assets at once use grab_site instead.' It names the alternative and the condition that picks it, leaving nothing to inference.

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 the full burden and does well: it discloses the 'unlock ladder' fetching path, what gets downloaded, the non-overwrite folder policy with '-2'/'-3' suffixes, that the chosen folder is returned as out_dir, that read=true additionally writes page.md, and the 'Error: ...' failure string. It does not mention permissions, auth, or rate limits, which is the only meaningful gap.

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 dense but well-ordered block: purpose and output first, then the sibling disambiguation, then storage semantics, then the flag and failure mode. Every sentence carries information, though the storage discussion is long enough to make the entry heavier than most agents need at selection time.

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?

An output schema exists, so the manifest's structure need not be described. Given the tool's three parameters, no annotations, and a non-trivial filesystem side effect, the description covers selection, behavior, storage, and error reporting without gaps an agent would need filled.

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, and it does: out_dir's default resolution (relative folder in the working directory, or SEARCHTS_MCP_OUT_DIR if set), the 'searchts-grab-<host>' fallback, and the collision-avoidance renaming are all explained, and read is tied to its concrete effect of saving page.md. Only url is left self-evident.

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 ('Grab a page') and then enumerates exactly what the operation produces: assets, color palette, fonts, and a manifest returned as JSON. It also explicitly distinguishes itself from the sibling fetch_asset for single known files, so an agent can route without opening either schema.

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?

Gives an explicit when-to-use rule ('a whole page's design/assets at once') paired with the alternative and its condition ('for a single known file use fetch_asset'). Nothing about tool selection is left to inference.

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 behavioral burden and does so richly: escalation order and stopping condition, invisible/control-character stripping, prompt-injection fencing with an untrusted-body marker, 'next_url'/'more' truncation signaling with the caveat that absence of a note does not prove completeness, and error-return semantics ('Error: ...' string, not an exception). That is materially more than any structured field provides.

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?

Action and mechanism are front-loaded in sentence one, and the escalation tiers are easy to scan. It is on the long side and repeats the plain-fetch prohibition in three separate sentences ('Do not start with a plain fetch', 'Also use this when a plain fetch was blocked', 'Do not answer from a blocked snippet'), which could be consolidated without losing meaning.

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?

An output schema exists, so return values need not be explained, yet the description goes further and covers next_url/more continuation, the truncation note, injection fencing, and error strings. Combined with the escalation semantics, an agent has everything needed to call this correctly and interpret the result.

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% for the single 'url' parameter, so the description must compensate. It implies a single page URL (singular 'one web page') rather than a list or domain, but never states format requirements such as absolute scheme, fragment handling, or whether redirects are followed. Marginal added meaning over the bare 'url' string.

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 states a specific verb and resource ('Read one web page as clean Markdown') plus the mechanism (an unlocker ladder of three named tiers), so the agent knows exactly what it gets back. It routes away from naive plain fetches and from web_search snippets, but never acknowledges the sibling grab_site, whose name implies overlapping site-fetching behavior.

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?

Explicit when-to-use ('When the user asks what a URL says, call this first'), explicit when-not ('Do not start with a plain fetch'), and an enumerated list of triggering conditions (403/429, Cloudflare/DataDome/PerimeterX bot-walls, client-side rendering, thin or blocked search snippets). It even warns that a 200 sign-in form is not the page, which prevents a common false-positive 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 carries the full behavioral burden and does so thoroughly. It discloses the subtitles-first strategy, fallback to Whisper with an API-key-free local option, that cookies_from_browser uses the machine's own browser cookies, and the exact return shape ('transcript text, or an 'Error: ...' string on failure'). This is highly transparent about dependencies and failure modes.

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 and front-loaded with the main action. Each sentence adds distinct value: scope, subtitles strategy, usage decision, parameter defaults, and error behavior. There is 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?

Given the absence of annotations and low schema coverage, the description is remarkably complete: it covers inputs, processing strategy, parameter behavior, error output, and distinguishes itself from siblings. The only shortfall is the provider parameter detail, but it is a minor gap in an otherwise fully usable definition.

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 source (video URL or local audio/video file), prefer_subtitles ('defaults true; set false to force audio'), and cookies_from_browser (opt-in, browser cookie source). However, 'provider' is not explicitly defined: the description mentions Groq/OpenAI/faster-whisper but does not enumerate valid values or explain what 'auto' selects, leaving a clear gap.

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 clear verb ('Transcribe') and resource ('a video URL or a local audio/video file'), and differentiates itself from siblings by explicitly stating 'Do not use read_url for a transcript' and 'when the user wants spoken words, not the page.' This makes the tool's 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?

It gives explicit when-to-use guidance ('when the user wants spoken words, not the page'), excludes a specific alternative ('Do not use read_url for a transcript'), and provides conditional logic for choosing subtitles vs Whisper. The note about cookies_from_browser being opt-in and never used by read_url further clarifies boundaries.

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.