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

With no annotations provided, the description carries the burden of behavioral disclosure, and it does a solid job: it states that arbitrary JavaScript is evaluated, that expressions, functions, async functions, and complex code are supported, that results are returned, and that execution can target the whole page or an element. It does not warn about side effects or serialization edge cases, but the examples and execution modes give an agent a clear picture of how the tool behaves.

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 core purpose is front-loaded in the first sentence, and the examples are useful for conveying accepted code shapes. Some redundancy exists because the examples in the description mirror those already present in the schema's function property, but the description remains compact and scannable rather than 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?

The description covers the main invocation contract and code formats, and the schema fills in the remaining parameter semantics. However, there is no output schema and no mention of how results are serialized or what error behavior looks like, which leaves some ambiguity for a complex JavaScript-evaluation tool. It is adequate for basic use but not fully 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 input schema covers all six parameters with descriptive text, including detailed examples for the function parameter and explanations for args, element, timeout, contextId, and returnType. The description adds little beyond what the schema already provides, so the baseline score of 3 is 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?

The description clearly states that this tool evaluates JavaScript in the browser context and returns a result, with explicit mention of targeting either the page or a specific element. It is distinct in function from the sibling DOM inspection and screenshot tools, but it does not explicitly differentiate itself from execute-browser-commands, so it falls just 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 guidance is given about when to choose this tool over alternatives such as execute-browser-commands, get-element-properties, or capture-screenshot. The examples illustrate accepted code formats but do not state when this tool is the right choice or when a sibling would be better.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It does disclose useful behavior: the screenshot is stored in the MCP resource system, a resource URI is returned, and base64 output is conditional on an environment variable. However, it does not mention that providing a URL causes the browser to navigate first, nor does it state that an active browser/context 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?

The description is compact and front-loaded: the core capability appears in the first sentence, followed by return behavior and the conditional base64 detail. Every sentence earns its place with no repeated or extraneous 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?

The description explains the return mechanism (resource URI and conditional base64) despite the lack of an output schema, which is helpful. However, it omits important operational context: a browser must already be running or otherwise available, and the navigation side effect when url is supplied is not surfaced in the main description. These are meaningful gaps for an agent deciding whether and how to invoke the 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 url, selector, and contextId clearly. The description adds little parameter meaning beyond echoing the current-page versus element distinction, which is already present 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 clearly states a specific action ('Captures a screenshot') with a clear resource scope: the current page or a specific element. It is immediately distinguishable from the sibling get-element-* and browser-evaluate tools, which are about inspecting properties and running scripts rather than producing a screenshot.

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 when to use the tool—when a screenshot is needed—but it does not explicitly state when not to use it or name alternative tools. The optional URL, selector, and contextId guidance lives only in the schema, so the natural-language description alone gives no usage context beyond the obvious screenshot case.

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

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

No annotations are provided, so the description must disclose behavioral implications. It does not mention side effects of closing (e.g., whether open tabs are lost, whether the process is terminated, whether it is reversible), nor does it state what happens if the contextId is invalid. For a mutating operation, this is a significant 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?

The description is a single efficient sentence with no filler words. It clearly communicates the action and target without redundancy or unnecessary detail.

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

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

For a simple one-parameter tool, the description is minimally adequate. However, because there is no output schema and no annotations, it does not explain how to discover contextId, whether the operation returns a value, or how errors are handled. This leaves an agent without enough context for fully reliable 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?

The input schema covers the only parameter, contextId, with the description 'ID of the browser to close,' giving 100% schema coverage. The tool description does not add additional meaning beyond the schema, so the baseline 3 is 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?

The description uses a clear verb and resource: 'Closes a specific browser instance.' This distinguishes it from siblings like start-browser and list-browsers by naming the action and target. It could be slightly improved by noting that the instance is identified via contextId, but the core 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.

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

No guidance is given on when to use this tool versus alternatives like start-browser or list-browsers, nor is there any mention of how to obtain contextId. The description implies usage only at the most basic level ('close something'), 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?

No annotations exist, so the description must disclose behavior on its own. It only says 'safely' and lists commands, without noting side effects, sequential execution semantics, error/failure behavior, or return value shape. The coordinate reference note is helpful, but the description does not disclose that commands can navigate, click, mutate state, or that continueOnError controls failure handling.

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 moderately sized and well-structured: a one-line summary, a scannable command list, and a focused coordinate note. There is no fluff, and the pointer to examples in the schema avoids unnecessary duplication.

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

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

The tool is highly complex with 15 command types and per-command args, and the schema handles that well. However, the description does not explain what the tool returns, whether commands execute in order, what happens on failure, or how timeout and contextId interact. For an agent deciding whether to use this plus how to interpret results, these are material 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 the baseline is 3. The description adds value with the coordinate-system note: for mouse commands coordinates are viewport-relative with (0,0) at top-left, which is not fully explicit in the individual parameter descriptions. The command list also clarifies the allowed command vocabulary.

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 clear verb and resource: 'Executes a sequence of predefined browser commands safely.' The appended command list makes the scope concrete and distinct from single-action sibling tools like capture-screenshot or get-element-properties. It is specific, not tautological.

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

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

No guidance is given on when to prefer this tool over individual browser tools, when a sequence is needed, or when a more targeted sibling like browser-evaluate or get-element-properties would be better. The word 'sequence' implies multi-step use, but that is left to inference 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 burden of disclosing behavior. It establishes a read-oriented retrieval action and specifies the source as the development server, but it does not describe whether logs are paginated, what 'limit' does exactly, what a checkpoint is, or how the returned logs are structured.

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 names the action, the target, and the environment in a compact way.

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 tool with two optional, fully described parameters, the description is minimally viable. However, it lacks any statement about expected return shape, prerequisites such as a running development server, or when not to use this tool, and there is no output schema or annotations to cover those 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?

The schema already documents both parameters with 100% coverage, so the description adds little parameter-level meaning. The description does not explain how limit and checkpoint interact, but the schema descriptions are sufficiently detailed to set a baseline of 3.

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 ('Retrieves') and a specific resource ('console logs'), and 'from the development server' gives scope. It does not explicitly contrast with sibling tools like get-hmr-events or get-context-stats, but the resource name is distinct enough to make the tool's purpose identifiable.

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 guidance about when to prefer this tool over alternatives. There is no mention of use cases, exclusions, or sibling tools, so an agent is left to infer context purely from the name and the short description.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only says 'gets detailed information,' which is the bare operation; it does not clarify what information is included, whether the call is read-only, or what errors or edge cases may occur.

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

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

The description is a single short sentence with no filler, and the key action is front-loaded. It is concise, though slightly vague by using 'detailed information' without elaboration.

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 should convey what kind of detailed information the agent will receive, but it does not. It also leaves ambiguity with the sibling get-context-stats, making the definition incomplete for an agent deciding which tool to invoke.

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 required parameter contextId is already described as 'ID of the browser to inspect.' The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is 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?

The description states a clear verb ('gets') and resource ('detailed information about a specific browser instance'), so the core action is understandable. However, it does not distinguish this from get-context-stats, which sounds closely related, so it misses the full sibling-differentiation bar.

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 guidance on when to use this tool instead of alternatives like get-context-stats, list-browsers, or get-context-info-related tools. There are no conditions, exclusions, or references 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not state it explicitly, doesn't explain what 'usage statistics' contains, and gives no details about return format, side effects, or implications of omitting contextId. The parameter description partially covers the default-all behavior, but the tool description itself reveals almost nothing.

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 sentence with no filler, and it is appropriately front-loaded with the action and resource. It is concise but slightly under-specified; nonetheless, structure is not the issue.

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

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

Given no output schema, no annotations, and a loosely defined 'usage statistics' term, the description is incomplete for an agent to know what response to expect or when this tool is the right choice. The optional parameter behavior is in the schema, but the core meaning of the returned stats is missing, making the overall definition insufficient for confident invocation.

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

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

Schema description coverage is 100% and the sole parameter, contextId, is well-described in the schema as optional with a clear default behavior. The tool description adds no additional parameter meaning, but none is needed since the schema already explains the semantics. Baseline 3 applies here.

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

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

The description uses a specific verb ('Gets') and resource ('usage statistics for browsers'), which conveys a read operation on browser usage data. However, 'usage statistics' is vague—it doesn't specify whether these are CPU/memory metrics, session counts, or something else—so it leaves room for interpretation. It is still distinguishable from siblings like get-context-info and get-console-logs, but not precisely.

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 this tool versus alternatives such as get-context-info or get-console-logs. There are no stated conditions, exclusions, or references to sibling tools, leaving the agent to infer appropriate usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool reads dimension/position data but omits any detail about coordinate system (viewport/document), units, behavior when selector matches no element, or whether layout must be settled. This is a meaningful ambiguity.

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; the core information is front-loaded and concise.

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?

Without an output schema, the description should specify the return structure (e.g., width, height, x/y coordinates and coordinate system). It gives a high-level summary that is minimally viable but leaves important operational details undefined.

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 a clear description of the selector parameter, so the schema already fully documents the input. The tool description adds no parameter-specific meaning, but 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?

Clearly states the action (retrieves) and resource (dimension and position information of a sspecific element). The resource is specific enough to distinguish from sibling getters like get-element-styles or get-element-html, though it doesn't explicitly name an alternative.

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

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

No guidance on when to choose this tool over siblings such as get-element-properties or get-element-styles. The description only states what it does, leaving the agent to infer 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the tool returns HTML and supports depth control, but it does not describe the exact return payload or any side effects. For a read-only inspection tool, this is a modest but acceptable 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?

A single, front-loaded sentence conveys the core action, target, scope, and key option. There is no redundant wording or repetition of schema details.

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 relatively simple read-only tool with three parameters, the description plus fully documented schema provides enough information to invoke it correctly. It does not explain the exact return format, but that omission is minor given the availability of output examples over time and the clear purpose.

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 the baseline is 3. The description adds meaning by clarifying that the tool returns content for the element and its children, which goes beyond individual parameter descriptions and helps interpret depth and includeOuter behavior.

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

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

The description uses a specific verb ('Retrieves') with a concrete resource ('HTML content of a specific element and its children') and mentions depth control. This clearly distinguishes it from sibling inspection tools like get-element-properties or get-element-styles.

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 context is implied: this tool should be used when HTML content is needed, as opposed to properties, styles, or dimensions. However, it does not explicitly say when not to use it or mention alternatives to consider.

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 of behavioral disclosure. 'Retrieves' implies a read operation, but the description does not mention what happens for non-existent elements, invalid property names, missing selectors, or whether the tool returns raw values, computed values, or serialized objects. This leaves meaningful behavioral gaps for an agent.

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 clear sentence with no filler and no repetition. The core action and target are front-loaded, making it easy to parse and remember.

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 fully documented schema, the description is minimally viable. However, with no annotations and no output schema, it would benefit from stating return behavior or edge cases (e.g., error when element is not found). It is adequate but not thorough.

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 input schema already fully documents both `selector` and `properties` with examples. The description adds little beyond the phrase 'state information,' which hints at properties like checked or selected but does not materially extend what the schema already provides. Baseline 3 is 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?

The description uses a specific verb ('Retrieves') and identifies the resource ('properties and state information of a specific element'). It distinguishes from sibling tools like get-element-styles, get-element-dimensions, and get-element-html by focusing on arbitrary properties and state, though it does not explicitly name those alternatives.

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

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

The description gives no guidance on when to use this tool versus get-element-styles, get-element-dimensions, get-element-html, or browser-evaluate. There are no stated exclusions, prerequisites, or alternative-selection hints, so an agent must infer the appropriate use case from the tool list 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Retrieves style information' without specifying whether these are computed styles, inline styles, what happens if the element is missing, or the format of the returned values. It does not contradict any annotations, but it is far too minimal.

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, concise sentence with no redundant wording. It is front-loaded with the action and resource, making it easy to scan, though some brevity comes at the cost of missing behavioral context.

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

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

With no annotations and no output schema, the description should provide more context about return values, computed versus inline style semantics, and error behavior. The schema covers the parameters, but the overall behavioral contract is incomplete for an agent deciding how to use this tool.

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

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

Schema description coverage is 100%, so both parameters are already documented with clear descriptions and an example for styleProperties. The description adds no parameter-level meaning, 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.

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

The description clearly states the verb 'Retrieves' and the resource 'style information of a specific element', making the tool's purpose understandable. It also differentiates well from sibling tools like get-element-properties and get-element-dimensions, though it does not explicitly contrast with them.

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

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

No guidance is provided about when to use this tool over alternatives such as get-element-properties, get-element-html, or browser-evaluate. The name implies a use case, but the description offers no conditions, 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 provided, the description bears the full burden of behavioral disclosure, but only restates the basic action. It doesn't mention side effects, whether events are cleared on retrieval, how 'recent' is defined, or the source/scope of the events. This leaves the agent unaware of important behavioral nuances.

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 concise sentence with no redundancy, and the core action is front-loaded. It is appropriately brief for a simple getter, though the lack of supporting context limits its overall usefulness.

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

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

The tool has no annotations, no output schema, and no description of return structure or scope. In a suite of browser tools with similar log/event retrieval functions, the description doesn't clarify what HMR events are or when to use this tool, making it insufficient for fully informed selection and 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?

The input schema already describes the only parameter, limit, with 100% coverage, so the baseline is 3. The description adds no extra meaning about limit usage, but none is required given the schema's clarity.

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 'Retrieves recent HMR events' states a specific verb and object, clearly identifying the tool's function. It names a distinct resource type (HMR events) that isn't covered by any sibling, though it doesn't explicitly explain the acronym or contrast with alternatives.

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

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

The description provides no information about when to use this tool versus its siblings such as get-console-logs or monitor-network. There are no exclusions, preconditions, or context cues to guide selection.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses nothing about side effects, return shape, prerequisites, or limitations. The text is a placeholder and adds no transparency about how the tool behaves.

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 short but not usefully concise; it is under-specified placeholder text that does not earn its place. A single vague sentence without concrete content is closer to omission than to effective conciseness.

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?

Even though the tool is simple with one parameter, the description gives an agent almost nothing to work with. It does not explain what 'checkpoint' or 'hmr' sections contain, what the output looks like, or how this tool fits into the broader browser automation context. This is incomplete for reliable invocation.

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

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

Schema description coverage is 100%, including a meaningful enum and description for the 'section' parameter. Per the rubric, this warrants a baseline 3 even without parameter details in the description. The description adds no extra parameter meaning, but the schema already documents the single parameter adequately.

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

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

The description is a tautology: "Description of how to use the server" essentially restates the tool name without saying what the tool actually does. It does not specify a concrete verb, what resource it operates on, or what outcome the agent can expect.

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 this tool versus the many sibling tools. There is no context, no alternatives, and no exclusions. The section enum hints at checkpoint/hmr content, but the description itself gives no usage direction.

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 behavioral transparency burden. The verb 'Lists' strongly implies a non-mutating read operation, which is helpful. However, it does not clarify how 'active' is determined, whether filters combine, or what the response contains beyond the inferred list of browsers.

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 or redundant content. Every word contributes meaning, and it communicates the core intent 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 low-complexity read-only listing tool with no required parameters and fully documented optional filters, the description is reasonably complete. It does not detail return shape or edge cases like zero active instances, but those are minor given the simplicity of the 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 input schema already documents all three parameters (tags, type, includeStats) with adequate descriptions. The tool description itself adds no additional parameter-level detail, so the baseline score of 3 is 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?

The description 'Lists all active browser instances' uses a specific verb ('Lists'), a clear resource ('browser instances'), and a scope qualifier ('active'). It is clearly distinct from sibling operations like start-browser or close-browser, though it does not explicitly differentiate from get-context-info or other query-like tools.

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 usage context is implied: use this when you need to see currently active browser instances. However, there is no explicit guidance about when to prefer list-browsers over related tools like get-context-info, nor any mention of exclusions or prerequisites.

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

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

No annotations are present, so the description carries the burden. 'Monitors' suggests passive, non-destructive observation, which is useful, but the description does not disclose whether results are returned immediately, whether the tool blocks until the duration elapses, or how filtered requests are surfaced. Basic transparency, but not rich behavioral detail.

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, focused sentence that front-loads the main purpose and includes the key variable. There is no fluff or repetition, so every word earns its place.

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

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

With no output schema and no annotations, the description should clarify what the result looks like and whether the tool has side effects. It says only that it 'monitors'network requests, leaving the agent unknowing about return format, timeouts, default behavior, or empty-result handling. For a simple tool this is minimally usable, but incomplete.

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 parameters are already documented by the schema. The description reinforces the 'duration' concept but adds no meaning beyond the schema for urlPattern. Baseline 3 is 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?

The description clearly states the action ('Monitors'), the resource ('network requests in the browser'), and the primary scoping input ('for a specified duration'). This distinguishes it from siblings like get-console-logs and get-hmr-events, which target different data streams.

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 when to use the tool—when network request monitoring is needed—but it does not explicitly explain when to prefer it over alternatives or when not to use it. It provides enough context, but no exclusions or sibling routing.

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 transparency burden. It discloses that an ID is auto-generated, but it does not say that this launches a persistent browser process, that the instance can later be closed with close-browser, or what happens after creation. The lifecycle and side-effect behavior is left unexplained.

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 one sentence with no filler and front-loads the action and resource. It is efficient, but at nine words it is arguably too terse for a tool with seven optional parameters and no annotations, so it does not earn a 5.

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 should say what the tool returns and how to use the generated ID with sibling tools, but it only hints at an auto-generated ID. It also omits the persistence/cleanup lifecycle. The full parameter schema prevents this from being a 1, but the missing output and lifecycle context is significant.

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 input schema documents all 7 parameters with descriptions, so the baseline is 3. The description adds no parameter-level detail beyond clarifying that the ID is auto-generated, which helps explain why no ID parameter is needed. That is marginal but sufficient.

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

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

The description names a specific action ('Creates'), a specific resource ('new browser context'), and an outcome ('auto-generated unique ID'). This clearly separates start-browser from siblings list-browsers and close-browser, which manage existing contexts.

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 verb and 'new' imply this tool should be used when a fresh browser context is needed, but the description does not explicitly state when not to use it or point to alternatives such as list-browsers for existing contexts. No prerequisites or cleanup guidance is provided.

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