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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds a genuine behavioral contract: it returns pass/fail with short evidence and never returns images. It stops short of describing timing behavior (waitFor), timeouts, or what happens on partial failure.

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 tightly packed sentences, front-loaded with the capability list and closed with the distinguishing return constraint. No filler, no repetition of the title.

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 5 parameters, nested check objects, and no output schema, the description adequately covers purpose and return shape but leaves the caller without guidance on timing (waitFor), viewport/darkMode, or how min/max/impact interact with the check types. Enough to call it, not enough to call it well.

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 only 20%, so the description should compensate. It partially does by enumerating the check kinds ('text present, element visible/hidden, element count, no console errors, no horizontal overflow, no a11y violations'), which map to the checks[].type enum, but it says nothing about waitFor, darkMode, viewport, or the min/max/impact/selector fields.

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 (assert/check) and resource (live page) and enumerates the exact check categories: text, visibility, count, console errors, overflow, a11y. The clause 'Never returns images' implicitly separates it from ui_capture, so an agent can route between the two 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?

The word 'cheap text-only' implies this is the lightweight alternative to screenshot-based siblings like ui_capture, but no sibling is named and there is no explicit when-not condition. Usage is inferable rather than stated.

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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real behavior: the return payload is a text summary listing title, console errors, failed requests, overflow and a11y violations, and the image only comes back on the first capture of a label or with includeFull=true. It stops short of saying whether re-capturing a label overwrites the stored baseline, which is the one mutation detail still missing.

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 tight sentences, front-loaded with what it does, then the return shape, then the call-ordering rule. No filler and no repetition of schema content.

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 8 parameters, 88% schema coverage and no output schema, the description usefully fills the return-value gap by naming the summary fields. Everything an agent needs to call it correctly at the right moment is present.

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 88%, so the schema already documents most parameters and the baseline of 3 applies. The description earns the bump by clarifying includeFull's conditional semantics (image returned only on first capture of a label or when includeFull=true) beyond the schema's bare 'Also return the full screenshot'.

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?

Specific verb+resource: screenshots a page and persists it as the baseline for a label. It also implicitly distinguishes itself from ui_diff by framing itself as the producer of the artifact ui_diff consumes.

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

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

Explicit sequencing guidance ('Call this BEFORE editing so ui_diff has something to compare against') names the sibling alternative and the condition that requires this tool first. That is the exact routing information an agent needs.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond those flags: the concrete detection heuristics and the fact that results are unverified 'candidate' URLs rather than confirmed servers.

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 tight sentences with no filler: the first gives the action plus detection sources, the second gives the return shape. Front-loaded and appropriately sized for a zero-parameter tool.

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, the description correctly supplies the return contract ('candidate base URLs') and the detection sources. It stops short of saying what an empty result means or whether multiple candidates are ranked, but nothing essential for correct invocation is 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 tool takes zero parameters, so the baseline is 4 — there is nothing for the description to clarify and no ambiguity an agent could stumble into when invoking it.

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 ('Find running local dev servers') and enumerates exactly how detection is performed (UI_LOOP_URL env, Next.js .next/dev/lock, specific ports). It also states the return type. No sibling (ui_capture, ui_diff, ui_list, etc.) overlaps this discovery function, so an agent can select it unambiguously.

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 — an agent would call this to discover a base URL before capture/assert operations — but the description never states when to use it or what to do if detection fails. There is no explicit alternative to route against, so the gap is moderate rather than severe.

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?

Annotations only declare readOnlyHint=false and idempotentHint=false; the description goes well beyond that by disclosing the key side effect ('The new capture becomes the baseline'), the truncation policy (only changes that 'fit within maxTokens', largest first, omitted regions enumerated), and the degraded no-baseline mode. These are exactly the traits structured fields cannot express.

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?

Four tight sentences with no filler: action first, then return payload, then truncation handling, then side effect and fallback. Every clause earns its place and the most decision-relevant facts are front-loaded.

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 9 parameters, the description still fully describes the return contract (text summary plus cropped changed-region images, largest first, budget-limited, omissions listed) and the state-mutating side effect, which is the maximum an agent needs before calling 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?

Schema coverage is 89%, so the baseline is 3, but the description adds real meaning: it ties 'label' to the baseline selection ('the baseline for its label'), explains that maxTokens gates which regions are returned at all, and clarifies the default/override relationship for 'baseline'. It does not cover the viewport or waitFor semantics, leaving a small 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 states a specific verb chain and resource ('Re-capture a page, pixel-diff it against the baseline for its label') and explicitly contrasts itself with siblings ui_capture (fallback when no baseline exists) and ui_region (fetching omitted regions). An agent can distinguish it from all six sibling tools without opening a 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?

It gives clear context: use this to see what changed against an existing baseline, and it names the fallback behavior ('If no baseline exists, behaves like ui_capture') plus the follow-up path via ui_region for regions dropped by the token budget. It stops short of an explicit 'prefer this over ui_capture when...' rule, but the routing is inferable and mostly spelled out.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the critical behavioral fact that omitting the parameter widens the blast radius to every label, which is exactly the disclosure that matters for a destructive default-scope operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action and resource, with the optional-parameter semantics attached directly. No 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?

For a one-parameter destructive tool with no output schema, the description plus annotations cover action, scope, default behavior, and safety. It leaves unstated whether deletion is permanent/recoverable, which is the only notable omission.

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 lone parameter carries no description, so the description must compensate — and it does, by defining what 'label' selects and what its absence means. It stops short of naming the label format or where labels come 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?

States a specific verb ('Delete') and resource ('stored captures') plus the scoping axis ('for a label, or all labels'). It is clearly distinguishable from siblings like ui_capture and ui_list, 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?

Usage is implied rather than stated: the agent can infer this is the cleanup path for captures created by ui_capture, but there is no explicit when-to-use, when-not-to-use, or named alternative. Adequate but with a clear gap.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds value beyond that by disclosing the scope of the listing (labels plus ids and sizes) and the backing location .ui-loop/captures, which is useful context since no output schema exists.

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 zero filler; the verb, the resource, the returned fields, and the storage path all appear immediately.

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 parameters, no output schema, and annotations covering the safety profile, the description supplies the remaining essentials: what is listed and where it lives. It stops short of describing ordering, pagination, or behavior on an empty store, but nothing critical to invocation is 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description does not need to explain argument semantics.

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 (List) and resource (labels and their stored captures), and even names the returned fields (ids, sizes) and the storage location (.ui-loop/captures). It is clearly distinguishable from siblings like ui_capture or ui_forget, though it does not explicitly name an alternative.

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 only implied: the agent can infer this is the way to inspect what is currently stored before diffing, asserting, or forgetting. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as ui_forget for cleanup.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that the crop is returned at higher resolution, which is useful context, but says nothing about the maxTokens-capped return or what happens when captureId is omitted beyond the schema note.

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 tight sentences with zero filler; the core action is front-loaded before the region-form detail.

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?

No output schema exists, and the description never indicates what comes back (an image crop consumed as tokens, presumably governed by maxTokens). Combined with the un-explained label parameter, an agent has to infer the return contract.

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 50%, so the description must compensate. It does clarify the dual form of region and its provenance from ui_diff, which the schema's anyOf does not express, but label and the defaulting behavior of captureId/maxTokens are left entirely to the schema.

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 ('Fetch a single crop from a stored capture') plus a key differentiator ('at higher resolution'), which separates it from a full capture. It does not explicitly contrast with ui_capture, so sibling differentiation is only partial.

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 through the region provenance note — 'a diff region index (from ui_diff output)' — which tells the agent this follows a diff workflow. There is no explicit when-to-use vs when-not guidance or statement of alternatives such as ui_capture.

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