Skip to main content
Glama
emadklenka

mare-browser-mcp

by emadklenka

browser_act

Batch multiple browser actions—click, fill, hover, drag, select, press keys—into one call. Target elements by accessibility refs from snapshots or CSS selectors for reliable UI automation.

Instructions

Perform one or more browser actions in sequence. Batch multiple steps into one call.

Two ways to target an element — use whichever is more stable: • ref — accessibility ref from browser_snapshot (preferred). LLM-friendly: no selector guessing, survives CSS class churn, resistant to obfuscated build output. Each ref is pinned to the exact element captured in the snapshot, so it never silently drifts to a different element when the page reflows. If that element is removed or re-rendered, the action fails loudly ("stale ref" / element not found) — re-snapshot rather than retrying. Call browser_snapshot first to get refs like "e9", "e42", then pass them to actions: { action: "click", ref: "e9" }. • selector — raw CSS selector. Use when you already know it, or for elements not in the a11y tree.

Example ref flow:

  1. browser_snapshot() → { snapshot, refs: [{ref: "e9", role: "button", name: "Sign in"}] }

  2. browser_act({ commands: [{ action: "click", ref: "e9" }] })

Available actions: • click — click an element (supports left/right/middle button). Use button:'right' for context menus • hover — hover over an element for tooltips, dropdown menus, hover states • drag — drag an element to a target selector (column reorder, kanban) OR by pixel offset (column resize, sliders). Use target for element-to-element, offsetX/offsetY for precise pixel drag • clicklink — click a link/button by visible text (text-based; does not use ref/selector) • fill — fill an input field (clears first) • select — select a dropdown option • keypress — press a key (Enter, Tab, Escape, etc.) — keyboard action, no ref/selector needed • waitfor — wait for an element to appear • scrollto — scroll an element into view • wait — pause for N milliseconds (no target) • clearconsole — clear captured console logs (no target)

click, hover, drag, fill, select, waitfor, scrollto all accept either 'ref' or 'selector'. If both are provided, 'ref' wins. Refs are invalidated on navigation — re-snapshot if the page has changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandsYesOrdered list of actions to execute
Behavior5/5

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

With no annotations, the description discloses critical behavioral traits: refs are pinned to snapshot elements, stale refs cause loud failures, refs invalidate on navigation, ref takes precedence over selector, fill clears first, and drag supports both element and pixel targets. This goes far beyond any structured metadata.

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?

The description is well-organized into sections: purpose, targeting methods, example flow, and action list. Every sentence earns its place, with clear bullet points and examples. It is long but appropriately so for the tool's complexity.

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?

Given the tool's 11 actions, no output schema, and no annotations, the description is remarkably complete. It covers targeting, all action nuances, failure modes, and the snapshot workflow, leaving no essential guidance for the agent.

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

Parameters5/5

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

The schema lists fields with minimal descriptions, but the tool description adds rich semantics for each action: click's button options, drag's target vs offset modes, clicklink's text-based targeting, waitfor's timeout, and the 'ref wins' rule. This is far beyond schema basics.

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?

The description clearly states it performs browser actions in sequence and batches multiple steps. It distinguishes itself from sibling tools by focusing on interactions like click, fill, drag, and keyboard presses, and explicitly references browser_snapshot for refs.

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 explicitly instructs to call browser_snapshot first to obtain refs and explains when to use selector vs ref. It also gives guidance on when to re-snapshot, though it does not explicitly contrast with alternative navigation/eval tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/emadklenka/mare_browser_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server