Skip to main content
Glama
Sign In
xav-ie

Browser Session MCP

by xav-ie
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

act

Destructive

Automates goal-directed actions on the active browser tab by choosing and performing clicks, typing, selections, scrolling, and waits until the goal is reached or progress stops.

Instructions

Act toward a goal on the session's active tab in one call: the server extracts the page's interactive elements and visible text, asks the Jev decision model for the next step, does it (click, type, select, scroll, back or wait), and repeats — until the goal reads achieved, nothing looks able to make progress, or the step budget runs out. Each step is one cheap Jev request (~150–500ms), not a driving-LLM round trip, so multi-step flows take seconds and fractions of a cent. Pass values (e.g. { query: "Oolong" }) for anything to type: Jev only sees the keys and picks which field each belongs to — the text goes straight to the page, so secrets never reach a model. Needs TYPESAFE_API_KEY; fails closed on any Jev problem, and every step lands on an element the extraction just offered. If a login wall or an error page appears, it stops early with a status saying so — pair needs_login with request_human_takeover or load_browser_state. A run with values keeps going at a login form, since the caller supplied what to type. Actions with no visible effect trigger a retry with Jev's next-best option before giving up as no_progress. Returns a per-step trace with confidences; status is completed, stuck, needs_login, blocked, no_progress or max_steps. Jev can be eager to call a goal met — verify with take_snapshot or take_screenshot afterwards. For a single action, click/type with a plain-language selector is cheaper.

Input Schema

NameRequiredDescriptionDefault
goalYesWhat to achieve on the active tab, e.g. "open the article about espresso". Re-decided after every step against the page as it is.
valuesNoText the loop may type, keyed by role, e.g. { query: "Oolong", password: "hunter2" }. Only the keys are sent to Jev; the values are typed via CDP.
maxStepsNoStep budget before stopping with status max_steps. Default 8, capped at 32.
sessionIdYesThe id returned by open_browser_session. Errors if no open session has it.

Output Schema

NameRequiredDescriptionDefault
urlYesThe page's URL at the final decision.
goalYesThe goal as given.
stepsYesWhat was done, in order.
titleYesThe page's title at the final decision.
statusYes"completed", "stuck" or "max_steps".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.14

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond annotations: discloses the per-step cost (~150-500ms, fractions of a cent), the TYPESAFE_API_KEY requirement, fail-closed behavior on Jev issues, retry on no visible effect, all possible `status` values, and that Jev may be eager to declare success so it should be verified with take_snapshot/take_screenshot. This is rich, actionable transparency.

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 definition is dense but front-loaded with the core loop behavior. Most sentences carry useful, distinct information, though the very long final paragraph could be structured more cleanly for scanning.

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

Completeness5/5

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

Despite the tool's complexity, the description covers the loop model, cost, auth requirement, failure modes, login handling, retry behavior, status values, and verification advice. With an output schema and annotations already present, this is complete for correct invocation.

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 100%, so the schema already documents goal, values, maxSteps, and sessionId thoroughly. The description adds some practical context—especially that `values` keys go to Jev and values go directly to the page—but does not materially supplement the parameter definitions beyond what is already in the schema.

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 and resource: it acts toward a goal on the active tab by extracting elements, asking Jev, executing a step, and repeating. It clearly distinguishes itself from cheaper single-action siblings like click/type.

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

Usage Guidelines5/5

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

Explicitly says to use click/type for a single action because it is cheaper, names request_human_takeover and load_browser_state for login-wall handling, and explains that a run with `values` continues at a login form. These are concrete when/when-not/alternatives.

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