TraeBridge MCP Server

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

With no annotations, the description carries the full behavioral burden, and it discloses only that the target is the current tab and the return is raw. It does not say that arbitrary CDP commands can mutate or destroy page state, whether the call blocks or times out, or how errors surface.

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

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

Two short sentences, front-loaded with the action and target, with no wasted words. The trailing 'Use with care' is terse but carries little information.

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

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

For an open-ended passthrough tool with a free-form params object and no output schema, the description covers scope (current tab) and return shape (raw response) but omits risk profile, failure behavior, and any hint about the domain of valid CDP methods.

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

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

Schema description coverage is 100% and both parameters (method, params) are already documented in the schema with an example. The description adds nothing beyond 'arbitrary command', so the baseline 3 applies.

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

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

States a specific verb ('Send') and resource ('an arbitrary Chrome DevTools Protocol command to the current tab') plus the response shape ('raw response'). It is clearly distinct in kind from the high-level siblings, though it never names the escape-hatch relationship explicitly.

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

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

'Use with care' is a vague caution, not guidance. There is no statement of when to prefer this over browser_evaluate, browser_screenshot, browser_click, or other task-specific siblings, nor any prerequisites for calling it.

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, and it discloses little beyond the action itself. It does not say whether the click waits for navigation or network idle, how it behaves on hidden/disabled/covered elements, whether it auto-scrolls, or what errors to expect.

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

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

A single front-loaded sentence with no wasted words; the action and its identifier mechanism are stated 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 one-parameter tool with no output schema, the description is minimally adequate. However, with no annotations covering safety or side effects and no mention of navigation waiting or failure modes, an agent lacks the behavioral context needed to invoke it confidently.

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?

With a single parameter at 100% schema description coverage, the schema already documents the selector format. The description restates that the selector may be a CSS selector or an @eN handle, which is redundant with the schema and adds no format or precedence details.

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

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

The description states a specific verb (Click) and resource (an element on the page) and names the two accepted identifier forms (CSS selector or @eN snapshot handle). It is clear on its own, though it does not explicitly differentiate itself from siblings like browser_fill or browser_type that also act on elements.

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

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

There is no statement of when to use this tool versus alternatives such as browser_fill, browser_type, or browser_send_keys, all of which also target elements. Usage is only implied by the tool name and the mention of the @eN handle sourcing from browser_snapshot.

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 does not state that this is an irreversible mutation, what happens to the active tab or session afterwards, or what errors occur for an invalid/already-closed tab id.

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 clean sentence with the action and target front-loaded and zero filler. Nothing could be trimmed without losing meaning.

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 with a fully documented schema and no output schema, the essentials are covered. The gap is that, as an unannotated mutation, the description never says the close is irreversible or how failures surface.

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 schema itself documents tabId including its source (browser_list_tabs), so the description adds no parameter meaning beyond structured data. Baseline 3 applies.

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

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

The description states a specific verb (Close) and resource (the given browser tab), so purpose is unambiguous. It does not, however, differentiate itself from siblings like browser_switch_tab or browser_list_tabs, which share the same tab domain.

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

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

There is no guidance on when to use this tool versus alternatives, nor prerequisites such as whether the tab must be the active tab or whether the id must come from browser_list_tabs. Usage is only implied by the name.

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

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

With no annotations, the description carries the full burden. It discloses one useful trait (returns JSON-serializable values only), but says nothing about whether the code runs in the page's main world, whether it can mutate the DOM/state, async/timeout behavior, or sandboxing/security implications of executing arbitrary code.

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

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

A single, front-loaded sentence with no filler; the key constraint (JSON-serializable return) is placed at the end efficiently. It is tight and earns its length.

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

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

For a one-parameter tool with full schema coverage and no output schema, the description is adequate but thin: it hints at the return type but not its structure, and omits mutation/security context that matters for arbitrary code execution.

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% for the single 'code' parameter, so the schema already documents it fully. The description adds nothing beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 verb (Evaluate) and resource (arbitrary JavaScript in the current page context), so the agent knows exactly what it does. It is reasonably distinct from siblings like browser_click/browser_snapshot, though it doesn't explicitly position itself against the potentially overlapping browser_cdp.

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

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

There is no guidance on when to use this tool versus alternatives such as browser_cdp or the DOM-specific siblings, nor any mention of prerequisites. The agent must infer that this is the escape hatch for arbitrary script execution.

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

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

With no annotations, the description carries the full burden. It usefully discloses that existing content is replaced (idempotent set rather than append), which is real behavioral value. However, it omits whether input/change events fire, what happens if the selector matches nothing, or whether the element must be visible — significant gaps for an unannotated browser-automation tool.

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

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

A single front-loaded sentence with zero filler; the core action, target, and replacement behavior all appear before any trailing 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 two-parameter, no-annotation, no-output-schema tool, the description covers the action and the key replacement semantic. It is adequate but not complete: nothing explains failure modes, event triggering, or what the tool returns, which an agent calling a DOM mutation would benefit from.

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 both parameters, establishing a baseline of 3. The description repeats the selector-handle detail ('CSS selector or @eN handle') without adding syntax, format, or constraint information beyond the schema.

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

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

The description states a specific verb (Fill) and resource (input or textarea element), plus the value semantics. It is clear and unambiguous, but it never distinguishes itself from the close sibling browser_type, which an agent will reasonably confuse with it.

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

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

There is no explicit when-to-use guidance and no named alternative. The phrase 'replacing any existing content' hints at how it differs from a character-by-character type operation, but the description never says 'use browser_type instead when...' or otherwise routes the agent, leaving the fill-vs-type decision to inference.

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 behavioral burden, and it only implies that an active browser session is required ('from the browser'). It says nothing about which browsing context/tab cookies come from, what happens with no active session, or whether httpOnly/secure cookies are included. The read-only nature is inherently low-risk, which keeps this from dropping further.

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 12-word sentence that front-loads the action and resource and appends the filter qualifier. Nothing is wasted and nothing important is buried.

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 say more about the returned shape (names, values, domains, expiry) and the required browser-session precondition. For a simple two-param read tool it is adequate, but an agent still lacks the return-value picture.

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's 'optionally filtered by URL and/or name' merely restates the two documented properties. It adds no matching semantics beyond the schema, such as how URL matching interacts with cookie domain/path scoping.

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

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

States a specific verb and resource ('Read cookies from the browser') plus the two optional filter dimensions, which is enough for an agent to distinguish it from browser_set_cookie. It does not explicitly name or contrast against any sibling, so it stops 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?

There is no when-to-use or when-not-to-use guidance and no routing to the obvious alternative (browser_set_cookie for writing, browser_evaluate for JS-level access). The optional-filter mention describes parameters, not tool selection, so usage must be inferred 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 does disclose the shape of the result (id, URL, title, active state), which signals a non-destructive read, but it says nothing about scope beyond 'all' — e.g. whether tabs across multiple windows or contexts are included, or ordering. Adequate but thin for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler; the verb, scope, and returned fields are stated 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 no-parameter read tool with no output schema, the description compensates well by enumerating the returned fields. Minor gap: it does not state whether the listing spans all windows/contexts or in what order tabs are returned.

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

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

The tool takes zero parameters and the schema is empty with additionalProperties false, so there is nothing for the description to clarify. Baseline of 4 applies.

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

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

The description gives a specific verb (List) and resource (open browser tabs) and even names the returned fields: id, URL, title, active state. It is immediately distinguishable from browser_switch_tab and browser_close_tab by intent, though it never explicitly contrasts itself with sibling 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as browser_snapshot or browser_network_list. Usage is only implied by the tool name and the listed siblings.

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

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

No annotations are provided, so the description carries full behavioral burden. It does not say whether navigation waits for page load, what happens on failure, or that navigating away from the current page may lose unsaved state, which are meaningful traits for a navigation tool.

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

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

A single, front-loaded sentence with no filler; the primary action and target are stated immediately. It is efficient, though verging on under-specified rather than optimally structured.

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

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

For a simple two-parameter tool with a fully documented schema and no output schema, the description is minimally adequate. It omits behavioral details such as navigation timing or failure handling that would complete the picture.

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 both url and newTab are already documented in the schema, establishing a baseline of 3. The description's '(or a new tab)' merely restates the newTab parameter without adding format or default guidance beyond the schema.

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

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

States a specific verb (Navigate) and resource (browser tab / URL), making the action immediately clear. It does not explicitly distinguish itself from siblings like browser_switch_tab or browser_list_tabs, but the URL-navigation 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?

The description gives no when-to-use versus when-not guidance and names no alternatives. The parenthetical '(or a new tab)' hints that the newTab parameter exists but offers no condition for choosing tab behavior, leaving routing entirely to inference.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the return contents (headers, body, timing), which is genuinely useful for a read-only fetch, but says nothing about payload size, truncation, performance cost, or error behavior for a detail endpoint that may return large bodies.

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

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

A single front-loaded sentence with no filler. The verb and resource come first and the return contents follow, so nothing needs to be skimmed for or re-read.

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

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

No output schema exists, so the description must hint at return values, and it does so by naming headers, body, and timing. That is enough for an agent to know what it gets back, though it does not describe the shape or size of the payload.

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 schema itself explains where captureId and requestId come from, so the baseline is 3. The description adds only the notion that the requestId identifies "one captured request" and does not go beyond the schema.

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

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

The description gives a specific verb ("Get") and resource ("the full details of one captured request"), and even enumerates what those details are (headers, body, timing). This distinguishes it from browser_network_list, which returns the request list, but the description never names that sibling to make the contrast explicit.

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

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

Usage is only implied: the phrase "one captured request" signals it operates on an already-captured request, and the schema parameter descriptions chain it to browser_network_start and browser_network_list. There is no explicit statement of when to use this tool versus browser_network_list or when it is not appropriate.

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. 'List' correctly implies a read-only operation and the 'active (or stopped)' clause usefully signals that captures can be queried after stopping, but return format, pagination behavior, and truncation semantics are not disclosed.

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

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

A single front-loaded sentence with no filler. The key constraint (requires an existing/stopped capture) is stated in the fewest possible words.

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

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

There is no output schema, so the description could have explained what a listed request contains and how ordering/pagination works. For a simple three-parameter list tool this is adequate but leaves return-value context unaddressed.

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

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

Schema description coverage is 100%, with limit, filter, and captureId all documented in the schema itself, so the baseline is 3. The description adds no extra meaning about parameter behavior or defaults beyond what the schema already provides.

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

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

The description states a specific verb (list) and resource (requests captured by a network capture), which is clear and immediately understandable. It does not contrast itself with the sibling browser_network_detail, which also returns request data, so an agent must infer the difference between listing and detailing.

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

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

It implies when the tool is usable by noting the capture may be 'active (or stopped)', which tells the agent a capture must already exist. However, it never names browser_network_detail or browser_network_start as alternatives, nor states when to prefer this over them.

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

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

No annotations exist, so the description carries the full burden. It valuably discloses that the tool is stateful (a capture session started here feeds sibling tools) and returns a captureId, but says nothing about lifecycle limits, what happens if started twice, whether capture survives navigation, or the performance cost of includeBodies.

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

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

Two short sentences with zero padding; the action and the return value are both front-loaded and every clause 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?

Without an output schema, the description correctly names the returned captureId, which is the key consume-side detail. For a stateful capture-start tool with no annotations, it leaves open session lifetime, per-tab vs per-page scope, and failure modes.

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 `filter` and `includeBodies` are already documented in the schema; the description adds no parameter detail beyond that. Baseline of 3 is appropriate when the schema does all the heavy lifting.

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

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

States a specific verb and resource ("Start capturing network requests made by the page") and explicitly situates itself in the browser_network_* family. It is clearly distinguishable from browser_network_stop/list/detail, though it doesn't spell out the start-vs-stop relationship beyond the captureId hand-off.

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 mention that the returned captureId is "used with the other browser_network_* tools" implies this must run before list/detail/stop, giving usable context. However, there is no explicit when-to-use statement, no exclusion (e.g. one active capture per page), and no prerequisites such as an active tab.

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

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

With no annotations, the description carries the full behavioral burden and falls short. It says it returns captured requests but does not disclose whether the capture is deleted/terminated afterward, what happens if the captureId is invalid or already stopped, or whether the returned data is complete or partial.

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

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

A single well-formed sentence that front-loads the action (stop) and then the outcome (returned requests). Zero waste or filler.

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

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

There is no output schema and no annotations, so the description does most of the work; it correctly notes the return of captured requests. However, for a state-changing stop operation it omits error conditions and post-stop capture state, leaving it only minimally adequate.

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

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

Schema coverage is 100% and the single captureId parameter is fully documented in the schema, including that it comes from browser_network_start. The description adds no parameter detail beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb ("Stop") and resource ("running network capture") plus the return behavior ("return the captured requests"). It is clear on its own, but it does not differentiate itself from sibling capture tools like browser_network_list or browser_network_detail, so it stops short of a 5.

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

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

The description gives no explicit when-to-use guidance, no prerequisites (e.g. that a capture must be running), and no mention of alternatives. The agent must infer that this pairs with browser_network_start and is distinct from browser_network_list purely from the name.

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 the return format (base64) which is useful, but omits whether the operation mutates state (printing is generally non-destructive but this is not stated), whether it requires the page to be loaded, and any size or rate limits.

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

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

A single front-loaded sentence with no filler; 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?

The description covers the core action and return shape, which is enough for an agent to invoke the tool. However, with no annotations and no output schema, it leaves behavioral aspects like preconditions, non-destructiveness, and error conditions undocumented, making it only minimally complete for a 6-parameter 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 every one of the six optional parameters is already documented with type, default, and constraints. The description adds no parameter-level information beyond what the schema provides, so the baseline 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?

States a specific verb (Print) and resource (current page) and the output form (PDF, base64-encoded data). This clearly distinguishes it from browser_screenshot, which would produce an image rather than a PDF.

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?

Implied usage is clear from the purpose, but there is no explicit when-to-use guidance or contrast with the sibling browser_screenshot. For a tool whose main alternative (screenshot) is present in the sibling list, an explicit routing sentence is missing.

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 the output being base64-encoded, which is useful, but omits critical behavioral details: whether it requires the page to be loaded, whether it captures only visible content or the full page, any size or performance implications, and whether it modifies browser state. For a tool with zero annotation coverage, 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 concise sentence that front-loads the core action and return format with zero waste. It is appropriately sized for a simple tool.

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

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

With no annotations, no output schema, and a simple parameter set, the description is too sparse. It fails to disclose behavioral traits like page-load requirements, full-page vs. viewport capture, or error conditions, which are essential for correct invocation in a browser automation context.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters and their defaults fully. The description adds no parameter-specific semantics beyond what the schema provides. A baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb ('Take a screenshot') and resource ('current page or a specific element'), and it clearly names the return format ('base64-encoded image'). This distinguishes it from siblings like browser_snapshot (likely DOM snapshot) and browser_save_as_pdf (PDF output).

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 browser_snapshot or browser_save_as_pdf. It neither states when it is appropriate nor when it should be avoided. An agent must infer usage from the tool name alone.

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

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

With no annotations, the description carries the full burden. It adds one genuinely useful behavioral fact — keys go to the focused element — but is silent on what happens when nothing is focused, whether the call blocks or waits, and how modifier sequences are handled.

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

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

Two short sentences, with the core action stated first and the disambiguation second. Every clause earns its place and nothing is padded.

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

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

For a two-parameter input tool with no output schema, the description supplies purpose plus the key routing decision, which is most of what an agent needs. Only the preconditions around focus and blocking behavior remain unaddressed.

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

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

Schema description coverage is 100%, so the schema already documents both 'keys' (with key-name examples) and 'repeat'. The description adds no syntax, ordering, or default details beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Send individual key presses / keyboard shortcuts') and scopes it to 'the focused element'. It also explicitly separates itself from the nearest sibling by name, so an agent can pick it over browser_type without opening a schema.

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

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

Gives clear routing guidance: 'For typing literal text prefer browser_type.' This covers the primary confusion case but names only one alternative and gives no exclusions or prerequisites (e.g. how it relates to browser_fill or whether the page must be focused first).

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 disclosure burden. It conveys mutation ('create or update') and profile scope, but says nothing about whether an existing cookie is overwritten, persistence/session lifetime, required permissions, or domain/path inheritance behavior for a 9-parameter mutation tool.

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

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

A single 12-word sentence with the action front-loaded and no filler. It is appropriately sized for the tool, though very lean given the parameter surface.

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 9-parameter mutation tool with no annotations and no output schema, the description is minimal. It omits the url-vs-domain interactions, secure/httpOnly/sameSite implications, and whether the cookie is immediately active in the current session, leaving meaningful gaps an agent would have to guess at.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema (url derives domain/path, path default '/', expirationDate as Unix seconds, etc.). The description adds no parameter detail beyond that, matching the baseline 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 states a clear verb+resource ('Create or update a cookie') and scopes it to 'the current profile,' which is specific enough to distinguish it from read siblings like browser_get_cookies. It stops short of explicitly naming or contrasting with those siblings, so it doesn't reach the 5 tier.

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

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

There is no when-to-use or when-not-to-use guidance. It never mentions browser_get_cookies for reading, nor does it note any prerequisite such as needing a page/tab context before setting a cookie. Usage must be inferred entirely from the verb.

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

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

With no annotations, the description carries the full burden, and it does usefully disclose the returned artifact and the @eN handle syntax that other tools consume. It says nothing about the read-only nature of the call, page-loading prerequisites, or whether very large pages produce truncated output.

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

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

Two sentences, no filler, with the core purpose front-loaded and the handle-interop fact second. Every sentence 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?

For a zero-parameter tool with no output schema, the description covers the essential facts an agent needs: what is produced and how the @eN handles feed the other tools. Only minor gaps remain around preconditions and output size behavior.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is 100% and no enum or nested structure exists.

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

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

States a specific verb (capture) and a precise resource (accessibility-tree snapshot of the current page), which is distinct from sibling browser_screenshot and the network tools. It does not explicitly name an alternative, but 'AX snapshot' is specific enough that an agent will not confuse it with the other capture/interaction 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?

Usage is only implied: the note that returned @eN handles can be used as selectors by other tools suggests this is the precursor step before click/fill/type, but the description never states when to call it, whether a page must already be loaded, or when to prefer browser_screenshot.

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. It states that focus shifts, but says nothing about what happens if the tabId is stale or invalid, whether the containing window is raised, or whether the operation has any other side effects.

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

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

A single four-word sentence, front-loaded with the verb and containing no filler. Nothing is wasted and there is nothing further to trim.

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

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

For a one-parameter tool with full schema coverage and no output schema, the description covers the core action adequately. However, it omits failure behavior and any note about the resulting UI state, which are the only remaining gaps an agent would care about.

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 schema itself already documents tabId with its provenance ('from browser_list_tabs'), so the baseline of 3 applies. The description adds no constraints, ranges, or format notes beyond what the schema provides.

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 pairs a specific verb ('Activate (focus)') with a specific resource ('the given browser tab'), so an agent immediately knows this changes which tab is active rather than cloning or closing one. It does not explicitly contrast itself with siblings like browser_close_tab or browser_list_tabs, keeping it 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?

There is no when-to-use guidance, no mention of how to obtain a valid tabId, and no statement of alternatives such as browser_list_tabs for discovery or browser_close_tab for removal. The intended usage (after a tab is listed) is only implied by the tool name and is left entirely to inference.

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

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

With no annotations the description carries the full burden, and 'as if the user was typing on the keyboard' usefully signals per-character keyboard events rather than a direct value set (contrasting with fill semantics). It does not disclose what happens when no element is focused, whether existing text is cleared, or how errors surface.

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

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

A single front-loaded sentence with no filler; the focus constraint and the keyboard-emulation behavior both do work and are stated 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 one-parameter, no-annotation tool this is minimally adequate, but it omits failure modes (no focused element, non-editable target) and any note on return behavior or element state after typing, which an agent would need to sequence calls correctly.

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

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

One parameter with 100% schema description coverage, so the schema already defines 'text' fully. The description's only added semantic is that the text goes to the focused element, which is marginal given the schema already says 'text to type into the focused element'.

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

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

States a specific verb (type) and a precise target (the element that currently has focus), which implicitly separates it from sibling browser_fill, which presumably targets an element by selector. It never names that sibling explicitly, so an agent must infer the distinction, but the 'currently has focus' scoping makes the core purpose unambiguous.

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

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

The phrase 'into the element that currently has focus' carries an implied prerequisite (focus must already be set) but the description never says when to choose this over browser_fill or browser_send_keys. Usage is inferable from the focus constraint rather than stated.

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

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

With no annotations, the description carries the full behavioral burden, and for a page-mutating action it is thin. The 'as if picked via the file chooser' clause is genuinely useful because it tells the agent the native dialog is bypassed and the input's change events fire, but nothing is said about failure modes, permission/visibility requirements, or whether files must exist locally.

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though arguably under-specified rather than optimally tight for an action tool.

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

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

For a simple two-parameter tool with 100% schema coverage and no output schema, the description covers the core action adequately. However, given the absence of annotations on a mutating tool, it could say more about what the call changes and when it fails.

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 (files and selector) are already fully documented in the schema, including absolute paths and CSS selector/@eN handle formats. The description adds no parameter detail beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Attach local files to a file input element'), and the parenthetical clarifies the mechanism. It does not explicitly differentiate from siblings like browser_fill or browser_type, but the phrase 'file input element' implicitly narrows the scope.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer that this is for file-input uploads versus browser_fill/browser_type for text fields, with nothing in the text to confirm that routing decision.

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