jevpilot

browser_act

Run manual browser actions (click, type, select, scroll, wait) on current element refs in an existing session; returns a fresh snapshot, removing the need for a separate observe step.

Instructions

Perform manual browser operations against current element refs in an existing session. Returns a fresh snapshot, so a separate browser_observe is not needed after it. The orchestrator rechecks targets and applies the same domain and irreversible-action gates.

Input Schema

TableJSON Schema

Name	Required	Description
`ops`	Yes
`session`	Yes	Session ID returned by browser_run.
`allow_irreversible`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`title`	Yes
`trace`	Yes
`usage`	Yes
`reason`	Yes
`status`	Yes
`timing`	Yes
`details`	No
`session`	Yes
`question`	Yes
`snapshot`	Yes
`screenshot_path`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.0Oct 1, 2026

changedOutput schema / properties / trace / items / properties / outcome / enum

Previous value: -[
-  "changed",
-  "unchanged",
-  "stale",
-  "covered",
-  "disabled",
-  "invisible",
-  "not-editable",
-  "unstable",
-  "select-failed",
-  "dialog-opened",
-  "value-not-set",
-  "accepted",
-  "dismissed"
-]New value: +[
+  "changed",
+  "unchanged",
+  "stale",
+  "covered",
+  "disabled",
+  "invisible",
+  "not-editable",
+  "unstable",
+  "select-failed",
+  "dialog-opened",
+  "value-not-set",
+  "not-focusable",
+  "accepted",
+  "dismissed"
+]

First observedv0.1.0Sep 29, 2026

TDQS

B3.1/5.0

Behavior3/5

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 that the tool returns a fresh snapshot and that the orchestrator rechecks targets and applies domain and irreversible-action gates. However, it omits important details such as failure behavior, session state changes, and the specific implications of the irreversible-action gate.

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

Conciseness5/5

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

Three tightly written sentences with no waste. The purpose is front-loaded, followed by return behavior and gate information, all in a logical order.

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

Completeness2/5

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

For a complex tool with 14 possible actions in a nested ops array, no annotations, and low schema coverage, the description is insufficient. It does not explain how to construct ops entries or use allow_irreversible, leaving an agent without enough context to invoke the tool correctly despite the output schema being present.

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

Parameters1/5

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

Schema description coverage is only 33%, so the description must compensate, but it does not. It only vaguely references 'current element refs' (already covered by the schema) and provides no explanation of the ops array structure, individual action parameters, the session ID, or allow_irreversible.

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

Purpose4/5

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

The description clearly states the action (perform manual browser operations) and target (current element refs in an existing session). It distinguishes from browser_observe by noting that a fresh snapshot is returned so a separate observe is unnecessary. However, it does not differentiate from other siblings like browser_run or browser_navigate.

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

Usage Guidelines3/5

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

The description implies usage context (existing session, current refs) and notes that a separate browser_observe is not needed after this tool. It does not explicitly say when to use this tool versus alternatives like browser_observe before acting, nor does it state exclusions or prerequisites.

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

Deploy Server