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

No annotations are provided, so the description carries the full behavioral burden. It does not say what detection returns, whether it interacts with the page, how reliable detection is, or what an agent should do after detection.

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, front-loaded sentence with no wasted words. It is appropriately sized for the amount of information it contains.

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 detection tool with no annotations and no output schema, the description omits essential context such as the return value and recommended next step. An agent would need to call it blindly to learn what "detect" actually produces.

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 there are no parameter meanings to explain. This is the expected baseline for a no-parameter tool.

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 ("Detect") and resource ("CAPTCHA challenges") scoped to the current page. It is clear what the tool does, though it does not differentiate itself from the sibling thunder_challenge tool.

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 no explicit guidance on when to use this tool versus alternatives such as thunder_challenge. Usage is only implied by the phrase "on the current page".

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 usefully notes that the tool is "keyless" and lists supported challenge types, but it does not explain whether it solves or merely counters challenges, whether it blocks, what permissions or side effects are involved, or what the agent should expect after invocation.

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 wasted language. It gives the main action, scope, supported challenge types, and keyless constraint efficiently.

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-parameter tool with no annotations and no output schema, the description covers the essential scope and challenge types but leaves important behavioral details unclear. An agent still does not know what "counter" entails, whether the operation is automatic, or what result to expect, making the definition only minimally complete for this kind of browser challenge handler.

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 there are no parameter semantics to explain. The description does not need to compensate for undocumented inputs, and the baseline for a no-parameter tool is appropriate 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 states a specific action ("Detect and counter") and resource ("CAPTCHA/challenge on the current page"), and it enumerates concrete challenge types such as Turnstile, reCAPTCHA, hCaptcha, Amazon, and CF interstitial. It is clear what the tool does, but it does not differentiate itself from the sibling tool thunder_captcha, so an agent cannot tell from the description alone when this tool is preferable to that sibling.

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 should be used when a CAPTCHA or challenge is present on the current page, which gives the agent a basic usage condition. However, it provides no explicit when-not guidance, no prerequisites, and no comparison to alternatives such as thunder_captcha, leaving the agent to infer the correct context.

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 usefully discloses that the click uses a Bezier mouse path and human timing, which is meaningful behavioral context beyond the schema. However, it does not state whether the click is destructive, whether it waits for navigation, how failures are handled, or what permissions are needed.

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: it states the action first and adds the human-like behavior parenthetically. It is efficient, though the parenthetical could be slightly clearer about whether it applies to all clicks.

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 one required parameter, no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It explains the human-like click behavior but omits selector semantics, side effects, usage context relative to many siblings, and failure behavior, leaving key information missing.

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 has one required parameter, 'selector', with 0% schema description coverage, so the description must compensate. The description never mentions the selector, its format, what it targets, or how it is resolved, leaving the only parameter undocumented in both schema and prose.

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 states a specific verb and action: 'Click like a human', which clearly distinguishes it from siblings like thunder_type, thunder_read, or thunder_scroll. It does not explicitly name or differentiate from closer alternatives such as thunder_open, but the core purpose is clear.

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?

There is no guidance on when to use this tool versus alternatives such as thunder_open or thunder_type, nor any exclusions or prerequisites. The agent must infer its usage context solely from the tool name and one-line description.

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 disclosure burden. It implies two outbound network requests but says nothing about safety, side effects, rate limiting, auth requirements, or what the probe reports back.

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?

It is a single front-loaded sentence with no filler, which is good structurally. But the brevity tips into under-specification, leaning on undefined internal terminology instead of explaining the operation.

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 no annotations, the description is the only source of behavioral information, yet it does not explain what the probe returns (detection verdict? per-mode comparison?) or how the two results are presented. This is a significant gap for a diagnostic 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 coverage is 0% for the single 'url' parameter, and the description provides no compensation: no format, no constraint (e.g., must be absolute, http/https only), and no explanation of whose URL perspective the request originates from.

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 (probing a URL's bot posture) and distinguishes two modes (plain request vs 'thunder ghost' TLS-true request). However, 'thunder ghost' is undefined jargon that overlaps with the sibling tool thunder_ghost, so an agent cannot fully tell what this tool does differently from that sibling without inference.

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 given on when to use this tool versus thunder_ghost, thunder_challenge, or thunder_open. The description only states what is compared, not the conditions or scenarios that should trigger this probe.

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 behavioral burden. It identifies the underlying curl_cffi approach and TLS fingerprinting, which is useful, but does not disclose read-only nature, redirect behavior, response format, timeout/rate limits, or that curl_cffi does not execute JavaScript.

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 definition is a single front-loaded sentence with no filler. Every phrase adds some signal, even though the overall description is under-specified in other dimensions.

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 annotations and no output schema, the description should carry more weight about behavior and return expectations. It covers the core mechanism but leaves out important operational details such as response shape, limitations, and error behavior.

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 one required URL parameter and schema description coverage is 0%. The description only repeats 'URL' and adds no details about accepted protocols, format, normalization, or whether the URL must be absolute.

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 states a specific verb (Fetch) and resource (URL), and adds a differentiating trait: a real browser TLS fingerprint via curl_cffi. It does not explicitly distinguish from siblings such as thunder_rest, thunder_open, or thunder_read, which may also retrieve URLs, so it misses the top score.

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 'real browser TLS fingerprint' implies usage when anti-bot TLS fingerprinting matters, but it does not state when to choose this over sibling fetch tools or when it is inappropriate. Guidance is present only by implication.

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 meaningful behavior: burst scrolling, reading pauses, and idle hand drift signal this is a time-consuming human-simulation routine. But it omits whether it is read-only, what side effects occur on the page, and what it returns, leaving key behavioral questions unanswered.

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, tightly written sentence that is front-loaded with the verb and resource and wastes no words. Every element (burst scroll, pauses, drift) 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?

With no annotations, no output schema, and an undocumented parameter, the description should do more. It explains the simulation style but says nothing about what the call produces or how the seconds duration shapes the operation, leaving meaningful gaps for a human-behavior 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 coverage is 0% and the single 'seconds' parameter (default 12) is never mentioned in the description, even though duration is central to a timed human-simulation routine. The description gives no meaning or units guidance beyond what the bare schema shows.

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') and resource ('the current page') plus concrete mechanics (burst scroll, pauses, idle drift). However, it does not distinguish itself from siblings like thunder_read, thunder_look, or thunder_scroll, and it is ambiguous whether 'read' returns page content or merely simulates human interaction 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?

There is no guidance on when to use this versus thunder_read, thunder_look, or thunder_scroll, and no prerequisites or exclusions are stated. The agent must infer the intended use case from the name alone.

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 burden. It names export and wear modes but omits whether wearing a fingerprint mutates persistent state, required permissions, reversibility, error behavior, or effects on later browser actions.

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 front-loaded sentence with no filler packs both modes and the file source into minimal text. The parenthetical is the only potentially cryptic element, but it does not add wasted length.

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, the description covers the two operating modes and the file input at a basic level. However, with no annotations or output schema, it should say more about what export returns and what changes when a fingerprint is worn; as written it is only minimally sufficient.

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 one optional parameter and 0% schema description coverage, so the description must explain imitate_file. It identifies the argument as a fingerprint JSON file and implies omission triggers export mode, but it does not document path format, expected JSON structure, or validation behavior.

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 states two concrete actions: exporting the live fingerprint and wearing one from a fingerprint JSON file, with a parenthetical tying the latter to Skin.imitate. It is clear enough to distinguish the tool from generic browser actions, though it does not explicitly contrast with closer siblings such as thunder_ghost.

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 'or' construction implies that supplying a file switches from export mode to imitate mode, but it does not state when an agent should choose this tool versus alternatives or what preconditions apply. Usage is inferable rather than instructed.

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 must carry the behavioral burden. It does disclose that the tool returns a file path, which is useful, but it does not state whether the screenshot covers the viewport or the full page, what image format is used, or whether the operation waits for page load.

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 compact sentence that front-loads the action and then states the return value. Every phrase 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 zero-parameter visual inspection tool with no output schema, the description gives enough to call it and know the return type. It could be more complete by specifying whether the capture is viewport-only or full-page, but the core call is unambiguous.

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 there is no parameter semantics to explain. The baseline for zero-parameter tools applies, and the description correctly avoids inventing parameter details.

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 states a specific verb and resource: taking a screenshot of the current page. This clearly distinguishes 'look' from reading via thunder_read or thunder_human_read, but it doesn't explicitly name alternatives, so it falls short of full sibling differentiation.

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?

Usage is implied by the phrase 'current page,' but the description never says when to prefer thunder_look over thunder_read or thunder_human_read. No exclusions or alternative tool guidance are provided, leaving routing 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether opening a URL is read-only, whether it waits for page load, what side effects occur, or what is returned—only that a URL is opened.

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 efficient sentence with the action and main input front-loaded. The odd phrase 'human-shaped browser body' adds some ambiguity but does not bloat the definition.

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 annotations, no output schema, and many browser-automation siblings, the description is too thin for an agent to confidently invoke the tool. It omits return behavior, error cases, and how it relates to tools like thunder_rest or thunder_read.

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 has one parameter at 0% description coverage, but the description minimally identifies it as a URL. It does not add format details such as scheme requirements, but the single obvious parameter keeps the gap small.

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 states a specific verb ('Open') and resource ('URL'), but 'in Thunder's human-shaped browser body' is vague and does not clearly differentiate it from siblings such as thunder_rest or thunder_read.

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?

There is no explicit guidance on when to use this tool versus alternatives like thunder_rest, thunder_read, or thunder_search. The only implied usage is that it opens a URL, with no exclusions or prerequisites.

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 disclosure burden. It implies a read-only operation and lists return fields, but does not state permissions, side effects, or detailed return behavior beyond those fields.

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 waste. It states the action and the return contents efficiently.

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 read tool, the description is adequate for invocation because no parameters are needed and it names the returned fields. However, it does not help the agent choose among sibling tools or add behavioral context that an output schema or annotations would otherwise provide.

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 there are no parameter semantics to explain; the baseline for zero-param tools is 4. The description does not need to compensate for any schema gaps.

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 specific verb and resource: "Read the current page," and lists what will be returned (title, url, text, clickable elements). It is clear but does not differentiate itself from similar siblings such as thunder_look or thunder_human_read.

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?

There is no explicit guidance on when to use this tool versus alternatives, and no when-not conditions. The only usage cue is the implied context of reading the current page.

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 one meaningful trait: cookies and fingerprint persist for the next session, so closing does not wipe state. It says nothing about whether the close is immediate, what happens to in-flight page state, or whether it is reversible.

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 short sentences, front-loaded with the action, with the persistence note second. Nothing is wasted, though the extreme terseness contributes to the ambiguity of 'body'.

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-parameter, no-output tool the definition needs only to be unambiguous about effect, and the persistence note is a genuinely useful addition. The residual gap is what 'close' actually ends (page vs. entire session) relative to the other thunder_* tools.

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 there are no argument semantics to explain; the description is not misleading about inputs. Baseline 4 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?

"Close the body" is a verb plus an ambiguous object — it does not plainly say it ends the browser session/page, an inference helped only by the presence of the sibling thunder_open. An agent can guess it is the counterpart to opening, but the metaphor 'body' makes the resource unclear without prior knowledge of the toolkit.

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?

There is no statement of when to call this versus thunder_open or any other sibling, and no prerequisite or exclusion is given. The only usage signal is the implied 'when done' framing, which the agent has 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?

With no annotations, the description carries the full behavioral burden. It discloses a useful trait—human-like easing and reading pauses—but says nothing about direction, whether scrolling is bounded, whether it waits for content to load, or what side effects it has on page state.

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 short sentence with no filler and the key action is front-loaded. It is under-specified rather than verbose, which is a completeness issue, but from a conciseness standpoint it wastes no 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 no annotations, no output schema, and an undocumented parameter, the description is too thin for reliable invocation. It does not cover return behavior, boundaries, or how the single parameter affects the operation, leaving an agent without enough context to call 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 description coverage is 0% for the single parameter "amount" (default 600), and the description never mentions it. It does not clarify units (pixels? lines? percent), direction, or what the default represents, so the description fails to compensate for the schema 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 verb "scroll" is specific, but the description never names the target (page, element, viewport) or scope, and the phrase "human easing and reading pauses" describes manner rather than the resource acted on. It provides no differentiation from siblings such as thunder_human_read or thunder_read, leaving the agent to infer the distinction.

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 no indication of when to use this tool versus the many sibling tools, no prerequisites, and no exclusions. An agent must guess whether this is for general page movement, reading assistance, or something else entirely.

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 must carry the behavioral burden. It usefully discloses the fallback order (ddg->bing->google), browser-true TLS handshake, and that the result names the engine used, but it does not describe failure behavior, rate limits, or broader return structure.

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 action and remains compact. The parenthetical engine list and TLS handshake detail are relevant and earn their 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?

Given no annotations and no output schema, the description provides important context about engine selection and fallback but does not explain the limit parameter or result shape beyond naming the engine. It is adequate but has clear gaps for a search 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 should compensate for all three parameters. It clarifies the engine enum and auto fallback, and query is implied by 'Search the web,' but the limit parameter is not mentioned at all.

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 states a specific verb and resource: 'Search the web' with Google, Bing, or DuckDuckGo. It is clearly distinguishable from sibling page-interaction tools such as thunder_open, thunder_read, and thunder_click, though it does not explicitly name those alternatives.

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 explains engine fallback behavior but gives no guidance on when to use thunder_search instead of sibling tools like thunder_open or thunder_read. It also omits prerequisites, exclusions, or other usage 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 provided, so the description carries the full behavioral burden. It discloses only that a model is queried, but says nothing about whether the call is read-only, what the return value looks like, how long it may take, or whether the returned 'next action' is text, a command, or something else.

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, which is appropriately concise. Its brevity is not wasted, though it leaves important specifics unstated.

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 role as a planning step among concrete action tools, the description should explain how the returned action relates to the sibling tools. With no output schema and no annotations, it leaves critical context missing: what the model returns, how to interpret it, and how to proceed after calling this 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?

The single parameter 'goal' has 0% schema description coverage, so the description must compensate. It merely repeats the word 'goal' without explaining format, level of detail, or examples. This gives no additional meaning beyond the parameter name itself.

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 states a specific action: querying a named model (stewmind-1.7b) for a next action toward a goal. This distinguishes it from sibling tools like thunder_click or thunder_open, which perform concrete operations rather than planning. The only weakness is that 'stewmind-1.7b' is unexplained, leaving some ambiguity about what kind of system is being asked.

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 implies the tool is used when a goal needs a next action, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives among the many thunder_* action tools. An agent must infer the planning role without being told whether to call this before or after the sibling action 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 provided, the description carries the full behavioral burden and does disclose useful traits: inter-key delays, rare typos, and pauses. However, it omits important behavior such as whether the selector is focused first, whether existing text is replaced or appended, whether injected typos are corrected, and what side effects occur on the page.

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 wasted words. The parenthetical details add useful behavioral context efficiently.

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 two required parameters, no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It explains the human-like typing style but leaves the selector semantics, text behavior, and element interaction details undocumented.

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 but does not mention either required parameter. It vaguely implies a text input through the verb 'Type', but gives no meaning for 'selector' or whether text replaces or appends to existing content.

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 states a specific verb, 'Type', and adds behavioral qualifiers: human-like inter-key delays, rare typos, and pauses. This distinguishes it from sibling actions like click, scroll, or open, though it does not clarify the target element context beyond the schema's selector parameter.

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 human-like typing phrase implies when this tool might be preferred, but there is no explicit guidance on when to use it versus alternatives or when not to use it. No prerequisites or alternative tools are mentioned.

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