Server Quality Checklist

Tool Scores

• evaluate_jsA
  3.6/5.0
  Behavior2/5

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

  With no annotations beyond a title, the description carries the full burden for behavioral disclosure. Evaluating arbitrary JavaScript can cause side effects, modify page state, or access sensitive data, but the description only says 'Evaluate javascript in page' without warning about these risks or explaining what happens upon execution.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of two sentences that front-load the core purpose and add a useful pointer to an alternative. There is no verbose or redundant content, making it easy to parse.

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

  Completeness3/5

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

  The tool is simple with one parameter and no output schema, but the description lacks essential context for safe and correct use, such as parameter details and potential side effects. The alternative guidance adds some context, but the overall description is adequate only for tool selection, not for confident invocation.

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

  Parameters2/5

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

  The schema has one parameter ('expression') with 0% description coverage. The tool description indirectly implies that the expression is JavaScript to execute, but it does not clarify whether statements vs. expressions are accepted, return value handling, or async behavior. This is insufficient for an agent to craft correct invocations.

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

  Purpose5/5

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

  The description clearly states that the tool evaluates JavaScript in the page, using a specific verb and resource. It also distinguishes itself from a sibling tool by directing users to get_inspected_element for accessing the selected element ($0), showing awareness of related tools.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance for an alternative scenario (accessing the selected Element panel element with get_inspected_element). However, it does not mention other relevant alternatives like evaluate_at_frame for evaluating in a specific frame, leaving some usage context implicit.

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

• get_computed_styleA
  3.6/5.0
  Behavior3/5

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

  With readOnlyHint=true, the annotation covers the safety profile. The description adds the 'computed' qualifier, clarifying that it returns resolved styles rather than inline or default values, but does not disclose edge cases like missing elements or invalid property names.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no fluff. Every word contributes to clarifying the tool's purpose.

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

  Completeness4/5

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

  For a simple read-only tool with two well-defined parameters and an output schema, the description is sufficient. It conveys the essential function, though it omits any mention of error behavior or handling of non-matching selectors, which would be useful but not critical.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline applies. The description paraphrases the schema ('given properties' and 'element matched by selector') without adding additional semantic details such as return format or default behavior.

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

  Purpose5/5

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

  The description clearly states the tool retrieves computed CSS values for specified properties on a selector-matched element, using a specific verb and resource. It distinguishes from sibling tools like get_html or get_title by focusing on computed styles.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as evaluate_js or get_inspected_element. The description simply states the operation without context on selection criteria or exclusions.

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

• get_console_logsA
  4/5.0
  Behavior4/5

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

  Annotations mark the tool as read-only, and the description adds useful context: it includes pre-existing DevTools messages and source-mapped stack traces. This exceeds the annotation without contradicting it.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the primary purpose. The second and third sentences efficiently detail buffer behavior and exception formatting with no fluff.

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

  Completeness4/5

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

  The description covers core behavior, historical buffer inclusion, and exception handling, which is sufficient for a read-only logging tool. An output schema exists to define return structures, so the description does not need to explain them.

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

  Parameters3/5

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

  The input schema already provides 100% description coverage for all parameters (clear, level, limit). The tool description adds no parameter-specific meaning, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description states a clear action ('Return') and specific resource ('browser console messages and uncaught exceptions'). It distinguishes itself from sibling debugging tools by focusing on console output, not DOM state or script execution.

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

  Usage Guidelines3/5

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

  The description implies usage when you need console messages or uncaught exceptions, but it does not explicitly compare against alternatives or state when not to use it. The buffer inclusion detail hints at historical retrieval, but no direct guidance is provided.

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

• set_breakpointA
  4/5.0
  Behavior3/5

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

  Annotations include idempotentHint=true, which already communicates that repeated calls are safe. The description adds no extra behavioral context such as whether existing breakpoints are overwritten, persistence, or side effects. With annotations present, the bar is lower, but the description still adds minimal value beyond 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. It communicates the essential purpose and selection criteria in under 15 words.

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

  Completeness4/5

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

  With a fully descriptive schema and an output schema present, the description only needs to summarize the core action, which it does. It does not mention optional parameters like condition or columnNumber, but their absence is acceptable since the schema covers them. The description is sufficient for an agent to select and invoke the tool.

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

  Parameters3/5

  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 mentions URL (exact or regex) and line number, but those are already fully described in the schema. It does not add additional meaning about condition, columnNumber, or precedence rules, which are also covered by the schema.

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

  Purpose5/5

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

  The description clearly states the action ('Set') and resource ('breakpoint'), and specifies the key inputs (URL exact or regex + line number). It distinguishes this from sibling tools like remove_breakpoint and list_breakpoints by focusing on creation.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (to create a breakpoint) by naming the selection method (URL exact/regex) and line number. It does not explicitly mention alternatives or when not to use it, but the context is unambiguous for a simple tool. No exclusions are needed given the sibling list.

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

• step_intoA
  4/5.0
  Behavior3/5

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

  No annotations beyond the title are provided, so the description carries the burden. It discloses that it returns the new call stack position, which is valuable. However, it does not mention potential side effects like changing debugger state explicitly, nor prerequisites like a paused debugger, leaving some behavioral details implicit.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the action and the return value. Every word is necessary; no filler or redundancy. Perfectly concise.

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

  Completeness4/5

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

  For a simple tool with no parameters and an output described in the text, the description is largely complete. It lacks explicit mention of prerequisites (e.g., debugger must be paused) and potential error conditions, but these are reasonably inferred from the sibling context and debugger domain.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description adds no parameter information, which is appropriate since there are none. No further elaboration is needed.

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

  Purpose5/5

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

  The description uses a specific verb ('step into') and resource ('the function call on the current line'), clearly distinguishing it from sibling tools like step_over and step_out. The purpose is immediately obvious and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies its usage (to enter a function call) but does not explicitly state when to use it over alternatives like step_over or step_out. No exclusions or prerequisites are mentioned, making it functionally clear but with implied guidance only.

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

• step_outA
  4/5.0
  Behavior3/5

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

  Annotations only provide a title, no behavioral hints. The description does disclose that execution pauses and that a new call stack position is returned, but it does not mention that the debugger must already be paused or that this mutates debugger state. This is partial transparency.

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

  Conciseness5/5

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

  Two sentences, no filler. The description is front-loaded with the action and immediately gives the return value. Every word earns its place.

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

  Completeness4/5

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

  For a zero-parameter debugger command, the description covers the action and return value sufficiently. However, it omits any reference to prerequisites (e.g., execution must be paused) or side effects beyond pausing, slightly reducing completeness.

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

  Parameters4/5

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

  The tool has zero parameters, and schema coverage is 100%. With no parameters to document, the baseline is 4, and the description adds no param info needed.

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

  Purpose5/5

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

  The description clearly states the action: 'Step out of the current function and pause at the caller.' This is a specific verb+resource phrasing that distinguishes it from siblings like step_over and step_into.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (when you want to exit the current function), but it does not explicitly contrast it with alternatives such as step_over or step_into. No exclusions or alternative conditions are provided.

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

• switch_tabA
  4/5.0
  Behavior3/5

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

  With only a title annotation (no readOnly/destructive hints), the description carries the burden of disclosing behavior. It states the action ('Switch the MCP connection') and gives a prerequisite, but it does not explicitly describe the effect on subsequent commands, error behavior, or reversibility. This is a moderate level of transparency, sufficient for a simple state-changing tool.

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

  Conciseness5/5

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

  The description is two sentences with no redundant words. It is front-loaded with the core action and includes a practical usage hint. Every sentence earns its place.

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

  Completeness4/5

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

  The tool has a single parameter and an output schema (not detailed here). The description explains what the tool does and the prerequisite for the parameter, which is adequate for a simple switching tool. It could mention the persistent effect on subsequent MCP calls, but 'Switch the MCP connection' sufficiently implies that. Overall, it is complete for this complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%: the parameter targetId is described as 'Target ID from list_tabs.' The tool description reinforces this by saying 'Use list_tabs first to get available targetIds.' The description adds no new meaning beyond the schema, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Switch the MCP connection to a specific Chrome tab.' This uses a specific verb ('switch') and resource ('Chrome tab'), and it distinguishes itself from siblings like list_tabs (listing) and get_url (reading). The purpose is unambiguous.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance: 'Use list_tabs first to get available targetIds.' This tells the agent when to use this tool and what prerequisite to satisfy. It does not explicitly name alternatives or exclusions, but for a simple switching operation 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.

• evaluate_at_frameA
  4.2/5.0
  Behavior3/5

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

  Annotations provide only a title, so the description carries the burden. It discloses the pause requirement and the exact scope access, but it omits potential side effects of evaluating arbitrary JavaScript and any error behavior. This is a notable gap for a tool that executes code.

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

  Conciseness5/5

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

  The description is three short sentences, each adding unique value: purpose, differentiation, and a critical limitation. No redundancy or fluff; well front-loaded.

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

  Completeness4/5

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

  Given the schema covers parameters and the description explains purpose and constraints, it is largely complete. However, with no output schema and minimal annotations, it does not describe return values or error conditions, leaving some ambiguity for the agent.

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

  Parameters3/5

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

  Both parameters have schema descriptions, and the description does not add parameter-specific details beyond what the schema provides. The context of frame scope is mentioned, but not tied directly to frameIndex. Schema coverage is 100%, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it evaluates a JavaScript expression in the scope of a paused call frame, and explicitly contrasts with evaluate_js, noting access to local/closure/this. This firmly distinguishes it from sibling tools like evaluate_js and get_scope_variables.

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

  Usage Guidelines5/5

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

  It explicitly names evaluate_js as an alternative and describes the difference, while also stating the prerequisite that execution must be paused. This gives clear when-to-use and when-not-to-use guidance.

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

• remove_breakpointA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds meaningful context: the ID becomes invalidated after removal and restoration produces a new ID. This informs the agent about side effects beyond the basic destructive flag, which is valuable behavioral disclosure.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every word adds value. It includes the key caveat (ID invalidation) and a hint about restoration without unnecessary elaboration.

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

  Completeness4/5

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

  For a simple destructive operation with one parameter and no output schema, the description covers the essential behavior, side effects, and an alternative. It does not mention error handling or return values, but these are not critical for such a focused tool given the siblings and annotations.

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

  Parameters3/5

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

  The schema provides only a required breakpointId string with no description (0% coverage). The description identifies it as 'a breakpoint by ID', linking the parameter to its role, but does not explain how to obtain the ID or its expected format. This is adequate but leaves some gap.

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

  Purpose5/5

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

  The description clearly states the action ('Remove a breakpoint') and the resource ('by ID'), making the tool's function unambiguous. It also distinguishes itself from sibling tools like set_breakpoint and list_breakpoints by focusing on removal and noting the restoration path.

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

  Usage Guidelines4/5

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

  The description provides practical guidance: it explicitly mentions using set_breakpoint to restore a removed breakpoint, which implies a clear alternative. It also notes the invalidation of the ID, helping the agent decide when this tool is appropriate. A brief mention of prerequisites (e.g., needing an existing breakpoint ID) would make it fully explicit.

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

• resume_executionA
  4.2/5.0
  Behavior3/5

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

  There are no behavioral annotations (no readOnlyHint or destructiveHint), so the description must carry the full burden. It states the core operation but does not disclose potential side effects, error cases (e.g., calling when execution is already running), or return values. This is minimal but not misleading, earning a borderline average score.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that communicates the action and trigger condition without unnecessary words. It is appropriately sized for a tool with no parameters and no complex semantics.

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

  Completeness4/5

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

  The tool is simple with no output schema, but the description explains when to invoke it (after a breakpoint or pause) and what it does (resume execution). While it lacks detail on error behavior or side effects, this is a minimal debugger control operation, and the description is sufficient for an agent to use it correctly in most scenarios.

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

  Parameters4/5

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

  The input schema has zero properties, meaning there are no parameters to describe. Per the rubric, a zero-parameter tool receives a baseline score of 4 because the description cannot add parameter meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the specific action ('Resume') applied to the resource ('JavaScript execution') and the condition ('after a breakpoint or pause'). This distinguishes it from sibling tools like pause_execution and the step_* commands, which serve different debugger control functions.

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

  Usage Guidelines4/5

  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 the tool ('after a breakpoint or pause'), implying it should be used when execution is paused. It does not explicitly mention alternatives or exclusions, but sibling tool names like step_over and step_into signal that resume is for continuing normal execution, providing adequate guidance.

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

• get_titleA
  4.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds the detail that it refers to the currently connected tab and that it's from `document.title`, which provides minor context. However, it doesn't describe the return format or any edge cases, though these are not critical for such a simple tool.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no superfluous words. It is front-loaded with the action and resource, and the technical detail is in parentheses. This is maximally concise.

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

  Completeness5/5

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

  For a simple getter with no parameters and no output schema, the description fully covers what the tool does. The low complexity means no further behavioral details are needed. The mention of `document.title` adds implementation clarity, making it complete.

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

  Parameters4/5

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

  The tool has zero parameters, so the description need not explain parameters. The baseline for zero-parameter tools is 4, and the description appropriately says nothing about parameters, as there is nothing to add beyond the empty schema.

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

  Purpose5/5

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

  The description clearly states the tool gets the title of the currently connected tab, with a specific verb ('Get') and resource ('title of the currently connected tab'). It also references `document.title` for exactness. This distinguishes it from sibling tools like get_url or get_html.

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

  Usage Guidelines4/5

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

  The description implies clear usage: use when you need the title of the current tab. While it doesn't explicitly exclude alternatives or name a sibling, the purpose is so self-evident that no further guidance is necessary. The context is clear, but there's no explicit comparison to alternatives.

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

• pause_executionA
  4.3/5.0
  Behavior3/5

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

  With only a title annotation (no readOnly/destructive hints), the description carries the full burden. It discloses the immediate pause behavior and hints at the halted state by mentioning inspection of the call stack. However, it does not mention that execution remains suspended until an explicit resume action is taken, which is a notable behavioral detail. This is a moderate gap for a debugger control tool.

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

  Conciseness5/5

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

  The description is exactly two sentences. The first sentence states the core action with the adverb 'immediately' adding useful nuance. The second sentence points to a supporting tool. There is no fluff or redundancy—every word earns its place.

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

  Completeness5/5

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

  For a zero-parameter, no-output-schema tool, the description is complete: it states what the tool does and offers a follow-up action. The sibling list shows this is part of a debugging suite, so the lack of extensive detail is acceptable. The description fully covers the tool's simple purpose.

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

  Parameters4/5

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

  The tool has 0 parameters and an empty input schema, so per the rubric the baseline is 4. The description adds no parameter-specific semantics because none are needed. The schema already covers everything, and the description does not attempt to invent parameters.

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

  Purpose5/5

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

  The description clearly states the action: 'Pause JavaScript execution immediately.' This is a specific verb+resource that distinguishes it from sibling tools like resume_execution, step_over, and get_debugger_state. The follow-up sentence provides additional context about its role in the debugging workflow.

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

  Usage Guidelines4/5

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

  The description implies when to use the tool (to pause execution) and provides a clear next step: 'After pausing, use get_debugger_state to inspect the call stack.' It does not explicitly state when not to use it or discuss alternatives, but the context is clear and the sibling tool reference helps orient the agent.

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

• get_inspected_elementA
  4.4/5.0
  Behavior4/5

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

  The description discloses a key behavioral trait: the tool depends on a prior marking step, not just a read of a live selection. This goes beyond the readOnlyHint annotation by explaining the stateful prerequisite. It does not mention the failure mode if no element is marked, but the output schema likely covers the return shape.

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

  Conciseness5/5

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

  Two sentences: the first states the purpose, the second gives the prerequisite procedure. No filler or repetition, and the critical info is front-loaded.

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

  Completeness4/5

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

  For a simple getter with no parameters and an output schema, the description covers the essential 'how' and 'when.' The only minor gap is not stating the behavior when no element has been marked, but this is a low-complexity tool and the description is otherwise complete.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description provides no parameter-specific semantics because there are none, and no schema coverage is needed.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Get the element marked for MCP inspection.' The verb 'Get' plus the specific resource 'inspected element' distinguishes it from sibling getters like get_html or get_computed_style. The additional instruction on how to mark an element removes ambiguity.

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

  Usage Guidelines4/5

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

  It provides explicit steps to prepare the element for inspection ('select it in the Elements panel, then run window.$0 = $0'), which is practical usage guidance. While it doesn't explicitly state 'use this when you need the inspected element reference,' the context implies it, and no alternatives are mentioned.

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

• get_debugger_stateA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a non-mutating operation. The description adds value by detailing the returned state components (pause reason, hit breakpoints, call stack), helping the agent anticipate the response. It doesn't mention edge cases like behavior when not paused, but the annotation covers the safety profile.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the main action and resource, then lists specifics in a compact list-style format. Every word earns its place with no filler or repetition.

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

  Completeness5/5

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

  With zero parameters and an output schema available, the description sufficiently covers the tool's purpose and scope. It names the key elements of the debugger state, making it complete for a read-only state getter.

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

  Parameters4/5

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

  The input schema has zero parameters, so there is no parameter semantics to clarify. The description appropriately focuses on the tool's output instead, and the baseline for a no-parameter tool is 4.

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

  Purpose5/5

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

  The description opens with 'Get current debugger state' and enumerates specific elements: paused status, pause reason, hit breakpoints, and full call stack with file/line info. This clearly distinguishes it from sibling debugger tools like get_scope_variables or list_breakpoints.

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

  Usage Guidelines4/5

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

  The description provides clear context on what the tool offers (current state information), making it straightforward for an agent to decide when to use it. However, it does not explicitly mention alternatives or exclusion cases, so it stops short of a 5.

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

• get_htmlA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a safe read operation, and the description adds useful behavioral detail by disclosing the 20,000-character truncation limit. It also names the exact DOM method, which gives transparency about how the HTML is retrieved. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loads the core action, and includes only essential caveat information (truncation). There is no fluff or repetition of what the schema already states.

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

  Completeness5/5

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

  For a simple, parameterless, read-only tool, the description covers the essential information: what it does, the exact extraction method, and the truncation limit. No output schema exists, but the return type (HTML source as a string) is evident from the description. The context is fully adequate.

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

  Parameters4/5

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

  There are zero parameters, so the schema leaves no ambiguity. The description adds value by clarifying the scope ('currently connected tab') but does not need to explain parameters that don't exist. The baseline of 4 for no-parameter tools is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Get') and resource ('full HTML source of the currently connected tab'), and even cites the exact DOM expression (`document.documentElement.outerHTML`). This clearly distinguishes it from siblings like get_url or get_title, which focus on different aspects of the page.

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

  Usage Guidelines4/5

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

  The description gives clear context by specifying it operates on the 'currently connected tab' and implies its purpose as a full-page HTML getter. However, it does not explicitly mention when to avoid it or point to alternatives such as get_title or get_url, though the sibling list makes those options visible.

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

• get_urlA
  4.5/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, and the description adds context by specifying it operates on the 'currently connected tab' and reveals the underlying `location.href` attribute. This clarifies scope without contradicting annotations.

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

  Conciseness5/5

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

  One sentence, concise and front-loaded, with zero redundant words.

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

  Completeness5/5

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

  For a getter of the current tab's URL, the description is complete. It states the exact resource, the implementation, and the read-only safe behavior covered by annotations. No output schema needed since the value is self-evident.

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

  Parameters4/5

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

  The tool has zero parameters, so there is no ambiguity to resolve. Baseline for no params is 4, and the description adds no unnecessary parameter details.

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

  Purpose5/5

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

  The description clearly states 'Get the URL of the currently connected tab' with a specific verb and resource, and includes the `location.href` implementation detail. This unambiguously distinguishes it from sibling tools like get_title or get_computed_style.

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

  Usage Guidelines4/5

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

  The description makes the tool's purpose self-evident, implying usage when the current tab's URL is needed. However, it does not explicitly state alternatives or exclusions, so it falls short of full guidance.

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

• list_breakpointsA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it only shows breakpoints created through this server, and explains the CDP limitation (no API to enumerate all breakpoints). This is valuable for setting expectations, though it does not detail the response format (which an output schema likely covers).

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

  Conciseness5/5

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

  The description is two clear sentences, front-loaded with the action and scope, and adds a useful caveat without any wasted words.

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

  Completeness5/5

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

  With zero parameters and an output schema present, the description needs only to clarify the tool's scope and limitations, which it does thoroughly. The note about CDP's enumeration limitation is an important piece that makes the description self-contained.

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

  Parameters4/5

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

  The tool has zero parameters, so the description carries no parameter burden. A baseline of 4 is appropriate since there is nothing additional to explain.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and the resource 'breakpoints tracked by this server', distinct from sibling tools like set_breakpoint/remove_breakpoint. It also differentiates by explicitly excluding breakpoints set via DevTools UI or other CDP clients, which removes ambiguity.

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

  Usage Guidelines4/5

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

  The description provides clear context: use this to list breakpoints set via set_breakpoint on this server. It implicitly warns against expecting externally-set breakpoints by stating they are not visible, which guides when not to use this tool. It does not name an alternative explicitly, but the context is sufficient.

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

• screenshotA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint: true, and the description adds valuable context: the output is PNG format, and it captures only the visible viewport rather than the entire page or UI elements. This is sufficient behavioral disclosure for a zero-parameter tool.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence that leads with the action ('Capture') and immediately clarifies scope with a parenthetical. No wasted words.

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

  Completeness5/5

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

  With no parameters and no output schema, the description fully specifies what the tool does, its output format, and its limitations. The sibling tools are all functionally distinct, so no additional guidance is needed.

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

  Parameters4/5

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

  The tool has no parameters, so the description does not need to explain any. The schema has no properties, and the baseline for 0 parameters is 4, which is appropriate here.

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

  Purpose5/5

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

  The description uses the specific verb 'Capture' and identifies the resource as 'a PNG screenshot of the current viewport', with explicit exclusions (not full scrollable page, not browser chrome, not DevTools) that clearly differentiate it from any sibling tool.

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

  Usage Guidelines4/5

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

  The description provides clear context by specifying what is captured (current viewport) and what is excluded (full page, chrome, DevTools), giving the agent decision criteria. However, it does not explicitly name an alternative tool or state a when-to-use condition, so it falls just short of a 5.

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

• step_overA
  4.5/5.0
  Behavior4/5

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

  Annotations only provide the title, so the description carries the burden of behavioral disclosure. It explains that execution pauses at the next line, that function calls are not entered, and that the new call stack position is returned. This is adequate but does not mention potential edge cases (e.g., behavior at function boundaries) or that execution must already be paused.

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

  Conciseness5/5

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

  The description is a single sentence that is front-loaded with the primary action, concise, and contains no fluff. Every word adds value.

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

  Completeness5/5

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

  Given that there are no parameters and no output schema, the description fully covers the tool's behavior and return value. It is sufficiently complete for an AI agent to understand how to use it correctly.

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

  Parameters4/5

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

  The input schema is empty (0 parameters), so the baseline is 4 per the rubric. The description does not need to explain parameters as there are none.

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

  Purpose5/5

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

  The description clearly states the tool's action: execute the current line and pause at the next line. It explicitly notes that it does not enter function calls, which distinguishes it from sibling tools like step_into. The return value (new call stack position) is also stated.

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

  Usage Guidelines4/5

  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: when you want to execute a line without stepping into function calls. The phrase 'does not enter function calls' serves as a when-not condition, but it does not explicitly name alternative tools like step_into or step_out. However, the implied usage is clear.

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

• get_scope_variablesA
  4.7/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description adds that the tool only functions while paused and that frame indices come from get_debugger_state, giving important operational context. No contradiction with annotations.

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

  Conciseness5/5

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

  Two concise sentences that front-load the purpose and include essential usage guidance without fluff.

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

  Completeness5/5

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

  Given the readOnlyHint, complete parameter schema, and presence of an output schema, the description fully covers the tool's context, prerequisites, and usage, making it complete for an inspection tool.

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

  Parameters4/5

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

  The schema already covers both parameters with descriptions, but the description adds the crucial link between frameIndex and the debugger state, enhancing parameter semantics beyond the schema.

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

  Purpose5/5

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

  The description uses the specific verb 'Inspect' with the resource 'variable values in a call frame scope,' clearly distinguishing it from debugger control tools like pause_execution or evaluate_at_frame.

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

  Usage Guidelines5/5

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

  It explicitly states a precondition ('Only works when execution is paused') and directs users to call get_debugger_state first to obtain frame indices, providing clear usage guidance and a sibling alternative.

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

• list_tabsA
  4.7/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint: true, which the description reinforces by using 'List.' The description adds workflow context about presenting the list to the user and proactively calling it when unsure, which goes beyond the annotation's minimal information. However, it does not disclose potential ordering or pagination behavior, though for a simple list tool this is minor.

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

  Conciseness5/5

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

  The description is two sentences. The first sentence states the core function, the second provides usage guidance. Every word earns its place, with no redundancy or fluff.

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

  Completeness5/5

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

  For a zero-parameter list tool with an output schema and a clear read-only annotation, the description fully covers what the tool does, when to use it, and how to handle the results. It is complete for its simplicity, leaving no significant gaps.

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

  Parameters4/5

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

  There are zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details, and the schema is empty because no input is needed. No additional parameter semantics are required.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'List all open Chrome page tabs with their targetIds, titles, and URLs.' The verb 'List' is specific and the resource ('Chrome page tabs') is unambiguous, distinguishing it from sibling tools like switch_tab or get_title.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: 'When you are unsure which tab to inspect, call this proactively to discover available tabs, then present the list to the user and ask which one to switch to.' It also offers an exclusion: 'do NOT tell the user to switch tabs manually in Chrome,' clearly positioning this tool as the alternative to manual user action.

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