devtools-fleet-mcp

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

With no annotations, the description carries the full behavioral burden. It usefully discloses what survives (cookies, localStorage, open tabs) and one side effect ('Pages reload'), but omits what is lost (in-memory JS state, scroll position), whether it errors when no browser is running, and how long the relaunch takes. Partial disclosure, not a rich profile.

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 short sentences, front-loaded with the core action and preservation guarantee, then the parameter semantics, then the reload side effect. Every sentence earns its place and nothing is 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 with no output schema, the description covers the action, preserved state, parameter semantics, and reload behavior. The remaining gap is the default value/behavior of the optional headless parameter when omitted, which an agent would want to know.

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 parameter name ('headless') alone is ambiguous, but the description explains both boolean values with concrete intent ('visible window … headless: true to hide it again'), which is exactly the meaning the schema lacks. It does not state the default when the optional parameter is omitted.

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 ('Relaunch this session's browser') plus the scope that separates it from a fresh browser_start: cookies, localStorage and open tabs are preserved. It doesn't name the sibling it is contrasted with, but the session-scoped framing makes the distinction inferable.

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 a concrete use condition for one parameter value (headless: false so a human can watch or solve a captcha), but never says when to reach for browser_restart rather than browser_start, browser_stop, or a plain reload, nor what prerequisites exist (e.g. an active session). Usage is implied 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?

With no annotations, the description carries the full burden and does well: it discloses per-agent isolation, that a state-bound browser is restricted to that state's allowed origins, and that a browser surviving a reconnect is re-adopted with its tabs. It doesn't cover failure modes or what happens if a browser is already running with conflicting settings, leaving a small gap.

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

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

Front-loaded with the core action and the optionality caveat, then the explicit reasons to call it. Dense but every sentence carries information; the reconnect sentence is slightly tangential but useful.

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 six-parameter, all-optional tool with no output schema and no annotations, the description covers identity, isolation, origin restrictions, and reconnect behavior well enough to call it correctly. Return-shape details and behavior on a second call are the only notable omissions.

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 already 83%, but the description adds real meaning: it groups the tuning parameters (headless/viewport/channel), explains the state parameter's origin-restriction consequence, and cross-references state_list. It still doesn't clarify the distinction/additivity of allowedOrigins versus a state's own allowed origins.

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+resource ('Start this session's own Chrome') and immediately scopes it as isolated from every other agent, which cleanly separates it from siblings like browser_status, browser_restart and browser_stop. An agent can identify the tool's action and its unique session-scoped nature without opening the 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?

Explicitly says the call is optional because the first browser tool call starts one with defaults, then names the exact reasons to invoke it eagerly: load a saved login state, choose headless/viewport/channel, or open a URL. This is genuine when-to-use/when-not-to-use guidance with 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 burden. It does disclose the concrete state dimensions returned, which signals this is a non-mutating introspection tool, but it never states that it is read-only, that it requires an active session, or what happens if no browser is running. Adequate but incomplete for an unannotated tool.

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

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

A single front-loaded sentence that leads with the verb and subject and then lists the returned fields compactly. Every clause earns its place with 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?

With no output schema, the description usefully enumerates the returned state fields, which is the main thing an agent needs. For a zero-parameter, zero-risk status tool this is close to complete; only the precondition of an active browser session is unstated.

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 document; the schema coverage is 100% and there is nothing for the description to compensate for. Baseline 4 applies for a 0-param 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 (Show) plus the resource (this session's browser) and enumerates the exact fields returned (id, saved state, allowlist, headless, open tabs, uptime). That distinguishes it from sibling read tools like list_pages and state_list. It stops short of explicitly naming a sibling it is not, so a 4 rather than 5.

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 routing to alternatives. The phrase 'this session's browser' implies an inspection context, but the agent must infer that it precedes actions like browser_start or close_page. No exclusions or alternative conditions are 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?

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful destructive side effect — the temporary profile is deleted — but says nothing about what happens to open pages, whether the profile deletion is irreversible, whether it errors if no session is running, or whether a subsequent browser_start is 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?

One sentence, front-loaded with the primary action and the secondary side effect. No filler, no redundancy.

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 teardown tool with no output schema, the description covers the action and its cleanup effect adequately. It could be stronger by noting the fate of open pages and whether a restart is needed afterward, but nothing essential to invoking it 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 schema is empty and the baseline is 4. There is nothing further the description could add on parameter 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 and resource (close the browser) plus the notable side effect (delete the temporary profile). The scope word "this session's" distinguishes it from the sibling close_page, which closes a single page rather than the whole browser. It doesn't explicitly name an alternative, so it falls short of a 5.

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 explicit when-to-use guidance. The agent must infer that this is a teardown call for ending a browser session, and there is no statement about prerequisites (e.g. a running browser) or when browser_restart would be preferable.

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, confirming it is a mutating action, but the description adds nothing about consequences: whether the click may navigate, open tabs, or trigger dialogs, or whether it waits for the page to settle. For a mutation tool in a browser-automation suite, that leaves the agent without the behavior it needs to plan around.

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, front-loaded and free of padding, but it is concise to the point of under-specification rather than precision. There is nothing to trim, but the sentence earns its place only barely.

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?

A browser-click tool has complex, observable side effects, no output schema, and only one annotation. The description does not mention response contents (e.g., the optional snapshot), wait behavior, or failure modes, leaving significant gaps 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 coverage is 100%, with uid, pageId, dblClick, and includeSnapshot all documented in the schema. The description adds no meaning beyond that, so the schema-based baseline of 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?

States a specific verb (clicks) on a resource (element), but "the provided element" is vague and gives no hint of how this differs from sibling interaction tools like hover, drag, fill, or type_text. An agent must open the schema to learn what an element reference is.

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 click versus hover, drag, fill, type_text, or press_key, and no prerequisites or exclusions are stated. The agent must infer applicability from the tool 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?

Annotations only declare readOnlyHint=false, so the agent already knows this is a mutation. The description adds a meaningful behavioral constraint: the last open page cannot be closed. It does not explain what happens to page state, whether closing discards unsaved data, or what errors occur for invalid page IDs.

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 core action and followed by the key constraint. There is no unnecessary text.

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 page-closing tool with full schema coverage and no output schema, the description provides enough context to invoke it correctly. The minor gap is that it does not clarify the 'index' versus 'ID' terminology or the effect on the active page, but those are secondary for this operation.

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%, so the parameter is already documented as the page ID and the agent is told to call list_pages. The description adds little beyond restating the parameter, and it uses 'index' while the schema says 'ID', which is potentially ambiguous rather than clarifying.

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: 'Closes the page.' It also clarifies that the page is identified by index, which helps an agent understand the operation. However, it does not explicitly distinguish this tool from siblings such as select_page, new_page, or browser_stop, so it falls short of a 5.

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 provides no guidance on when to use close_page versus alternatives. 'The last open page cannot be closed' is a constraint on the action, not a usage guideline or comparison to sibling 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?

Annotations only declare readOnlyHint=false, so the description carries the burden of explaining the mutation, yet it says nothing about how the drag is performed (native HTML5 drag events vs. synthesized mouse move sequences), what side effects occur, or what happens if the drop target rejects the element. With only one annotation bit and a very terse sentence, this is a significant disclosure gap for an interaction tool prone to silent 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?

A single front-loaded sentence with zero waste. It is concise without being a tautology, though the brevity borders on under-specification for a browser interaction 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?

Four parameters, a mutation annotation only, and no output schema; the description does not cover viewport/visibility requirements, drag-mechanism caveats, or result expectations. An agent could invoke it but has little basis for predicting or diagnosing 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?

Schema description coverage is 100%, and every parameter (pageId, from_uid, to_uid, includeSnapshot) is documented in the schema itself. The description adds no meaning beyond the schema, so the 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?

Clear specific verb ('Drag') plus resource ('an element onto another element'), so the agent knows exactly what action is performed. It does not differentiate itself from nearby siblings such as click, hover, or fill, but the drag semantics are unambiguous.

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

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

No guidance on when to use this over click/hover/fill, and no prerequisites such as elements needing to be visible or dragged into the viewport first. Nothing says when drag will fail or what alternative to use instead.

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, so the description carries real weight, and it does add non-schema value: state is wholesale replaced per call, with extraHttpHeaders as the documented exception. It doesn't explain the effect of changing viewport mid-session or that omitted values clear overrides (that part lives in the schema).

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

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

Two sentences, zero waste, with the call-shape constraint placed up front so the agent reads it before composing arguments. Nothing redundant is restated from the schema.

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

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

For an 11-parameter, mutation-style tool with no output schema, the definition plus rich per-property schema docs cover what an agent needs. What's missing is only secondary: interaction with ongoing screencasts/snapshots and whether emulation persists across navigations (the description notes headers persist, implying other settings may behave differently).

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%, so the baseline is 3. The description adds a genuinely param-relevant semantic the schema doesn't state as a whole: settings are replaced, not merged, per invocation, which changes how an agent must fill all 11 parameters at once.

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 ("Emulates ... features on the target page"), so the operation type is clear. But "various features" is vague, and nothing distinguishes it from siblings that also alter page state (resize_page, navigate_page) or explains what kinds of features can be emulated without reading the 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 second sentence is a strong usage rule: every call replaces all settings except extraHttpHeaders, so all desired settings must be passed together. It steers how to compose a call but doesn't say when to emulate versus using resize_page or a real device/browser, and gives no 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?

The description adds real behavioral context beyond the single readOnlyHint=false annotation: output is returned as JSON so return values must be JSON-serializable, and the file/inline duality is explained. However, it omits the critical implication of arbitrary code execution — that scripts can mutate page state, trigger navigation, or have side effects — which is exactly what the false readOnlyHint warns about.

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: purpose first, source modes second, return-format constraint last. No filler, no repetition of the tool name, and the most consequential caveat (JSON-serializable returns) is stated plainly.

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 optional-heavy parameters, a single weak annotation (readOnlyHint=false), and no output schema, the description should disclose that arbitrary JS can mutate or navigate the page and that failures/console errors surface elsewhere (list_console_messages). It covers the return shape but leaves the risk profile and failure behavior to inference.

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 100% and the schema itself carefully documents format, args, function vs sourcePath, dialogAction, and waitForStableDom. The description only restates the inline-vs-file choice, adding nothing about the function/script distinction, dialog policy, or DOM-stability default. Baseline 3 is appropriate when the schema carries the load.

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: 'Evaluate JavaScript inside the target page', plus the two source modes (inline or local file). No sibling tool performs arbitrary in-page JS evaluation, so it is distinguishable by default, but the description never names an alternative or scope boundary 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?

There is no when-to-use vs when-not guidance, no mention of prerequisites (e.g., page must be selected/loaded), and no comparison to siblings like take_snapshot, get_console_message, or get_css_styles that cover narrower read needs. The only selection guidance ('inline or loaded from a local file') mirrors the schema's mutual-exclusion rule rather than adding usage 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?

The annotations only declare readOnlyHint=false, so the description adds value by specifying the element types it targets. However, it does not disclose important behavioral traits like whether it clears existing values, dispatches input/change events, or handles focus.

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, well-structured sentence with no wasted words. The action and targets 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?

For a mutation tool with four parameters and full schema coverage, the description is minimally adequate but lacks behavioral details that would help an agent use it correctly, such as event triggering or interaction with pre-existing values.

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%, so all parameters are fully documented in the schema. The description adds no additional meaning about parameters, which is appropriate given the high coverage.

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

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

The description uses a specific verb ('Type') and names the target resources (input, text area, select) clearly. It does not explicitly differentiate from sibling tools like type_text or fill_form, but the core action is unambiguous.

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

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

The description gives no indication of when to use this tool instead of alternatives such as type_text or fill_form. It provides only a bare statement of function without context or exclusions.

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?

readOnlyHint=false already tells the agent this mutates page state, and the description correctly reinforces that by describing the fill action plus a concrete example. However, it never says what happens on partial failure (do earlier elements stay filled?), whether values are validated, or that element uids must come from a prior snapshot. Its remaining content is a speed/reliability pitch rather than new behavioral fact.

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 short sentences, front-loaded with the capability, then the selection rule, then a concrete example. The middle sentence's 'significantly faster, more reliable, reduces turn count' is a mild sales pitch, but it is directly actionable guidance for tool selection.

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, so the description should cover the response: includeSnapshot partially explains this, but the description is silent on what a successful fill returns and on the prerequisite of obtaining uids via take_snapshot. Those two omissions are the only meaningful gaps for a 3-parameter mutation 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 100%, so the schema already documents pageId, elements[].uid, elements[].value, and includeSnapshot. The description adds only the illustrative username/password/'Remember Me' example, which hints at the array's batch shape but doesn't explain includeSnapshot or the checkbox/radio string conventions the schema handles.

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 (fill out) and resource (multiple form elements) and enumerates the element kinds covered (inputs, selects, checkboxes, radios). It also explicitly positions itself against the sibling tools 'fill' and 'click', so an agent can distinguish it from them without opening any schema.

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

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

Gives an explicit always-use rule with named alternatives: prefer this over multiple individual 'fill' or 'click' calls when interacting with forms. The converse case (use 'fill' when only a single element is targeted) is only implied 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?

readOnlyHint=true already declares this is a safe read, so the description doesn't need to restate safety. It adds the useful provenance hint that ids come from list_console_messages, but says nothing about what a message contains (text, level, source URL, stack trace) or what happens if the msgid is stale or belongs to another 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?

Two short sentences, front-loaded with the purpose and followed by the one routing fact an agent needs. Nothing extraneous.

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 two-parameter read tool with full schema coverage, a readOnly annotation, and no output schema, the description covers the essential workflow. The only real gap is return-value shape, which an agent would have to discover by 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 description coverage is 100%, so both params are already documented, and the description adds only the cross-reference that msgid values originate from the console-message listing. No format or edge-case guidance (e.g., numeric id validity, pageId/msgid pairing) beyond what the schema supplies.

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 ('Gets') plus resource ('a console message') and the key selector ('by its ID'). It also names the sibling tool list_console_messages, so an agent can immediately tell it apart from the bulk-listing counterpart.

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 tells the agent how this tool relates to list_console_messages, implying retrieval-after-listing as the intended workflow. It stops short of explicit exclusions (e.g., when to prefer the list tool and filter client-side), but the context is clear.

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?

Beyond the readOnlyHint annotation, the description discloses important output behavior: rules are ordered by cascade precedence, source line numbers are included, winning declarations have no prefix, overridden declarations are marked with [overloaded], and results are paginated. This gives the agent substantial context for interpreting and trusting the result.

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 purpose, followed by output semantics and pagination. Sentences are dense with useful information and there is no significant waste.

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?

Because there is no output schema, the description must explain what is returned. It does so thoroughly, covering rule sources, ordering, active/overridden notation, and pagination, while also stating the UID prerequisite.

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%, so all parameters already have documented meanings. The description adds little parameter-specific semantics beyond restating that pageIdx pages through remaining results and that UID comes from take_snapshot, both of which are already reflected in 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?

The description uses a specific verb, 'Retrieve', and a precise resource set: matched CSS rules, inline styles, inherited styles, custom properties, and cascade wrappers for an element identified by UID. It clearly distinguishes this as the CSS-inspection tool among the browser siblings.

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

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

It states the prerequisite that the UID must come from take_snapshot and explains how to page through results with pageIdx. It does not name explicit alternatives or when-not-to-use conditions, but the operational context is clear.

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?

The description adds real value by pointing at Cookie/Set-Cookie header inspection, which tells an agent why to call it. However, it never explains why a 'get' tool carries readOnlyHint=false — namely that requestFilePath/responseFilePath cause writes to disk and can clobber files. That side effect is consequential and is only visible in the schema.

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

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

Two compact sentences, front-loaded with the primary action and default behavior, then the value proposition. 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?

With no output schema, the description usefully signals what comes back (request and response headers and directives), and the schema covers the file-output variants. Minor gap: it does not clarify that bodies are returned inline by default, which matters for response size expectations.

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%, so all four parameters are already documented in the schema, including the file-path options. The description only restates the reqid/default-selection semantics and adds nothing about the two file-output parameters, so 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?

States a specific verb and resource ('Gets a network request') plus the lookup key (reqid) and the fallback behavior. It is distinguishable from the sibling list_network_requests by being single-request scoped, though it never names that sibling 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?

Gives clear context: pass a reqid, or omit it to get whatever is currently selected in the DevTools Network panel, and it explains the concrete use case (inspecting request/response headers including cookies). It stops short of stating when to prefer list_network_requests or any exclusions.

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 declare only readOnlyHint=false, so the description still carries most of the burden. It does not disclose the key behavioral trait of dialogs — that they block further page interaction until handled — nor the difference in effect between accept and dismiss beyond what the enum labels imply.

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 with the condition front-loaded and no waste. It is efficient, though the brevity comes at the cost of substance rather than being a model of dense information.

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 three-parameter tool with a fully documented schema and no output schema, the description covers the minimum: what it is for. It omits the blocking nature of dialogs and when to choose each action, which would matter for correct invocation sequencing.

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 100% and every parameter has an inline description, including the accept/dismiss enum and optional promptText. The description adds no meaning beyond that, so the 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 verb 'handle' is vague, but paired with 'browser dialog' it identifies a concrete resource, and the tool is distinguishable from siblings like click or navigate_page. It never states what 'handle' actually entails (accept/dismiss), which the schema alone reveals.

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 conditional 'If a browser dialog was opened' gives an implicit trigger condition, which is better than nothing. However, it offers no guidance on when to accept vs dismiss, no mention of ordering relative to other actions, and no sibling alternatives.

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?

The annotation readOnlyHint=false signals this is not a pure read operation, yet the description does not explain what hovering changes (tooltip, hover menu, CSS state) or whether the call waits for a hover duration. It adds essentially no behavioral context beyond the annotation.

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 sentence with no wasted words, but it is under-specified rather than appropriately concise for a three-parameter interaction tool. It does front-load the verb and target, which is the one structural strength.

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 schema covers all parameters and no output schema exists, so parameter-level needs are met, but the description omits what an agent should expect from a hover action and how includeSnapshot affects the response. For an interaction tool with only a readOnlyHint=false annotation, this leaves significant behavioral gaps.

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%, so uid, pageId, and includeSnapshot are already documented in the schema. The description's phrase "provided element" only loosely gestures at uid and adds no format or identification guidance beyond what the schema provides, making the baseline 3 appropriate.

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 ("Hover") and the resource it acts on ("the provided element"), so an agent can tell it performs a mouse-hover interaction rather than a click or drag. However, it includes no differentiation from siblings like click or drag, which also target elements.

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?

Provides no guidance on when to use hover versus click, drag, or evaluate_script. The implied use case (revealing hover-dependent UI) is left entirely to inference, with no exclusions or conditions 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 only declare readOnlyHint=false, so the description must explain why a read-style audit is flagged as non-read-only. It does so by disclosing that full reports are written to disk, which accounts for the write side effect, and it hints that 'navigation' reloads the page. It doesn't state permissions or report size/retention, leaving a small gap.

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

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

Three short sentences: capability, output location, and exclusion/redirection. The scope constraint and alternative are front-loaded with 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?

With no output schema, the description still tells the agent what comes back (scores, failing audits, flagged DOM nodes) and where full reports go, plus how to get the excluded category elsewhere. Nothing needed to invoke it correctly 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?

Schema description coverage is 100% and both enums are documented, so the schema already carries parameter meaning. The description's mention of reports saved to disk loosely ties to outputDirPath but adds no syntax or format detail beyond 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?

Names a specific verb and resource and enumerates the categories covered (accessibility, SEO, best practices, agentic browsing), plus explicitly what it excludes (performance). An agent can distinguish it from performance_start_trace and the snapshot/screencast siblings without opening the 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?

States the exclusion ('This excludes performance') and names the exact alternative tool and action to take instead ('run performance_start_trace'). Both the use case and the routing decision are explicit.

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, so safety is covered. The description adds the meaningful constraint that only messages since the last navigation are returned (with includePreservedMessages extending to three navigations left to the schema), but says nothing about ordering, volume, or output shape.

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 zero filler. Nothing is padded or repeated from the schema.

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

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

For a read-only listing tool with a fully documented schema, the description is adequate but leaves out the two things an agent most needs: how this differs from get_console_message, and the fact that preserved messages require an opt-in flag to be visible.

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%, so all seven parameters are self-documenting, including the filter, pagination, and preserved-message flags. The description adds no parameter insight beyond the schema, which is the baseline case.

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 ('List all console messages') plus a scope ('for the target page since the last navigation'). It does not distinguish itself from the sibling get_console_message, which fetches a single message, so an agent must infer the list-vs-single split.

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 guidance and no mention of the obvious alternative, get_console_message, or of when a bulk listing is preferable. The scope phrase hints at coverage but gives 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?

readOnlyHint=true already signals a safe read, and the description adds genuinely useful behavioral scoping: results are limited to the window since the last navigation. That window is the key non-obvious trait (the schema's includePreservedRequests only indirectly reveals the 3-navigation alternative), though ordering guarantees and response shape remain unstated.

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; the scope qualifier arrives immediately after the verb. It is efficient, though slightly thin given five parameters and no output schema.

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

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

With full schema coverage and a readOnly annotation, a short description can suffice, but for a 5-parameter list tool with no output schema the description says nothing about result shape, ordering, or whether the list is a point-in-time snapshot. It is adequate but leaves real questions for the agent to discover at call time.

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%, so pagination, filtering by resourceTypes, and preserved-request behavior are already fully documented. The description only echoes the page targeting and implies recency ordering ('most recent'), adding little beyond the structured field text.

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 (Lists) plus resource (network requests) scoped to a target page, which cleanly separates it from the single-item sibling get_network_request. It doesn't name that sibling explicitly, so differentiation is inferred from the singular/plural naming rather than stated.

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 by the phrase 'target page since the last navigation' – there is no statement of when to prefer this over get_network_request, nor any prerequisite such as the page needing to be loaded or selected first. An agent can guess the intent but gets no routing guidance.

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?

The annotation already declares readOnlyHint=true, and the description adds no behavioral context such as ordering, scope across windows, pagination, or what a page entry contains. It is minimally transparent but does not meaningfully go beyond the annotation.

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. It is appropriately concise, though it could be slightly more informative without becoming bloated.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description gives enough information to invoke the tool correctly. It could optionally mention return shape or scope, but the core invocation context is complete.

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 are no parameter semantics to clarify, and the empty schema is consistent with the 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 states a specific verb and resource: "Get a list of pages open in the browser." This clearly identifies a read-oriented listing tool, though it does not explicitly distinguish it from siblings such as state_list or select_page.

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 that the tool is used to see open pages, but it provides no explicit guidance on when to use it versus alternatives like state_list, select_page, or new_page. There are no exclusions or 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?

Annotations only declare readOnlyHint=false, so the description adds some value by naming navigation modes and the default project URL behavior. However, it does not disclose side effects such as page state loss, dialog handling, or script execution behavior during navigation.

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 no wasted language, and the core navigation behavior is front-loaded. The default-URL note is useful and compact.

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 schema is fully described and no output schema exists, which reduces the description's burden. Still, for a seven-parameter navigation tool, the description is terse and leaves important context implicit, especially around default type behavior and how this differs from related page 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?

Schema description coverage is 100%, so the schema already documents all seven parameters thoroughly. The description only adds a default-URL hint and broadly names the navigation modes, without meaningfully elaborating on pageId, timeout, initScript, ignoreCache, or handleBeforeUnload.

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: navigating a page by URL or through history actions. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as new_page or select_page.

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-like guidance is a default behavior: 'Use project URL if not specified otherwise.' There is no explicit guidance on when to choose this tool over new_page, select_page, or other navigation-related 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?

Annotations only set readOnlyHint=false, so the description carries most of the burden. It says a tab is opened, which is consistent with the mutation annotation, but doesn't disclose whether the new page becomes the active target (relevant given sibling select_page), whether the tab persists, or whether it operates in the same browser context by default. Only the schema fills that in.

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 action front-loaded and no filler. The second sentence is vague ('otherwise') and could have been replaced with actual guidance.

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 four parameters, one required, and no output schema, the description should indicate what the agent gets back (e.g., a page handle usable with select_page) and how the new tab relates to existing ones. The schema covers the parameters well, but the interaction model is left implicit.

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%, so all four parameters are already documented, which sets the baseline at 3. The description adds only the default-URL notion, and it muddles rather than clarifies semantics by implying url is optional when the schema requires 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: 'Open a new tab and load a URL.' This is clearly distinct from navigate_page (which navigates an existing page) and from select_page, though the description never names those siblings. Clear but not differentiated 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?

'Use project URL if not specified otherwise' is a hint about the url argument, not a when-to-use rule; it also conflicts with the schema marking url required. Nothing tells the agent when to use this over navigate_page or select_page, or what happens to the previously active 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?

The readOnlyHint annotation already declares this is a safe read, so the bar is lower. The description adds useful context that it drills into insights previously surfaced by a trace recording, but says nothing about what the returned detail looks like or any limits on valid insight names beyond the schema example.

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; the drill-down intent is stated immediately. It is compact but arguably under-specified rather than wasteful.

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-only, three-parameter lookup tool with full schema coverage and an annotations-declared safety profile, most needs are met. The gap is explaining the shape of the 'more detailed information' returned, since no output schema exists to carry that.

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%, so all three parameters (pageId, insightName, insightSetId) are already documented in the schema, including the example insight names and the 'use only ids from Available insight sets' constraint. The description adds no parameter meaning beyond that, making baseline 3 correct.

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 (provides detailed information) and a specific resource (a Performance Insight within an insight set from a trace recording). This distinguishes it from siblings like performance_start_trace and performance_stop_trace as a drill-down tool, though it doesn't 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 phrase 'of an insight set that was highlighted in the results of a trace recording' implies the workflow context (call after a trace surfaces insights). However, it never states explicitly when to use this versus performance_start_trace/stop_trace, nor any preconditions or exclusions.

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?

readOnlyHint=false is the only annotation, so the agent knows this is not a pure read, but the description never says the trace keeps recording until performance_stop_trace is called or that a file artifact may be written. The schema descriptions carry the reload/autoStop/cache nuances, which partially compensates.

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 with the action front-loaded and the diagnostic value second; 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 stateful tracing tool with no output schema and only a single loose annotation, the description omits the essential lifecycle (trace runs until stopped, analyze with performance_analyze_insight). An agent could call it but might not know what to do next.

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% and each parameter is documented at the schema level, so baseline 3 applies. The description adds no parameter-level meaning beyond that.

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 clear verb+resource ('Start a performance trace on the target webpage') and adds the diagnostic intent (frontend performance, Core Web Vitals). It doesn't distinguish itself from the sibling lighthouse_audit, which plausibly serves a similar diagnostic role, so 4 rather than 5.

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?

'Use to find frontend performance issues, Core Web Vitals (LCP, INP, CLS)' gives implied usage context, but there is no explicit when-not guidance and no mention of the sibling alternatives (lighthouse_audit, performance_analyze_insight) or of the required stop step.

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?

Only readOnlyHint=false is given, so the description carries the burden of explaining the mutation, yet it says nothing about what happens to captured data when filePath is omitted (discarded? returned?), how existing trace data is affected, or the error behavior with no active trace. These are exactly the details an agent needs before invoking a stop 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?

A single front-loaded sentence with zero filler, but its brevity is also what leaves the behavioral gaps unaddressed; efficiency is good, completeness is the tradeoff.

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 two-parameter tool with full schema coverage and no output schema, the definition is minimally sufficient, but an agent still cannot tell whether the trace result is saved, returned, or lost unless filePath is supplied.

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

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

Schema description coverage is 100%, and the filePath schema entry already explains absolute/relative paths and compressed vs uncompressed formats. The description adds no parameter meaning of its own, so the 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?

States a specific verb ('Stop') and resource ('active performance trace recording') with a clear scope ('target webpage'). It implicitly contrasts with the sibling performance_start_trace, though it never names it or another 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?

The word 'active' implies a trace must already be running, but the description never says to call performance_start_trace first, nor what happens if no trace is active. Usage is implied 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 declare readOnlyHint=false, so the agent knows this is a mutating action. The description adds some context by explaining use cases (shortcuts, navigation), but it does not disclose behavioral details such as whether the key press requires prior page focus, what happens on invalid keys, or any side effects. With annotations present, this is adequate but not rich.

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

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

Two sentences, front-loaded with the core action and immediately followed by a usage condition. No wasted words; every sentence adds value (purpose and when-to-use).

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 full schema coverage and a single annotation (readOnlyHint=false), the description covers purpose and primary usage well. It could mention prerequisites (e.g., a page must be active) or expected outcomes, but it is sufficient for correct invocation given the structured fields.

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%, so all parameters are fully documented in the input schema. The description repeats the concept of 'key or key combination' without adding syntax or usage details beyond what the schema already provides. Baseline 3 is appropriate when the schema carries the full parameter documentation.

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 (press) and resource (key or key combination), and explicitly distinguishes the tool from sibling fill() by naming a condition when fill() cannot be used. An agent can immediately understand the tool's unique role among input methods.

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 clear context for when to use this tool: 'when other input methods like fill() cannot be used' and lists examples (keyboard shortcuts, navigation keys, special combinations). It does not explicitly compare to other siblings like type_text, but the guidance is sufficient without being misleading.

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, confirming a mutation, but the description adds nothing about what changes: whether this affects the real browser window or an emulated viewport, whether it persists across navigation, or how it interacts with screenshots and screencasts. For a state-changing tool with no output schema, that leaves the agent guessing about side effects.

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. Minor grammar awkwardness ('specified dimension' should be plural) but nothing extraneous.

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 three-required-parameter mutation tool with minimal annotations and no output schema, the description should cover units, whether it is the real window or an emulated viewport, and persistence. None of that is present, so an agent cannot fully predict the call's effect.

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%, so pageId, width and height are already documented, and the baseline of 3 applies. The description adds no meaning beyond the schema — notably it does not state the unit (pixels) or any practical bounds for width/height.

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 ('Resizes') and resource ('the page's window') with the resulting effect ('page has specified dimension'), so the operation is unambiguous. It does not distinguish itself from the sibling 'emulate', which can also change viewport dimensions, leaving overlap unaddressed.

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 alternatives such as 'emulate', nor any prerequisites (e.g., page must be open, effect on active tabs). The agent must infer the usage context entirely from the one-line purpose.

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?

The only annotation is readOnlyHint=false, so the description carries most of the burden. It establishes recording of the target page but says nothing about the recording continuing until screencast_stop, where output is written (beyond the schema's filePath note), or any disk/resource implications of an in-progress capture.

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. It is efficient, but the terseness borders on under-specification for a stateful operation that requires a paired stop call.

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?

Two simple parameters, no output schema, and a thin annotation set — the description is adequate to identify the action but leaves out lifecycle context (stop requirement, output location, page prerequisite) that an agent needs to drive the tool 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 100%, with both pageId and filePath documented including the mkdtemp fallback behavior. The description adds nothing beyond the schema, so the baseline of 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?

Specific verb + resource + scope: 'Starts recording a screencast (video) of the target page.' It is clearly distinguishable from the sibling screencast_stop by the verb 'starts', though it never names that counterpart 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?

No when-to-use guidance, no prerequisites (e.g., that a page must be selected), and no mention of the screencast_stop sibling that must eventually be called. Usage is only inferable from the verb.

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 declare readOnlyHint=false, so the agent already knows this is a write/mutating operation. The description adds that the recording must be "active" and scoped to a target page, but says nothing about what happens to the captured data, what is returned, or behavior when no recording is 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?

One short sentence with no filler, front-loading the verb and resource. It is appropriately sized for a trivial single-parameter tool, though it could have used a second clause for the no-active-recording case.

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-required-param mutation with annotations and no output schema, the definition is minimally adequate. It omits edge-case behavior (no active recording) and whether the recording result is delivered anywhere, which an agent would want to know before calling.

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% and the single pageId parameter is already documented in the schema as targeting a specific page by ID. The description restates the page scoping but adds no format, default, or validation detail beyond 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 ("Stops") and resource ("the active screencast recording on the target page"), which pairs naturally with the sibling screencast_start. It doesn't explicitly name the sibling as the counterpart, so it stops short of full 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 only implied: one infers this is called after screencast_start to end capture. There is no explicit statement of when to use it versus alternatives, prerequisites, or what to do if no recording is active.

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, so the safety profile is covered. The description adds useful behavioral context by saying the selection affects future tool calls, but it does not disclose persistence details or the side effect of focusing the page when bringToFront is used.

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. Every part of it contributes to understanding the tool's core effect.

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 two-parameter context-selection tool with full schema coverage and an annotation marking it read-only, the description is largely complete. It explains the tool's effect on future calls, though it could say more about page-context persistence and the optional bringToFront 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?

Schema description coverage is 100%, and both parameters are documented in the schema, including guidance to call list_pages for pageId. The description adds no parameter-level meaning beyond the schema, so the baseline score of 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 specific verb and resource: selecting a page. It also explains the effect—establishing context for future tool calls—which distinguishes it from page-listing or navigation tools, though it does not explicitly name 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 phrase 'as a context for future tool calls' implies when the tool should be used, but the description gives no explicit when-not guidance or alternative routing. The schema mentions list_pages for obtaining page IDs, but the description itself does not cover prerequisites or alternatives.

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 present, the description carries the full burden, and it does disclose a meaningful behavioral trait: cookie values are never exposed, only metadata such as cookie counts and first-expiry time. It stops short of covering anything else behavioral, but for a parameterless read tool the disclosure is substantive.

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 that front-loads the action and then lists returned fields, closing with the most important caveat. No filler and nothing misordered.

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?

There is no output schema, so the enumeration of returned fields (name, origins, cookie counts, saved time, first expiry) and the no-cookie-values caveat do the work the schema would otherwise do. The only minor gap is that questions of ordering, volume, or scoping of the listing are 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?

The tool takes zero parameters, so the schema sets the baseline at 4. The description adds no parameter detail because there is none to add, and correctly focuses on the returned shape instead.

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 (saved login states), and enumerates the fields it returns. It is distinguishable from the sibling state_save by the list-vs-save framing, though the sibling is not named 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?

The nature of the operation (read-only enumeration with no parameters) makes the intended use implied rather than stated. There is no explicit when-to-use guidance, no mention of state_save as the counterpart action, and no prerequisites or exclusions.

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 delivers meaningful behavior: allowedOrigins defaults to open http(s) tab origins, can never exceed the browser's own allowlist, and states created via `devtools-fleet login` are protected from overwrite. It doesn't spell out what cookies outside the allowlist undergo (dropped silently) or auth prerequisites, but the disclosure is strong.

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

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

Front-loaded with the core action, then behavioral caveats in descending importance. Four tight sentences with no filler, though the allowlist constraint is restated in two adjacent sentences.

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 stateful save operation with no annotations and no output schema, the description covers the critical behaviors an agent needs (origin scoping, overwrite protection, default derivation). Only minor gaps remain around failure modes and return 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?

Schema coverage is 75% and the schema already documents name, strict, and allowedOrigins. The description adds genuine meaning beyond the schema by explaining allowedOrigins' default derivation and its hard upper bound, plus the overwrite protection behavior that bears on the overwrite flag.

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+resource+payload: 'Save the current browser's login (cookies + localStorage) as a named state.' The purpose is unambiguous and distinguishable from the sibling state_list, which the agent can infer handles the read side.

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 rationale 'so other sessions can start already logged in' implies when this is useful, and constraints on allowedOrigins scope are given, but there is no explicit when-to-use vs when-not guidance and no mention of the sibling state_list as an alternative.

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?

The annotations declare only readOnlyHint=false, leaving the description to explain why this counts as a write. It never states that a file is written to disk at filePath, that the snapshot can be large or slow, or whether the page is paused. It does add purpose context (memory-leak debugging) that the annotations do not provide.

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

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

Two sentences, front-loaded with what the tool does followed by when to use it. Every phrase carries information and nothing is 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 two-parameter, no-output-schema tool, the description covers the action and purpose adequately; the output destination is clear from the required filePath. Minor gaps remain around side effects (disk write, snapshot size) that an agent would benefit from knowing before invoking.

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%, so both pageId and filePath are already fully documented in the schema. The description adds no format, path convention, or overwrite behavior beyond what the schema states, so the baseline of 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 gives a specific verb and resource ('Capture a heap snapshot of the target page'), which is clearly distinct from takeover siblings like take_screenshot or take_snapshot. It does not explicitly say how it differs from take_snapshot, but the memory/heap framing does the differentiating work.

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?

'Use to analyze the memory distribution of JavaScript objects and debug memory leaks' gives a use case, so the intent is implied rather than absent. There is no guidance on when to prefer this over alternatives such as performance_start_trace or performance_analyze_insight, and no exclusion 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?

Annotations only supply readOnlyHint=false, so the description carries the burden of behavioral disclosure and adds none. It doesn't say where the image lands (attached to the response vs. written to disk via filePath), whether the target page must be active, or how large captures are handled. Only the schema hints at these behaviors.

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 waste, but it is undersized for a six-parameter tool with a file-writing side effect. Concision here shades into under-specification.

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 required pageId and the main option set are covered by the schema, and there is no output schema to explain. What's missing is guidance on the response/attachment behavior and on which capture target to choose for which intent, which matters for a tool with six interacting options.

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%, so all six parameters are already documented, including the uid/fullPage incompatibility and quality's irrelevance to PNG. The description's only added semantic is the page-vs-element choice, so baseline 3 is right.

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 ('take a screenshot') and distinguishes the two capture targets (page vs. element). It does not differentiate itself from nearby siblings like take_snapshot or screencast_start, which capture similar visual state in different forms.

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 on when to prefer this over take_snapshot, screencast_start, or evaluate_script, and no mention of prerequisites such as an active page selection. The page-vs-element distinction is only implicitly conveyed by the phrase 'or element'.

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 carry readOnlyHint=false, leaving most behavior to the description, which does add useful context: uid-based element identity, the staleness rule, and the DevTools Elements-panel selection marker. It does not explain what the non-read-only hint means in practice (snapshot written to disk via filePath vs attached to response), nor snapshot size/verbosity implications.

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

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

Front-loaded with the core action in the first sentence, and each following sentence carries a distinct rule (uid identity, staleness, screenshot preference). Slightly encumbered by the parenthetical DevTools-panel remark, but no real waste.

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, so the description must convey the return shape, and it does describe a list of elements with uids. The remaining gap is that the effect of `verbose` on what comes back and the exact entry format are left implicit.

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%, so all three parameters are already documented in the schema; the description only reinforces the general notion of element entries and uids. It adds no extra meaning about `verbose` or `filePath` beyond the schema text, so the 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?

Specific verb and resource: 'Take a text snapshot of the target page based on the a11y tree', plus it explains what a snapshot contains (page elements with unique uids). It also distinguishes itself from take_screenshot by stating the snapshot should be preferred, so an agent can separate it from 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?

Gives clear operative guidance: 'Always use the latest snapshot' and 'Prefer taking a snapshot over taking a screenshot', which explicitly routes behavior against the nearest alternative. It stops short of stating when a snapshot is NOT appropriate (e.g., visual/CSS verification where a screenshot is required) or what to do if the page changes mid-flow.

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 supply readOnlyHint=false; the description adds real behavioral context by clarifying that keystrokes go to whatever is already focused rather than a targeted element. It does not cover what happens if nothing is focused, whether existing text is cleared, or error behavior for a mutation tool.

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

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

A single front-loaded sentence with zero filler; the most decision-relevant constraint (prior focus) appears 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?

For a simple 3-param interaction tool with no output schema, the description covers the core action and focus precondition, but leaves out sibling disambiguation and failure semantics, which matter for an agent choosing between typing, filling, and key-pressing.

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 100%, so text, pageId, and submitKey are already documented in the schema. The description adds no parameter-level meaning (e.g., it never mentions submitKey's role), so the baseline of 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?

States a specific verb (type) and mechanism (keyboard input) plus a key precondition ('previously focused input'). It does not distinguish itself from siblings like fill, fill_form, or press_key, which is the main clarity gap.

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?

'Previously focused input' implies a prerequisite (focus first) but never says when to use this versus fill/fill_form or press_key. Usage is inferable rather than explicit, and no exclusions or alternatives are named.

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 supply readOnlyHint=false, so the description must carry the rest of the behavioral burden. It does not mention that this mutates page state, that files must be local to the browser instance (a critical, non-obvious constraint that lives only in the schema), or what happens on failure or with multiple file paths.

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 action front-loaded. It is efficient, though its brevity reflects omission rather than disciplined 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?

For a mutating browser-automation tool with no output schema and no meaningful annotations, the description is far too thin. An agent gets no guidance on the snapshot/uid workflow, file path semantics, or whether the page changes after upload.

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%, so the schema already explains every parameter including the important browser-local path constraint. The description adds no parameter meaning beyond what the schema provides, which lands at the baseline.

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 ("Upload a file") but qualifies it with the vague phrase "through a provided element," which is only explained by the schema. It does nothing to distinguish this from siblings like fill, type_text, or evaluate_script, which an agent might otherwise consider for interacting with file inputs.

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 indication of when to use this tool versus alternatives, nor any prerequisite context such as needing the uid from a snapshot or requiring the target element to be a file input. The agent must infer the workflow entirely from the schema.

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?

The description provides crucial behavioral context that goes beyond the basic annotation (readOnlyHint). It specifically highlights the default matching behavior (hidden text is matched) and explains how to override this using the 'visible' parameter, which is key to correct tool 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 exceptionally concise, uses a logical two-sentence structure, and places the most important behavioral detail (default matching) immediately in the first sentence.

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 high complexity (4 parameters, timeout handling, visibility logic), the description is sufficient to use the tool, but it lacks high-level contextual guidance on expected latency or failure modes typical of browser polling 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?

Although the schema is 100% covered, the description adds semantic value by summarizing the behavior of the 'visible' flag and explaining the logic of the 'text' array (resolves when any value appears), thus helping the agent understand the parameters' effects.

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 clearly states the tool's function: waiting for specific text to appear on a page. While clear, it is a standard polling/wait action, lacking specific context of *why* this is distinct from other actions like 'type_text' or 'click'.

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 are no explicit usage guidelines or context provided regarding when an agent should choose this wait action over other sibling tools. It describes what the tool does, not why the agent should use it.

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