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 composition of the result (ranking + provenance + coverage + notes) plus the single-invocation aggregation behavior, which is genuinely useful. It says nothing about side effects, permissions, latency or how urls/top affect the aggregation, so mutation and safety profile remain unknown.

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 clauses, outcome first and usage constraint second, with zero filler. The density comes at the cost of some opacity (the repaired/rendered/fromCache triple is unpacked but 'zwinięty brief' and 'coverage' are left as jargon).

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 read-style aggregator with no output schema, the description does outline the returned sections, which is the most important missing piece. But with no annotations and 0% schema coverage, three undocumented parameters and no statement of side effects remain significant holes for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters (query, top, urls), and the description supplies no parameter meaning at all — no mention of what 'top' caps, whether 'urls' restricts the candidate set, or the query's role. The agent must infer everything from bare type declarations.

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 concrete outcome vocabulary: a condensed brief bundling ranking, provenance flags (repaired/rendered/fromCache), coverage and notes, produced in a single call. That is specific enough to distinguish it from web.search (raw results) and web.drift_report (diagnostics), though 'brief' itself is never defined and there is no title to anchor it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Do raportów' states the intended use case and 'nie do debugu' explicitly excludes the debugging scenario, which usefully routes the agent away from web.trace/web.eval. It stops short of naming the alternative sibling to call instead, so it misses the top band.

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 supplied, so the description carries the full behavioral burden, yet it never says that 'clear' is a destructive, irreversible mutation, whether it affects all namespaces or one, whether it requires elevated permissions, or whether concurrent requests are impacted. Naming the cache domains is the only extra context, and the description doesn't explain whether the tool operates on all of them or one at a time.

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 short sentence with no filler, and the resource is front-loaded. It is terse to the point of under-specification, but nothing is redundant or padded.

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 one-parameter tool this is close to adequate, but with no annotations and no output schema the description should at minimum state that one mode destroys data and what each mode returns. The mention of three cache domains without explaining their relationship to the single action parameter leaves a real gap.

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 partially does by mapping 'stats' to state inspection and 'clear' to clearing, and by naming cache domains. But the enum values themselves are never explained, no default for the optional action is stated, and the listed domains (resolve/content/feeds) have no corresponding parameter in the schema, creating ambiguity about whether they are selectable 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 the resource (cache) and names the two modes (state vs. clearing) plus the cache domains (resolve/content/feeds), which does separate it from siblings like web.stats or web.feeds. However, it is a noun phrase rather than a clear verb+resource statement, and the Polish wording leaves an agent to infer which mode the tool actually performs on a given call.

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 call this versus web.stats (which plausibly returns metrics) or web.configure. Nor does it state when inspection ('stats') is appropriate versus when invalidation ('clear') is warranted, leaving the choice entirely to the schema enum.

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 supplies almost nothing: no indication of whether the call is read-only or mutating, whether it refreshes or caches, or what it returns. The name suggests a write operation while the description reads like a status snapshot, leaving the mutation/read profile genuinely ambiguous.

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 certainly short and free of padding, but it is a sentence fragment rather than a front-loaded statement of action and scope. Brevity here comes from under-specification rather than from efficient editing.

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 structurally simple (no params, no nested objects), which lowers the bar, but with no output schema and no annotations the description must explain what the two named artifacts are and when they are useful, and it does not. An agent cannot confidently decide to call it.

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 nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 applies for a parameterless 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?

The description is a noun phrase ("Rozstrzygnięta konfiguracja + stan renderera") with no verb, so it never says whether the tool returns resolved configuration plus renderer state, applies a configuration, or something else. It also does not distinguish "configure" from siblings such as web.stats or web.render, which plausibly surface overlapping status information.

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 when-to-use guidance, no prerequisites, and no named alternative among the twelve web.* siblings. An agent has no basis for choosing this over web.stats or web.render when it needs configuration or renderer status.

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, yet it says nothing about whether this is a read-only scan, what output shape it returns, whether it scans a single domain or the whole crawl, or how long it takes. Only the detection target is disclosed.

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?

One short sentence is not wasteful, but here brevity is under-specification rather than crispness: it front-loads a label and omits everything an agent needs. It also switches to Polish while the tool name and all siblings are English, costing clarity for no gain.

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 structurally simple (one optional param, no nested objects, no output schema), so the bar is low, but the description still fails to explain the sole parameter or the return behavior, and there are no annotations to fill the gap.

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 single parameter 'threshold' is a bare number with no type, unit, default, or scale meaning. The description does not mention 'threshold' at all, so the agent cannot know whether it is a redirect count, a rate, or a sensitivity score.

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 detector for a specific signal (domains with accelerated/heightened redirects), which is more than a restatement of the name. However, 'drift' and 'przekierania' are not defined, and with a sibling named web.drift_report the agent cannot easily tell whether this detects drift or reports it. Purpose is implied, not pinned down.

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, when to prefer web.drift_report or web.search, or what prerequisite data is needed. The only guidance is what the tool nominally detects, which the agent must infer into a use 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 supplied, the description carries the full burden of behavioral disclosure and falls short. It does not say whether the tool performs live crawling (and the associated cost/latency), whether it is strictly read-only, whether it consumes a pre-built index, or what the 'prior źródeł' actually represents.

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 with the deliverable front-loaded and no padding. The second sentence is somewhat telegraphic and uses unexplained jargon ('prior źródeł'), which costs a little clarity but not 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 no-annotation, no-output-schema analysis tool, the description covers what is produced but not how, at what cost, or in what format the verdict arrives. It is minimally sufficient to try the tool but leaves real gaps an agent would want 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 100% for the single parameter (threshold, default 0.25), so the schema already documents it. The description mentions redirect behaviour but never explains how threshold changes the reported drift, so it adds no meaning beyond the schema; baseline 3 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?

The description states a concrete deliverable: a documentation drift report bundled with a source prior and a natural-language verdict, so the verb+resource are identifiable. It never distinguishes this tool from the sibling 'web.drift', which by name appears to overlap heavily, leaving the agent to guess which one to call.

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 when-to-use, when-not-to-use, or alternative routing guidance. The clause about domains that started redirecting hints at the signal that defines drift, but the agent is not told when to pick this over web.drift or web.verify_links.

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 exist, so the description carries the full burden and does not meet it. It does not say whether live mode performs network calls, whether the gate verdict can fail/block a pipeline, what happens when thresholds are unmet, or whether the call is expensive or long-running.

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 short sentence with no fluff, but it is terse to the point of under-specification, and the parenthetical mode list is doing work that belongs in prose. There is nothing to cut, but also little structure to front-load information beyond the two mode names.

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 three parameters (one nested), no annotations, no output schema, and zero parameter documentation, an agent cannot determine what the tool returns or how to construct thresholds. The definition is far from complete for a tool whose output apparently includes a pass/fail gate verdict.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It glosses 'mode' (replay/live) and implies 'gate' triggers a verdict, but 'thresholds' is a nested object with completely undocumented shape and keys in both schema and description.

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 an activity (quality evaluation) with two modes (offline replay / live) plus an optional regression-gate verdict, which is more than a restatement of the name. However, 'jakość' (quality) of what is never specified — pages, search results, or answers — and nothing distinguishes it from siblings like web.verify_links or web.drift_report, both of which also assess output quality.

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 indication of when to pick this over web.verify_links, web.drift_report, or web.stats, nor when replay vs live mode is appropriate. The parenthetical mode names hint at a choice but give no selection criteria.

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 supplied, so the description carries the full behavioral burden. It does disclose a downstream effect ('linklog → prior'), implying the submission influences future link scoring, which is genuinely useful context. However, it says nothing about whether records are persisted, idempotent, deduplicated by URL, or what the call returns, and the jargon ('prior', 'linklog') is never defined.

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?

At two short sentences it is brief, but brevity here comes from compression into internal jargon rather than from precision. The purpose is not front-loaded, and the arrow notation 'A → B → C' forces the reader to decode a pipeline instead of reading a plain statement of function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter mutation-style tool with no annotations, no output schema, and zero schema description coverage, the description should establish what is written, where, and under what conditions. It gestures at the feedback loop concept but leaves the agent unable to invoke the tool confidently, particularly regarding the role of 'query' and the effect of each label.

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 all three parameters. Instead it only echoes the four label enum values already present in the schema and adds no meaning for 'url' (is it required to match a prior search result?) or for the optional 'query' (is it the originating query context?). This leaves the most semantically important parameter undocumented.

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 never states a verb or resource: it opens with the abstract phrase 'Pętla użyteczności' (utility loop) and an arrow chain 'used/opened/ignored/rejected → linklog → prior'. Only by cross-referencing the tool name web.feedback and the label enum can an agent infer this records a feedback label against a URL. The listed labels merely restate the schema enum rather than naming the action.

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 second sentence gives a rationale ('Bez tego system uczy się rozstrzygać linki, a nie pomagać'), which hints at why feedback matters, but there is no statement of when to call this versus siblings such as web.trace, web.eval, or web.stats. No preconditions, no when-not-to-use, and no named alternative are provided.

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 supplied, so the description carries the entire burden, yet it discloses nothing about behavior. It does not say whether 'remove' is destructive or reversible, whether 'add' validates or fetches the URL, what 'reindex' costs or triggers, whether state persists, or whether any permissions are required.

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 compact sentence with the resource front-loaded and the operations trailing, so nothing is padded. But the compression is under-specification rather than efficient writing, and the Polish phrasing sits oddly against English sibling names.

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 four-parameter, multi-action tool that includes a destructive 'remove' and an undefined 'reindex', with no annotations and no output schema, the definition is far too thin. An agent has no basis for choosing between actions or knowing their side effects.

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% across 4 parameters. The description echoes the four action enum values, giving marginal mapping value, but adds no meaning for 'url', 'name', and especially 'intent', which remains entirely opaque in both schema and description.

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 concrete resource ('Rejestr kanałów RSS/Atom') and enumerates the operations (list/add/remove/reindex), so the general purpose is inferable. However, 'warstwa świeżości' is the only hint at how this differs from siblings like web.search or web.cache, and the fragmentary phrasing leaves the tool's overall role vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to register a feed versus using web.search, web.brief, or web.drift, nor any prerequisites or exclusions. The action list implies what operations exist but not the conditions that select this tool over its siblings.

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 disclose two important traits: it is expensive, and it returns markdown plus a title. It is silent on authentication, rate limits, and what timeoutMs does when exceeded, which matters for a costly browser render.

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 compact sentence pair: what it does, what it returns, and the cost warning, all front-loaded with zero filler.

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 return shape is covered in lieu of an output schema and the cost caveat is present. However, for a two-parameter tool where both parameters are undocumented and there are no annotations, the definition leaves real gaps for an agent to guess at.

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 does not: neither 'url' nor 'timeoutMs' is explained. An agent gets no hint about URL format or what a timeout value means or defaults to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource (render a single page via a V8 browser) and scopes it to JS/SPA content that only appears after interaction. That distinguishes it from lighter siblings such as web.search, though it never names an alternative explicitly.

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?

'Drogie — używaj świadomie' warns about cost and implies the tool should be a deliberate choice, which is useful guidance. But it gives no concrete when-to-use/when-not-to-use rule and does not point to a cheaper sibling (e.g. search or brief) for simpler fetches.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the internal pipeline (plan → propose → resolve → falsify → SERP → learn), that HTTP verification repairs via redirect/Wayback, and that browser rendering kicks in automatically below a text threshold. It omits cost/latency, rate limits, and whether external network calls leave the 'closed ecosystem', which keeps it below a 5.

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 dense block that front-loads internal pipeline stage names and arrow notation before stating the actual purpose and return shape. The pipeline enumeration is jargon that only partly earns its place for an agent selecting a tool, though nothing is truly redundant.

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 an 8-parameter tool with no annotations and no output schema, the description usefully compensates on the return side ('ranked + provenance + ślad decyzji'). However, it leaves sibling disambiguation, the undocumented 'staleness' parameter, and any cost/latency expectations unaddressed.

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 88%, so the schema already documents nearly every parameter (including the serp escape hatch and render policy). The description adds only the renderMinText threshold concept, which is not itself a parameter; the enum-only 'staleness' param remains undocumented anywhere.

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 ('szukaj' / search) and adds scope ('w zamkniętym ekosystemie') plus what the output contains ('ranked + provenance + ślad decyzji'). It never names or contrasts a sibling tool (web.brief, web.verify_links, web.render), so an agent cannot tell from this text alone which sibling to pick.

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 when-to-use or when-not guidance relative to the twelve siblings. The only conditional language concerns internal mechanics ('renderuje przeglądarka (auto), gdy treść < renderMinText') and a SERP escape hatch, which explains behavior, not tool 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?

No annotations are supplied, so the description carries the full burden: it must establish that this is a read of internal state, whether counters reset on read, whether values are per-session or global, and what shape the data takes. It does none of this. The noun list implies an internal-state inspection and hence a read-only operation, but that is inference, not disclosure.

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 short, but the brevity comes from under-specification rather than economy — a colon-delimited fragment with no subject or verb. A handful more words stating what is reported would cost little and remove the ambiguity. Nothing is padded, but nothing is front-loaded either, since there is no main clause to front-load.

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, no annotations, and no parameters, the description is the only channel for understanding the result, and it delivers a word list instead of a contract. An agent cannot tell whether the response is scalar counters, nested objects, or prose. For a zero-argument introspection tool this is the one place the return description was mandatory.

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 nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level meaning is missing because no parameters exist.

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 is a bare noun list ("cache, prior, drift, session search count") with no verb, so it never states what the tool actually does with those things — read them? reset them? aggregate them? It hints at the subject matter of "stats" but only broadens the name into adjacent nouns rather than specifying an operation. Siblings such as web.drift_report, web.cache, and web.drift overlap these same concepts, and nothing here distinguishes web.stats from them.

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 when-to-use guidance, no when-not-to-use, and no reference to any of the twelve sibling tools. An agent seeing this next to web.cache, web.drift, and web.drift_report has no basis for choosing one over another. The listed terms arguably overlap three siblings, making the ambiguity worse rather than better.

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 exist, so the description bears the full burden. It does disclose the shape of the output (natural-language stage trace plus statistics, mirroring the dashboard), which is real value since there is no output schema, but it says nothing about whether the call is read-only, whether it re-runs a live query or replays recorded telemetry, cost/latency, or paging.

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, output described first, purpose second — well front-loaded with no filler. The parenthetical 'what the dashboard draws' is slightly cryptic and the whole definition is terse to the point of under-specification, but nothing is wasted.

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 three undocumented parameters, no annotations, and no output schema, the description is far too thin; an agent cannot tell what 'top' or 'urls' do or when to prefer this over web.stats. Only the output content is covered.

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% across three parameters (required 'query', plus 'top' and 'urls'), and the description explains none of them. 'top' and 'urls' are completely opaque from both schema and prose, 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?

States a specific resource: a full natural-language trace of pipeline stages plus statistics, framed as a debugging view of 'what happened'. That is more concrete than a restated name, though it never positions itself against the nearby web.stats or web.drift_report, which also surface pipeline data.

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 one implied trigger ('for debugging what happened') but names no alternatives and no exclusions (e.g., use web.stats for aggregate metrics only, use web.trace when you need stage-by-stage narrative). An agent must infer the boundary from sibling names 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?

With no annotations, the description carries the full behavioral burden. It discloses that candidates are processed in a single call and classified as survived / rejected / repaired, which is useful, but it never explains what 'repaired' entails, whether network access is required, or how failures are reported.

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 short (two sentences) and roughly front-loads the batch outcome states, so there is little padding. However, the compressed jargon and parenthetical asides ('dowód sensu auto-korektora', 'bez wynalazców') cost clarity rather than saving space.

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 four-parameter tool with no annotations, no schema descriptions, and no output schema, the description is far too thin. The outcome states partially substitute for a missing return-value description, but the roles of 'top' and 'query' and the meaning of 'repaired' remain unexplained.

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 four parameters, so the description must compensate. It only addresses 'serp' (default off) and loosely implies 'urls' via 'Partia kandydatów'; 'top' and 'query' receive no explanation 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 never states a clear verb+resource such as 'verifies that URLs resolve'. Instead it says 'Partia kandydatów w JEDNYM wywołaniu: survived / rejected / repaired', which only hints at batch processing with three outcome categories and relies on the tool name to convey that links are being verified. It does not differentiate from siblings like web.search or web.render.

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 only usage-related statement is 'serp domyślnie wyłączony' (serp off by default), which is a parameter default rather than guidance on when to choose this tool over web.search or web.render. There is no when-to-use, when-not, or alternative routing.

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