Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_check

Destructive

Checks or unchecks a checkbox, radio button, or switch with a real CDP click only when the state differs, then reads back and verifies the change.

Instructions

Checks (checked=True) or unchecks (checked=False) a checkbox, a radio button or a role=checkbox/switch with a real CDP click, only if the state differs; the state is read back afterwards (verified, changed). E.g. locator={"role": "checkbox", "name": "I agree"} or {"label": "Newsletter"}.

Input Schema

NameRequiredDescriptionDefault
markNo
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).
checkedNo
locatorNo
selectorNo
timeout_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.31.6
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "browser_checkOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

No contradiction with annotations: destructiveHint=true is consistent with a real input click, and the skip-if-same-state behavior plus post-action state readback are disclosed. It even names the return fields (verified, changed), which annotations alone would not convey, though it omits permission/overlay or failure-mode details.

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

Conciseness4/5

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

The behavior and its guard condition are front-loaded in the first clause, and the examples are compact and useful. Slightly dense with parenthetical flags, but nothing is wasted.

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

Completeness3/5

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

With no output schema, the description helpfully names the returned fields, and the core check semantics are covered. Still, for a 6-parameter tool at 17% schema coverage, the unexplained selector/timeout/mark parameters and the absence of failure behavior leave gaps an agent could hit in practice.

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

Parameters3/5

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

Schema coverage is only 17%, so the description must carry weight: it defines checked's semantics with true/false mapping and gives concrete locator examples, which is genuinely additive. But mark, selector, and timeout_ms are left completely unexplained, and the selector-vs-locator relationship is not stated.

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

Purpose5/5

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

States a specific verb pair (checks/unchecks), the exact resource types (checkbox, radio button, role=checkbox/switch), and the mechanism (real CDP click). It is clearly separable from generic siblings like browser_click or browser_select_option.

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

Usage Guidelines3/5

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

'only if the state differs' implies the correct usage context, and the tool types named hint at when to prefer it over browser_click. However, no sibling is named and there is no explicit when-not guidance (e.g. what to do for custom widgets that are not role=checkbox).

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

Deploy Server

Other Tools