Skip to main content
Glama
TechyAditya

jev-browser-sidekick-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

run_action

Drive a browser through written steps on live pages for search, open, click, and read; Jev picks controls and can run four errands in parallel tabs, returning per-step status and handoff.

Instructions

Drive a browser through steps you write. Jev chooses on each page. Use for search, open, click, and read on live pages, and for several independent errands in one call through groups, one tab each, so two sites never need two calls. Returns a status per step, a handoff when one stops, and the tokens the API reported. Step shapes and status tables are in this server's instructions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoSingle step. Use tasks for a series.
debugNoRecord every browser call and Jev answer to the JSONL file named in tracePath.
tasksNoSteps in order on one tab, one action each. An entry may be a loop.
expectNoText that proves the run worked. Checked on the final page.
groupsNoIndependent errands, run at the same time, one tab each. Use whenever the work splits across two sites, accounts, or searches, instead of two calls.
noFailNoRun the rest of the series after a step does not complete. Endpoint faults stop it anyway.
valuesNoText the steps may type, such as an email. Never a password or a one-time code.
groupIdNoTab group to open a new tab in.
maxStepsNoPage actions the whole call may spend. Default 40.
startUrlNoAddress to open before the first step.
targetIdNoTab to work in. Omit to open one, returned in targetIds.
timeoutMsNoCeiling for the whole call. Default 90000. On expiry the call returns with the steps that finished plus a handoff naming the rest. Keep it under your client transport timeout: a dropped call still leaves the browser work done.
contextPathsNoFiles the steps may read.
returnSnapshotNoInclude the final page accessibility tree.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed19 schema fields changedv0.2.1
    • changedInput schema / properties / expect / description
      Previous value: -"Text that proves the run worked. Read off the final page."New value: +"Text that proves the run worked. Checked on the final page."
    • changedInput schema / properties / goal / description
      Previous value: -"A single step. Use tasks for a series."New value: +"Single step. Use tasks for a series."
    • changedInput schema / properties / groups / description
      Previous value: -"Independent errands, run at the same time, one tab each. Use this whenever the work splits across two sites, accounts, or searches instead of calling the tool twice."New value: +"Independent errands, run at the same time, one tab each. Use whenever the work splits across two sites, accounts, or searches, instead of two calls."
    • changedInput schema / properties / groups / items / properties / expect / description
      Previous value: -"Text that proves this series worked. Read off the final page."New value: +"Text that proves this series worked. Checked on the final page."
    • changedInput schema / properties / groups / items / properties / goal / description
      Previous value: -"A single step, when tasks is omitted."New value: +"Single step. Use when tasks is omitted."
    • changedInput schema / properties / groups / items / properties / id / description
      Previous value: -"Label for this series, echoed back in the result."New value: +"Label for this series. Echoed back in the result."
    • changedInput schema / properties / groups / items / properties / noFail / description
      Previous value: -"Run the rest of this series even after a step that did not complete."New value: +"Run the rest of this series after a step does not complete. Endpoint faults stop it anyway."
    • changedInput schema / properties / groups / items / properties / tasks / description
      Previous value: -"The steps, in order."New value: +"Steps in order."
    • addedInput schema / properties / groups / items / properties / tasks / items / $ref
      Added value: +"#/properties/tasks/items"
    • removedInput schema / properties / groups / items / properties / tasks / items / minLength
      Removed value: -1
    • removedInput schema / properties / groups / items / properties / tasks / items / type
      Removed value: -"string"
    • changedInput schema / properties / noFail / description
      Previous value: -"Run the rest of the series even after a step that did not complete."New value: +"Run the rest of the series after a step does not complete. Endpoint faults stop it anyway."
    • changedInput schema / properties / returnSnapshot / description
      Previous value: -"Include the final page's accessibility tree."New value: +"Include the final page accessibility tree."
    • changedInput schema / properties / targetId / description
      Previous value: -"Tab to work in. Omit to open one, which is returned in targetIds."New value: +"Tab to work in. Omit to open one, returned in targetIds."
    • changedInput schema / properties / tasks / description
      Previous value: -"Steps in order on one tab, one primitive action each."New value: +"Steps in order on one tab, one action each. An entry may be a loop."
    • addedInput schema / properties / tasks / items / anyOf
      Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "additionalProperties": false,
+    "description": "Repeat steps until the page shows `until`. One round per pass.",
+    "properties": {
+      "loop": {
+        "additionalProperties": false,
+        "properties": {
+          "maxRounds": {
+            "description": "Hard ceiling on rounds. Default 12.",
+            "maximum": 50,
+            "minimum": 1,
+            "type": "integer"
+          },
+          "tasks": {
+            "description": "Steps to run, in order, once per round.",
+            "items": {
+              "minLength": 1,
+              "type": "string"
+            },
+            "maxItems": 8,
+            "minItems": 1,
+            "type": "array"
+          },
+          "until": {
+            "description": "What the finished page shows. Jev reads the live page after every round and answers whether it holds, so name page evidence: \"the cart is empty\", not \"done\".",
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "tasks",
+          "until"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "loop"
+    ],
+    "type": "object"
+  }
+]
    • removedInput schema / properties / tasks / items / minLength
      Removed value: -1
    • removedInput schema / properties / tasks / items / type
      Removed value: -"string"
    • changedInput schema / properties / timeoutMs / description
      Previous value: -"Ceiling for the whole call. Default 90000. On expiry the call returns normally with the steps that finished and a handoff naming the rest. Keep it under your own client's transport timeout, because a dropped call still leaves the browser work done."New value: +"Ceiling for the whole call. Default 90000. On expiry the call returns with the steps that finished plus a handoff naming the rest. Keep it under your client transport timeout: a dropped call still leaves the browser work done."
  2. First observedv0.1.2

TDQS

A3.6/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 burden but only partially discharges it: it discloses Jev-driven per-page decisions, per-step status returns, a handoff on stoppage, and API token reporting. It omits safety/profile context such as authentication needs or side-effect/destructive footprint, which matters for a live-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.

Conciseness4/5

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

The core purpose is front-loaded in the first sentence and the four sentences each carry information (operations, parallel grouping, return shape, pointer to instructions). The trailing phrase 'so two sites never need two calls' is slightly redundant with the preceding clause.

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

Completeness4/5

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

For a 14-parameter nested tool with no output schema, the description supplies the missing return structure (per-step status, handoff, tokens) and defers step/status tables to server instructions. That covers the main gaps, though it could say more about failure and auth behavior.

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

Parameters3/5

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

Schema description coverage is 100%, so all 14 parameters (including groups, tasks, timeoutMs, noFail) are already documented in the schema; that sets the baseline at 3. The description adds the conceptual framing of groups as parallel one-tab-per-errand series, but no syntax or constraints beyond the schema.

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 opening line gives a concrete verb+resource ('Drive a browser through steps you write') and enumerates the operations it covers (search, open, click, read). It is clearly distinguishable in role, though it never names the sibling tool use_jev_raw to sharpen the boundary.

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

Usage Guidelines4/5

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

It states clear use contexts and even an alternative-to-two-calls rule ('several independent errands in one call through groups... so two sites never need two calls'). It stops short of explicit when-NOT-to-use guidance or a direct comparison with use_jev_raw.

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