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 well: it names the destructive side effect (the saved login is deleted, forcing a re-prompt), the default no-op on browser cookies, and the flag that widens the blast radius. The 'because those are the user's and they did not ask for them to be removed' clause explains the rationale for the default, which is exactly the kind of context an agent needs before flipping also_browser.

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, front-loaded with the action and effect, then the trigger, then the important non-obvious default. No filler and no repetition of the name or schema.

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?

Output schema exists so return values need not be described. For a two-parameter destructive tool, the definition covers effect, trigger, default behavior, and the flag's consequence — everything needed to call it safely.

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 supply meaning, and it does for also_browser by explaining precisely what true changes. The url parameter is only implied by 'for one site' — no format (full URL vs. domain/host) is given, which leaves a gap on the required 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?

States a specific verb and resource — delete searchts's own saved login scoped to one site — plus the observable consequence ('so the next read of it asks again'). An agent can distinguish this from siblings like login_signin, login_status, and read_url without opening any 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 trigger ('Use when a read_url error says the saved login has expired') and an explicit scope exclusion (browser cookies are untouched unless also_browser is true). It stops short of routing the agent to alternatives such as login_signin for re-authenticating or login_status for checking state, so it is strong but not complete on the when/when-not/alternatives axis.

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 persistence ('keep that login'), a privacy trait ('Nothing is copied from the user's own browser'), an operational prerequisite (user present at the machine), and the failure signal ('Returns Error: ... on failure'). It does not cover authentication scope or what happens on repeat sign-ins.

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?

Sentences are front-loaded with the purpose and none is obviously filler, but the malformed fragment 'in a browser searchts opens' injects noise and forces the reader to guess at the intended 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?

For a two-parameter tool with an output schema (so return format needn't be described), the description covers behavior, prerequisites, and failure mode adequately. The residual gap is parameter meaning, which is left entirely to 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 description coverage is 0% and the description never explains either parameter. 'For a site' loosely hints at url, but the browser parameter and its default are entirely undocumented in both description and schema, so the description fails to compensate for the coverage 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 gives a clear verb+resource: 'Sign in once for a site ... and keep that login,' which distinguishes it from the copy-session approach implied by siblings like login_status/login_kill. The garbled phrase 'in a browser searchts opens' blunts an otherwise precise statement but the core purpose survives.

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 states the selecting condition explicitly: 'the way past a login wall when the user has no browser session worth copying, or refuses to have one read,' plus the prerequisite that the user must be at the machine. It stops short of naming the sibling alternative (e.g. the copy-session tool) that would apply in the other case.

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

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

With no annotations, the description carries the full burden, and it does disclose the return format ('Returns JSON') plus a meaningful safety property: it never contains a cookie value. It does not state that the call is read-only/side-effect free, nor any auth or permission requirements, which matters for a login-related tool.

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, both front-loaded: the content of the status report first, the invocation trigger second. Every clause carries information — the enumerated report contents, the trigger, and the privacy guarantee.

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, and the description usefully summarizes them anyway; with zero parameters there is no schema burden. The only gap is the absence of any statement about side effects or permissions, which the annotations would otherwise have supplied.

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 zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The description correctly spends no words on arguments and instead describes the result set.

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 exact resource and enumerates what it reports: kept sites, whether the session may copy logins, which sites it copied, and the scratch folder location. That is far more specific than the bare name 'login_status' and clearly separates it from login_signin/login_kill. The proprietary term 'searchts' is never defined, which slightly blurs the resource being described.

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 an explicit trigger: 'Call this when a read_url error mentions a login,' naming the sibling tool that produces that error. The phrase 'before asking for anything' implies the ordering relative to login_signin, though it never states outright when not to use this tool or what login_status is not for.

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

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

No annotations are provided, so the description carries the full burden — and it does: it discloses the three-tier ladder and its stop condition, character stripping, prompt-injection fencing, error-as-string (not exception) semantics, cursor opacity/signing, and receipt fields ('authenticated', 'login_via'). It also details the security model (cookies host-fenced, never relayed or returned; proxy refuses cookies unless proxy_trusted).

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?

Front-loaded with the core purpose and the primary routing instruction, then proceeds to edge cases. It is long (~400 words) but nearly every sentence adds behavioral or routing value for an unusually complex tool; a few asides (e.g., 'You do not need a cursor for most pages') could be tightened.

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 10-parameter tool with ladder logic, auth handling, and pagination, the description covers the operational, safety, and failure-mode surface an agent needs. Even though an output schema exists, it still clarifies receipt semantics and the incompleteness caveat, which the schema alone would not convey.

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, and it explains most parameters: page_items, cursor/next_cursor flow, cdp_port, cookies_from_browser, cookies, proxy, and proxy_trusted, including safety constraints for each. It leaves max_items and max_pages unexplained, so it stops short of fully covering all 10 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?

States a specific verb (read), resource (one web page), and output form (clean Markdown), plus the escalation mechanism (unlocker ladder). It differentiates itself from siblings like web_search and fetch_asset by framing itself as the escalation path when plain fetches fail.

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 says when to call it first ('When the user asks what a URL says, call this first. Do not start with a plain fetch') and enumerates the failure conditions that select it (403/429, Cloudflare/DataDome/PerimeterX walls, JS-only pages, blocked/thin web_search snippets). It also warns against the wrong behavior (answering from a blocked snippet or login chrome).

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.