Agent Web Interface is an MCP server that gives AI agents a compact, semantic interface to control a Chrome browser, using structured page snapshots and stable element IDs instead of raw DOM or accessibility trees. It returns incremental diffs for same-page interactions to minimize context overhead.
Session Management
list_pages – List all open tabs with IDs, URLs, and titles
close_page – Close a specific tab by page ID
Navigation
navigate – Go to a URL and receive a structured page snapshot
go_back / go_forward – Move through browser history
reload – Refresh the current page
Observation & Inspection
snapshot – Re-capture page state without performing an action
find – Search for elements by type (button, link, textbox, etc.), label, or page region
get_element – Get full details (position, size, state, attributes) for a specific element by ID
screenshot – Capture a screenshot of the full page, viewport, or a specific element
Interaction
click – Click an element by semantic ID or viewport coordinates
type – Type text into an input field or textarea
press – Press keyboard keys (Enter, Tab, Escape, Arrow keys, etc.) with optional modifiers
select – Choose an option from a dropdown by value or visible text
hover – Mouse over an element to trigger tooltips or hover menus
scroll / scroll_to – Scroll by pixel amount or until an element is visible
drag – Drag from one coordinate to another
wheel – Dispatch a mouse wheel event for zoom or horizontal scrolling
Forms
get_form – Analyze all forms on the page: fields, validation rules, and dependencies
get_field – Get detailed info about a single form field including valid formats and suggested values
Canvas
inspect_canvas – Analyze a canvas element, detect its rendering library, query its scene graph, and return an annotated screenshot with a coordinate grid overlay
Content Extraction
read_page – Extract clean, readable content using Mozilla Readability, stripping navigation and clutter
Network Monitoring
list_network_calls – List HTTP requests/responses with filters for method, status code, URL pattern, and resource type
search_network_calls – Search network calls by URL substring or regex, with optional headers and POST body details
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Browser MCP navigate to example.com and extract the page snapshot"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Drisp Browser is an MCP server that gives AI agents a compact, semantic interface to the browser.
Website · npm · vs. Playwright MCP
Instead of exposing the full DOM or accessibility tree, it returns structured page snapshots: visible regions, readable content, interactive elements, stable element IDs, form context, screenshots, canvas inspection, and network activity. Agents can then navigate and act on pages using semantic IDs instead of brittle selectors or massive context dumps.
It is built for coding agents, browser agents, QA agents, research agents, and automation workflows that need reliable web interaction without wasting tokens on low-signal browser internals.
Browser automation is easy for scripts and hard for LLM agents.
Traditional browser tools expose either raw DOM, full accessibility trees, screenshots, or low-level selectors. That works for deterministic code, but it is inefficient for language models. The model has to spend context and reasoning budget separating useful UI intent from implementation noise.
Drisp Browser changes the interface boundary.
The browser still runs through Puppeteer and Chrome DevTools Protocol, but the agent sees a smaller, more semantic representation of the page:
What regions exist on the page
What the user can read
What the user can interact with
Which elements are visible, enabled, selected, expanded, or required
Which stable eid should be used for the next action
What changed after the previous action
The goal is not to mirror the browser. The goal is to expose the page in the shape an agent can reason about.
Related MCP server: @playwright/mcp
Drisp Browser turns a browser page into an agent-readable snapshot.
A snapshot contains compact semantic information such as:
Page regions: header, navigation, main content, footer
Interactive elements: buttons, links, textboxes, checkboxes, radios, comboboxes
Readable content: headings, paragraphs, alerts, labels
Element state: visible, enabled, checked, selected, expanded, focused
Layout hints: bounding boxes and screen zones
Stable element IDs: eid values that can be reused by action tools
Agents act on these IDs:
{
"eid": "btn-sign-in"
}rather than reasoning from fragile CSS selectors or repeatedly scanning a large DOM tree.
This makes browser use more predictable for agents because observation and action are connected through a stable semantic contract.
Drisp Browser is:
An MCP server for browser automation
A semantic observation layer over Puppeteer and CDP
A compact page representation for LLM agents
A stable eid-based action interface
A toolset for navigation, interaction, forms, screenshots, canvas, readability, and network inspection
Drisp Browser is not:
A replacement for Puppeteer
A general-purpose browser
A visual testing framework
A scraping framework
A CAPTCHA or anti-bot bypass tool
Puppeteer and CDP remain the execution layer. Drisp Browser changes what the agent sees and how it decides what to do next.
At a high level:
The agent calls a browser tool through MCP.
Drisp Browser controls Chrome through Puppeteer and CDP.
The current page is reduced into semantic regions, readable content, and actionable elements.
The agent receives a compact snapshot instead of a raw browser dump.
The agent acts using stable element IDs.
Drisp Browser waits for the page to stabilize and returns the updated state.
This keeps browser lifecycle, page representation, and action execution separated.
AI Agent
↓ MCP
Drisp Browser
↓ semantic snapshots + stable eids
Puppeteer / Chrome DevTools Protocol
↓
Chrome / ChromiumA typical browser-agent loop looks like this:
The agent calls navigate with a URL.
Drisp Browser returns a compact page snapshot.
The agent calls find to locate a semantic element, such as a “Sign in” button or an email field.
The agent calls click, type, select, or press using the returned eid.
Drisp Browser waits for the page to stabilize and returns the updated snapshot.
The agent continues from the changed page state instead of re-reading the entire DOM.
This gives the model a browser interaction loop based on semantic state transitions rather than raw page internals.
The following example shows how an agent might use Drisp Browser inside a dashboard-style web app.
Task:
Find the failed payment from
client@example.com, open it, add an internal note saying “Customer contacted. Waiting for bank confirmation.”, and confirm the note was saved.
Tool call:
{
"tool": "navigate",
"input": {
"url": "https://dashboard.example.com/payments"
}
}Tool response:
<state step="1" title="Payments · Dashboard" url="https://dashboard.example.com/payments">
<meta view="1440x900" scroll="0,0" layer="main" />
<baseline reason="first" />
<region name="nav">
<link id="lnk-home" href="/dashboard">Home</link>
<link id="lnk-payments" selected="true" href="/payments">Payments</link>
<link id="lnk-customers" href="/customers">Customers</link>
<link id="lnk-reports" href="/reports">Reports</link>
</region>
<region name="main">
<h id="hd-payments">Payments</h>
<btn id="btn-create-payment">Create payment</btn>
<btn id="btn-export">Export</btn>
<inp id="inp-search-payments" type="search">Search payments</inp>
<btn id="btn-filter-status">Status</btn>
<btn id="btn-filter-date">Date</btn>
<elt id="payment-row-1" kind="row">₹12,500 succeeded nadeem@example.com Jun 6</elt>
<elt id="payment-row-2" kind="row">₹8,999 failed client@example.com Jun 6</elt>
<elt id="payment-row-3" kind="row">₹2,400 refunded test@example.com Jun 5</elt>
</region>
</state>The agent does not need to inspect a DOM table. It sees the relevant row directly as semantic state.
Tool call:
{
"tool": "click",
"input": {
"eid": "payment-row-2"
}
}Tool response:
<state step="2" title="Payment ₹8,999 · Dashboard" url="https://dashboard.example.com/payments/pay_8x91">
<meta view="1440x900" scroll="0,0" layer="main" />
<baseline reason="navigation" />
<region name="main">
<h id="hd-payment-detail">Payment ₹8,999</h>
<alert id="payment-status" kind="status">Failed</alert>
<elt id="payment-customer" kind="row">Customer client@example.com</elt>
<elt id="payment-method" kind="row">Payment method UPI</elt>
<elt id="payment-failure-reason" kind="row">Failure reason Bank declined transaction</elt>
<h id="hd-timeline">Timeline</h>
<elt id="timeline-row-1" kind="row">Payment created Jun 6, 10:42 AM</elt>
<elt id="timeline-row-2" kind="row">Payment failed Jun 6, 10:43 AM</elt>
<h id="hd-internal-notes">Internal notes</h>
<inp id="inp-internal-note" type="textarea">Add an internal note</inp>
<btn id="btn-save-note">Save note</btn>
</region>
<region name="aside">
<btn id="btn-refund" enabled="false">Refund</btn>
<btn id="btn-retry-payment">Retry payment</btn>
<btn id="btn-copy-payment-id">Copy payment ID</btn>
</region>
</state>Because this is a navigation, the response is a new baseline. The previous row IDs are no longer assumed valid.
Tool call:
{
"tool": "type",
"input": {
"eid": "inp-internal-note",
"text": "Customer contacted. Waiting for bank confirmation.",
"clear": true
}
}Tool response:
<state step="3" title="Payment ₹8,999 · Dashboard" url="https://dashboard.example.com/payments/pay_8x91">
<meta view="1440x900" scroll="0,0" layer="main" />
<diff type="mutation" />
<region name="main">
<inp id="inp-internal-note" focused="true" val="Customer contacted. Waiting for bank confirmation." type="textarea">Add an internal note</inp>
</region>
</state>The agent receives only the changed field, not the whole page again.
Tool call:
{
"tool": "click",
"input": {
"eid": "btn-save-note"
}
}Tool response:
<state step="4" title="Payment ₹8,999 · Dashboard" url="https://dashboard.example.com/payments/pay_8x91">
<meta view="1440x900" scroll="0,0" layer="main" />
<diff type="mutation" added="1">
<status id="rd-note-status" role="status">Note saved.</status>
</diff>
<observations>
<appeared when="action" eid="toast-note-saved" role="status" delay_ms="180" transient="true">Note saved.</appeared>
</observations>
<region name="main">
<elt id="note-row-1" kind="row">Customer contacted. Waiting for bank confirmation.</elt>
<btn id="btn-save-note" enabled="false">Save note</btn>
</region>
<region name="alert">
<alert id="toast-note-saved" kind="status">Note saved.</alert>
</region>
</state>The agent can now conclude that the note was saved because both signals are present:
A status appeared: Note saved.
A new note row appeared with the submitted text.
Done. I opened the failed ₹8,999 payment for client@example.com, added the internal note, and confirmed that the dashboard showed “Note saved.”This journey demonstrates the core interaction model:
navigate → baseline state
click row → new page baseline
type note → small diff
click save → diff + observation + confirmation stateThe agent does not receive raw DOM, brittle selectors, or a massive accessibility tree. It receives a compact state transition after every browser action.
Most browser interaction tools return a compact XML state response.
The response is designed for LLM agents, not for humans reading browser internals. It favors stable semantic IDs, short tags, page regions, and incremental diffs over full DOM dumps.
A typical response contains:
<state>: current page state, title, URL, and step number
<meta>: viewport, scroll position, and active interaction layer
<baseline> or <diff>: whether this is a full page state or an incremental update
<observations>: important transient UI changes such as dialogs, alerts, and toasts
<region>: grouped actionable elements by semantic page region
Short element tags such as <btn>, <inp>, <link>, <chk>, <sel>, and <alert>
Agents should use the id attributes, not CSS selectors, when performing follow-up actions.
This is the shape after navigate when the agent has no previous state.
<state step="1" title="Sign in | Acme" url="https://app.example.com/login">
<meta view="1280x720" scroll="0,0" layer="main" />
<baseline reason="first" />
<region name="header">
<link id="lnk-home" href="/">Acme</link>
<link id="lnk-docs" href="/docs">Docs</link>
</region>
<region name="main">
<h id="hd-sign-in">Sign in</h>
<inp id="inp-email" type="email">Email</inp>
<inp id="inp-password" type="password">Password</inp>
<chk id="chk-remember">Remember me</chk>
<btn id="btn-submit">Sign in</btn>
</region>
</state>For same-page interactions, Drisp Browser returns only the meaningful change.
<state step="3" title="Sign in | Acme" url="https://app.example.com/login">
<meta view="1280x720" scroll="0,0" layer="main" />
<diff type="mutation" />
<region name="main">
<inp id="inp-email" focused="true" val="nadeem@example.com" type="email">Email</inp>
</region>
</state>Readable mutations are rendered inline inside <diff>.
<state step="4" title="Sign in | Acme" url="https://app.example.com/login">
<meta view="1280x720" scroll="0,0" layer="main" />
<diff type="mutation">
<status id="rd-alert-login" role="alert">Invalid email or password.</status>
</diff>
<region name="main">
<inp id="inp-password" focused="true" type="password">Password</inp>
<btn id="btn-submit">Sign in</btn>
</region>
<region name="alert">
<alert id="rd-alert-login">Invalid email or password.</alert>
</region>
</state>Overlay layers such as modals, popovers, and drawers show the complete active overlay so the agent can reason about available actions.
<state step="6" title="Products | Acme" url="https://app.example.com/products">
<meta view="1280x720" scroll="0,0" layer="modal" />
<diff type="mutation" added="3" />
<observations>
<appeared when="action" eid="dlg-delete-product" role="dialog" delay_ms="120">
<heading eid="dlg-title">Delete product?</heading>
<text>This action cannot be undone.</text>
<button eid="btn-confirm-delete">Delete</button>
</appeared>
</observations>
<region name="dialog">
<h id="dlg-title">Delete product?</h>
<btn id="btn-cancel">Cancel</btn>
<btn id="btn-confirm-delete">Delete</btn>
</region>
</state>When a page has many repeated elements, large regions may be trimmed. The agent can call find with the region to retrieve more.
<state step="9" title="Search results | Acme" url="https://app.example.com/search?q=invoice">
<meta view="1280x720" scroll="0,420" layer="main" />
<baseline reason="navigation" />
<region name="main">
<link id="result-1" href="/invoice/1001">Invoice 1001</link>
<link id="result-2" href="/invoice/1002">Invoice 1002</link>
<link id="result-3" href="/invoice/1003">Invoice 1003</link>
<link id="result-4" href="/invoice/1004">Invoice 1004</link>
<link id="result-5" href="/invoice/1005">Invoice 1005</link>
<!-- trimmed 42 items. Use find with region=main to see all -->
<link id="result-48" href="/invoice/1048">Invoice 1048</link>
<link id="result-49" href="/invoice/1049">Invoice 1049</link>
<link id="result-50" href="/invoice/1050">Invoice 1050</link>
</region>
</state>These examples are illustrative, but shaped according to the actual response contract: <state>, <meta>, <baseline> or <diff>, optional <observations>, and region-grouped short element tags.
<state step="1" title="Issue #42 · acme/platform" url="https://github.com/acme/platform/issues/42">
<meta view="1440x900" scroll="0,0" layer="main" />
<baseline reason="first" />
<region name="header">
<link id="lnk-github-logo" href="/">GitHub</link>
<inp id="inp-global-search" type="search">Search or jump to...</inp>
<link id="lnk-pulls" href="/pulls">Pull requests</link>
<link id="lnk-issues" href="/issues">Issues</link>
<btn id="btn-create-new">Create new...</btn>
</region>
<region name="nav">
<link id="repo-code" href="/acme/platform">Code</link>
<link id="repo-issues" selected="true" href="/acme/platform/issues">Issues</link>
<link id="repo-pulls" href="/acme/platform/pulls">Pull requests</link>
<link id="repo-actions" href="/acme/platform/actions">Actions</link>
</region>
<region name="main">
<h id="issue-title">Checkout flow fails on Safari</h>
<btn id="btn-issue-state">Open</btn>
<link id="lnk-author" href="/nadeem">nadeem</link>
<btn id="btn-edit-title">Edit</btn>
<btn id="btn-copy-link">Copy link</btn>
<h id="comment-1-author">nadeem commented</h>
<elt id="comment-1-body">Safari users cannot complete checkout after selecting Apple Pay.</elt>
<btn id="btn-add-reaction">Add reaction</btn>
<btn id="btn-comment-menu">Comment options</btn>
<inp id="comment-box" type="textarea">Leave a comment</inp>
<btn id="btn-comment">Comment</btn>
<btn id="btn-close-issue">Close issue</btn>
</region>
<region name="aside">
<btn id="btn-assignees">Assignees</btn>
<btn id="btn-labels">Labels</btn>
<btn id="btn-projects">Projects</btn>
<btn id="btn-milestone">Milestone</btn>
</region>
</state><state step="1" title="Drisp · Linear" url="https://linear.app/drisp/team/CORE/active">
<meta view="1440x900" scroll="0,0" layer="main" />
<baseline reason="first" />
<region name="nav">
<link id="lnk-inbox" href="/inbox">Inbox</link>
<link id="lnk-my-issues" href="/my-issues">My issues</link>
<link id="lnk-views" href="/views">Views</link>
<link id="lnk-roadmaps" href="/roadmaps">Roadmaps</link>
<link id="lnk-projects" href="/projects">Projects</link>
</region>
<region name="main">
<h id="hd-active-issues">Active issues</h>
<btn id="btn-new-issue">New issue</btn>
<btn id="btn-display-options">Display options</btn>
<btn id="btn-filter">Filter</btn>
<h id="grp-in-progress">In Progress</h>
<elt id="issue-core-61" kind="row">CORE-61 Operations console</elt>
<elt id="issue-core-62" kind="row">CORE-62 GitHub Actions CI pipeline</elt>
<h id="grp-todo">Todo</h>
<elt id="issue-core-47" kind="row">CORE-47 KYB Step 2</elt>
<elt id="issue-core-63" kind="row">CORE-63 Fix Biome config drift</elt>
</region>
</state><state step="1" title="Payments · Dashboard" url="https://dashboard.example.com/payments">
<meta view="1440x900" scroll="0,0" layer="main" />
<baseline reason="first" />
<region name="nav">
<link id="lnk-home" href="/dashboard">Home</link>
<link id="lnk-payments" selected="true" href="/payments">Payments</link>
<link id="lnk-customers" href="/customers">Customers</link>
<link id="lnk-products" href="/products">Products</link>
<link id="lnk-reports" href="/reports">Reports</link>
</region>
<region name="main">
<h id="hd-payments">Payments</h>
<btn id="btn-create-payment">Create payment</btn>
<btn id="btn-export">Export</btn>
<inp id="inp-search-payments" type="search">Search payments</inp>
<btn id="btn-filter-status">Status</btn>
<btn id="btn-filter-date">Date</btn>
<elt id="payment-row-1" kind="row">₹12,500 succeeded nadeem@example.com Jun 6</elt>
<elt id="payment-row-2" kind="row">₹8,999 failed client@example.com Jun 6</elt>
<elt id="payment-row-3" kind="row">₹2,400 refunded test@example.com Jun 5</elt>
</region>
</state>Drisp Browser exposes MCP tools across the main phases of browser use.
list_pages
close_page
navigate
go_back
go_forward
reload
snapshot
find
get_element
screenshot
click
type
press
select
hover
scroll_to
scroll
drag
wheel
get_form
get_field
inspect_canvas
read_page
list_network_calls
search_network_calls
Run the interactive installer — it auto-detects which AI tools you have installed and registers the MCP server and agent skill in one step:
npx @drisp/browser-mcp installThen ask your AI to use the browser:
Open https://example.com and summarize the main actions available to a user.# Claude Code (also installs the agent skill)
npx @drisp/browser-mcp install --harness claude-code
# Cursor
npx @drisp/browser-mcp install --harness cursor
# VS Code
npx @drisp/browser-mcp install --harness vscode
# Claude Desktop (MCP only — no skill placement)
npx @drisp/browser-mcp install --harness claude-desktop
# Multiple at once
npx @drisp/browser-mcp install --harness cursor,vscode
# All detected harnesses
npx @drisp/browser-mcp install --harness allFlag | Description |
| Target harness(es): |
| Where to write the config (default: |
| Alias for |
| Alias for |
| Browser mode: |
| Launch Chrome in headless mode |
| Connect to an existing Chrome DevTools Protocol endpoint |
| Register an exact version instead of |
| Preview changes without writing files |
| Skip interactive prompts (non-TTY mode) |
npx @drisp/browser-mcp doctorPrints a per-harness status table showing whether the MCP server is registered and whether the agent skill is installed.
The drisp-browser skill can also be installed independently — without the MCP server — using npx skills:
npx skills add drisplabs/browser-mcpThis copies only the skill into your agent's skills/ directory. You still need to register the MCP server separately (the install command above does both). npx skills is intentionally kept as a supported alternative for skill-only workflows — see ADR-0003.
If you prefer to edit config files manually, add the server under the appropriate key:
{
"mcpServers": {
"drisp-browser": {
"command": "npx",
"args": ["@drisp/browser-mcp@latest"]
}
}
}VS Code uses servers instead of mcpServers and requires "type": "stdio":
{
"servers": {
"drisp-browser": {
"type": "stdio",
"command": "npx",
"args": ["@drisp/browser-mcp@latest"]
}
}
}To force connection to your existing Chrome session:
{
"mcpServers": {
"drisp-browser": {
"command": "npx",
"args": ["@drisp/browser-mcp@latest"],
"env": {
"DRISP_BROWSER_MODE": "user"
}
}
}
}Browser initialization happens automatically on the first browser tool call.
Set DRISP_BROWSER_MODE to control how Chrome is started.
Mode | Behavior | Profile |
unset | Auto: try | Depends on fallback |
| Connect to your running Chrome | Chrome's default profile |
| Launch Chrome with a dedicated persistent profile |
|
| Launch Chrome with a temporary clean profile | Deleted on close |
Examples:
# Auto mode
npx @drisp/browser-mcp
# Always connect to existing Chrome
DRISP_BROWSER_MODE=user npx @drisp/browser-mcp
# Always launch with persistent profile
DRISP_BROWSER_MODE=persistent npx @drisp/browser-mcp
# Headless isolated browser
DRISP_BROWSER_MODE=isolated DRISP_BROWSER_HEADLESS=true npx @drisp/browser-mcpDRISP_BROWSER_STEALTH)Launched browsers (persistent/isolated) carry Puppeteer's automation tells —
navigator.webdriver, the "controlled by automated test software" infobar, an empty
plugins list — which some sites use to false-positive a legitimate session as a bot.
DRISP_BROWSER_STEALTH (default true) applies fingerprint-only patches so a launched Chrome
looks like your everyday Chrome. It changes nothing about behavior (clicks and typing are
untouched) and is a no-op in user mode, where the connected Chrome already has a
genuine fingerprint.
# Disable stealth (raw Puppeteer fingerprint)
DRISP_BROWSER_STEALTH=false DRISP_BROWSER_MODE=isolated npx @drisp/browser-mcpThis is not a CAPTCHA or anti-bot bypass tool — it only avoids false-positive blocking of ordinary, authorized use.
To connect Drisp Browser to your regular Chrome profile:
Open Chrome.
Navigate to chrome://inspect/#remote-debugging.
Enable remote debugging and allow the connection.
Start Drisp Browser with DRISP_BROWSER_MODE=user.
DRISP_BROWSER_MODE=user npx @drisp/browser-mcpThis is useful when an agent needs access to an already authenticated browser session.
The server accepts transport-level arguments only. Browser configuration is controlled through environment variables.
Argument | Description | Default |
| Transport mode: |
|
| Port for HTTP transport |
|
Examples:
# stdio transport
npx @drisp/browser-mcp
# HTTP transport
npx @drisp/browser-mcp --transport http --port 8080Variable | Description | Default |
| Browser mode: | unset; auto fallback |
| Run browser headless: |
|
| Explicit CDP endpoint; overrides browser mode | unset |
| Set to |
|
| Transport mode override, for example | unset |
| Host for HTTP transport |
|
| Port for HTTP transport |
|
| Logging level |
|
| CDP host for CEF bridge connection |
|
| CDP port for CEF bridge connection |
|
| Set to |
|
| Path to Chrome executable | unset |
Early internal comparisons against Playwright MCP show lower token usage and faster completion on representative browser-agent tasks.
Current directional results:
Lower token usage on multi-step navigation tasks
Faster task completion in common browsing workflows
Same or better success rates in tested scenarios
These results are not yet a formal benchmark suite. They are task-dependent and should be treated as directional until the benchmark harness, task definitions, model versions, and raw traces are published.
Drisp Browser separates browser automation into three layers.
Responsible for:
Launching or connecting to Chrome
Managing browser contexts
Managing pages and tabs
Preserving or isolating browser state depending on mode
Responsible for:
Extracting DOM structure
Reading accessibility metadata
Resolving labels and roles
Detecting page regions
Tracking element state
Producing compact agent-readable output
Responsible for:
Mapping stable eid values to browser nodes
Executing clicks, typing, scrolling, keypresses, and selection
Waiting for page stabilization
Returning the next page state
This separation lets the browser implementation evolve while keeping the agent-visible interface stable.
Clone the repository:
git clone https://github.com/drisplabs/browser-mcp
cd browser-mcp
npm installBuild:
npm run buildRun locally:
npm startRun in watch mode:
npm run devRun checks:
npm run checkRun tests:
npm testInspect with the MCP inspector:
npm run mcp:inspectNode.js 20 or newer
Chrome or Chromium
An MCP-compatible client such as Claude Code, Claude Desktop, Cursor, or VS Code
Drisp Browser is under active development.
The public tool surface is intended to stay simple, but internal APIs and snapshot formats may evolve as real-world agent usage informs the design.
Feedback from practitioners building browser agents, coding agents, QA agents, and automation systems is especially welcome.
MIT
Click an element (by eid) or at viewport coordinates. Prefer eid for reliability; use coordinates only for canvas or non-semantic targets. Returns a fresh page snapshot with the changes the click produced.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X coordinate for the click. When used with eid, relative to the element top-left corner. When used without eid, absolute viewport coordinate. | |
| y | No | Y coordinate for the click. When used with eid, relative to the element top-left corner. When used without eid, absolute viewport coordinate. | |
| eid | No | Element ID from find results or the page snapshot. Every interactive element has a unique eid. | |
| page_id | No | The ID of the page containing the element. | |
| modifiers | No | Modifier keys to hold during the click (e.g., Shift for multi-select, Control for ctrl-click). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that the tool returns a fresh page snapshot with changes. It also notes reliability differences between `eid` and coordinates. However, it does not detail potential side effects like navigation or modals, but the core behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each purposeful. The first states the action, the second gives guidance and return info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a click tool with 5 parameters and no output schema, the description covers the core action, return value, and usage guidance. It omits details about modifiers and page_id, but those are covered by the schema. The description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by advising preference for `eid` and explaining the coordinate usage context. This enhances the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks an element by `eid` or at viewport coordinates, distinguishing it from sibling tools like hover, drag, and type. It specifies the verb and resource, with guidance on when to use each method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to prefer `eid` for reliability and use coordinates only for canvas or non-semantic targets, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a browser tab. Use list_pages first to get the page_id.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys the basic destructive action but does not disclose details like whether unsaved state is lost or if confirmation is needed. Without annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear sentences, no fluff, and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required param, no output schema), the description adequately covers the action and prerequisite. Could mention expected behavior or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not directly explain the page_id parameter beyond implying it comes from list_pages. With 0% schema description coverage, it adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'close' and resource 'browser tab', making the tool's purpose distinct from sibling tools like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite guidance: 'Use list_pages first to get the page_id.' This helps the agent know how to obtain the required input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag from a source point to a target point (optionally relative to an element via eid). Use for reordering lists, moving sliders/handles, or manipulating canvas objects. Returns a fresh page snapshot with any resulting changes.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | No | Optional element ID. When provided, coordinates are relative to the element top-left corner. | |
| page_id | No | The ID of the page. | |
| source_x | Yes | X coordinate of the drag start point. | |
| source_y | Yes | Y coordinate of the drag start point. | |
| target_x | Yes | X coordinate of the drag end point. | |
| target_y | Yes | Y coordinate of the drag end point. | |
| modifiers | No | Modifier keys to hold during the drag (e.g., Shift for constrained rotation, Control for copy-drag). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return value ('fresh page snapshot') and optional parameters (eid, modifiers), but does not disclose potential side effects, waiting behavior, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover purpose, key parameters, use cases, and return value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers main behavior, optional features, and return value. Lacks details on edge cases or behavior modifiers, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about coordinates being drag start/end points and eid making coordinates relative, but does not significantly enhance understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Drag from a source point to a target point' and provides specific use cases (reordering lists, moving sliders/handles, manipulating canvas objects), distinguishing it from sibling tools like click or hover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists appropriate use cases explicitly, but does not mention when to avoid using this tool or suggest alternatives, which could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate elements or read page text without acting on them. Two modes: filter by kind/label/region to find interactive elements (returns each match with a stable eid for use with click, type, select, etc.), or set include_readable to also get text content tagged with semantic rd-* ids. Best for pinpointing a target before an action or pulling specific content; use snapshot for the whole page. Returns matching elements/content as XML.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by element type: 'button' for clickable buttons, 'link' for hyperlinks, 'textbox' for input fields, 'checkbox'/'radio' for toggles, 'combobox' for dropdowns, 'heading' for section titles, 'image' for images, 'canvas' for canvas elements, 'alert' for notifications/toasts/alerts/status messages. | |
| label | No | Search text to match against element labels - uses case-insensitive substring matching. Example: label "Sign" matches "Sign In", "Sign Up", "Signature". | |
| limit | No | Number of results to return. | |
| region | No | Restrict search to a specific area. | |
| page_id | No | The ID of the page to search within. | |
| include_readable | No | When true (default), text content (paragraphs, headings) gets semantic IDs (rd-*) for reference. Set to true when you need to read page content. Use the `kind` parameter to filter to specific element types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is read-only ('without acting on them'), returns stable eid for interactive elements, semantic rd-* ids for text, and results as XML. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence adds essential information. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return format (XML with eid or rd-*). With 6 parameters, schema descriptions cover them fully. The tool's two modes and relationship to snapshot are well-explained, making the description complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does mention parameters (kind, label, region, include_readable) but does not add significant new meaning beyond the schema's own descriptions. The value is in framing the overall modes, not enriching individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool locates elements or reads page text without acting on them. It describes two modes: filtering by kind/label/region for interactive elements, and using include_readable for text content. It distinguishes from snapshot, making the purpose precise and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool ('pinpointing a target before an action or pulling specific content') and provides a clear alternative ('use snapshot for the whole page'). This gives strong contextual guidance for choosing between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete details for one element: exact position, size, state, and attributes. Requires an eid obtained from find or snapshot. Use when you need precise geometry or full attribute/state data for a single element. Returns the element details as XML.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID to inspect, obtained from find results or the page snapshot. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns element details as XML, implying a read-only operation. However, it does not disclose potential error conditions, performance, or other side effects, which is acceptable for a simple inspection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three clear statements: purpose, prerequisite, use case, return format) and front-loaded with the core action. No redundancy, but could be slightly more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool without output schema, the description adequately covers prerequisites, purpose, and return format (XML). It does not detail the XML structure, but that is acceptable given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context that eid comes from find/snapshot, but page_id's behavior is already described in schema. Minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete details (position, size, state, attributes) for a single element, and distinguishes it from sibling tools like find or click by noting it requires an eid from find/snapshot and is for inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need precise geometry or full attribute/state data for a single element' and mentions the prerequisite (eid from find/snapshot). Does not explicitly list when not to use, but context from sibling tools implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info about one form field (by eid): purpose, valid input formats, dependencies, and suggested values. Use to resolve a field get_form flagged as ambiguous or invalid before typing into it. Returns the field context as XML including constraints, options, and dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID of the form field to inspect, from get_form or the page snapshot. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must stand alone. It mentions return format (XML with constraints/options/dependencies) but does not disclose side effects, auth needs, or rate limits. It implies a read operation but lacks explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence states purpose and scope, second provides usage guidance and output format. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers return format (XML with constraints/options/dependencies) which compensates for lack of output schema. It mentions dependencies and suggested values. However, it does not explain complex behavior like what 'dependencies' entail or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining eid comes from get_form or page snapshot, and page_id is optional. This contextualizes parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed info about one form field by eid, including purpose, formats, dependencies, and suggested values. It distinguishes from siblings like get_form and get_element by focusing on single field details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use when get_form flags a field as ambiguous or invalid before typing into it. This provides clear use context, though it omits when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze all forms on the page: fields, required inputs, validation rules, and field dependencies. Call this first on any multi-field or multi-step form to plan the fill order, instead of scrolling and screenshotting. Returns each form as XML with per-field eids, state, constraints, and the suggested next field to fill.
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | No | Restrict the result to a single form by its id (from a prior get_form call). If omitted, all forms on the page are returned. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. | |
| include_values | No | When true, include each field's current value in the response. Defaults to false; sensitive values (passwords, tokens) remain masked even when enabled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: returns XML with per-field eids, state, constraints, and suggested next field. It also explains the effect of the 'include_values' parameter and that sensitive values are masked. However, it does not mention error handling or performance characteristics, so a perfect score is not warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence states the core function, and the second provides usage guidance and output summary. Information is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return format (XML with fields). All three parameters are well-documented in both schema and description. Given the tool's complexity and the sibling context, the description provides complete guidance for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value beyond the schema. For 'form_id' it clarifies 'from a prior get_form call'; for 'page_id' it explains default behavior; for 'include_values' it notes default and sensitive value masking. This extra context helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze all forms on the page: fields, required inputs, validation rules, and field dependencies.' It uses a specific verb ('Analyze') and resource ('forms on the page'), and distinguishes itself from sibling tools like 'get_element' or 'get_field' by being form-specific and returning structural information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this first on any multi-field or multi-step form to plan the fill order, instead of scrolling and screenshotting.' This tells the agent when to use the tool and offers an alternative approach, making it easy to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Go back one page in browser history. Returns a fresh page snapshot of the resulting page with its interactive elements.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses return value (fresh snapshot with interactive elements) but omits edge cases like history boundary or performance impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear action and result. No waste. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 optional param, no output schema), the description fully covers what the tool does and returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is complete. The tool description adds no extra meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('Go back') and resource ('browser history'), and distinguishes from sibling 'go_forward' by specifying direction. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for navigating backward, but does not explicitly state when to avoid it (e.g., at history start) or compare with alternatives like 'navigate'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Go forward one page in browser history. Returns a fresh page snapshot of the resulting page with its interactive elements.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it returns a fresh snapshot but discloses no other behavioral details such as whether the tool waits for page load, what happens if no forward history, or any side effects like losing current state. Insufficient for an AI agent to predict behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with action and return value. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description explains the return value adequately. However, it omits edge-case behavior (e.g., when no forward history) and does not mention if the snapshot is synchronous or not. Still mostly complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'page_id' with description). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'go forward' and resource 'one page in browser history', and explicitly mentions the return value: a fresh page snapshot with interactive elements. This distinguishes it from the sibling tool 'go_back'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is for forward navigation in browser history, but no explicit guidance on when to use versus alternatives (e.g., 'navigate') or when not to use (e.g., if no forward history). The sibling list includes 'go_back' which provides context but no direct instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move mouse over an element without clicking. Triggers hover menus and tooltips.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID from find results or the page snapshot. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context that it triggers hover menus and tooltips, which is useful. However, with no annotations, more detail would be helpful, e.g., whether it returns anything or if it waits for effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that directly convey the purpose and a key behavioral effect. No extraneous words; front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple and description covers basic purpose and effect. However, without annotations or output schema, it would benefit from mentioning return value or prerequisites (e.g., element visibility).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds no additional parameter semantics beyond what the schema already provides. The parameter names and descriptions in the schema are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'move mouse' and resource 'element', and distinguishes from sibling 'click' by specifying 'without clicking'. The description is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage by mentioning 'without clicking', but no explicit guidance on when to use vs alternatives like 'click' or 'drag'. No conditions or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a canvas element: auto-detect the rendering library, query its scene graph, and return an annotated screenshot with coordinate grid overlay.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID of the canvas element from find results. | |
| format | No | Image format: 'png' (lossless, default) or 'jpeg' (lossy with quality control). | png |
| page_id | No | Page ID. If omitted, operates on the most recently used page. | |
| quality | No | JPEG quality 0-100. Only applies when format is jpeg. | |
| grid_spacing | No | Grid line spacing in pixels (default: 50). Smaller values give finer coordinate resolution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the tool's actions (detect library, query scene graph, return annotated screenshot) but does not explicitly declare it as read-only or mention any side effects. Since no annotations exist, the description carries the full burden; while it is informative, it could be enhanced with a read-only statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that is front-loaded with the core purpose. No redundant words or unnecessary detail. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core purpose well but lacks details about the return format (is it an image, JSON, or both?). With no output schema, the description should clarify what 'annotated screenshot' means and any potential limitations (e.g., dependency on library detection).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds overall context (e.g., grid spacing) but does not provide additional semantics beyond what the schema offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Analyze) and resource (canvas element), detailing actions: auto-detect rendering library, query scene graph, return annotated screenshot with grid overlay. This clearly distinguishes it from sibling tools like 'screenshot' or 'get_element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for canvas debugging but lacks explicit when-to-use or when-not-to-use compared to alternatives. No guidance on when to prefer this over 'screenshot' or 'snapshot' for canvas elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List HTTP requests and responses made by the page. Filter by resource type, method, status code, or URL pattern; supports pagination. Use after navigate or an action to inspect API traffic, confirm a request fired, or find failing calls (e.g. status_min=400). Returns request/response summaries as XML.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (default: 25, max: 100). | |
| method | No | Filter by HTTP method: GET, POST, PUT, DELETE, PATCH, etc. | |
| offset | No | Pagination offset (default: 0). | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. | |
| status_max | No | Maximum HTTP status code (inclusive). Use with status_min for ranges like 200-299. | |
| status_min | No | Minimum HTTP status code (inclusive). Use 400 to see only errors. | |
| failed_only | No | When true, only show requests that failed due to network errors. | |
| url_pattern | No | Filter URLs containing this substring. | |
| resource_type | No | Filter by resource type: xhr, fetch, document, script, stylesheet, image, font, media, other. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes the return format is XML summaries and implies read-only by listing calls, but does not explicitly state read-only behavior, side effects, or performance implications. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, filter options, usage context, and return format. Every word is informative with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description gives usage context and return format, it lacks details about the response structure (e.g., fields in each XML summary) and pagination specifics. Given the complexity (9 params, no output schema, no annotations), more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by providing a usage example (status_min=400) and summarizing filter types, which aids understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists HTTP requests and responses and names specific filter criteria (resource type, method, status code, URL pattern). It does not explicitly differentiate from the sibling 'search_network_calls' but the verb 'list' implies a non-search operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'after navigate or an action to inspect API traffic, confirm a request fired, or find failing calls' with a concrete example. Does not state when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open browser pages with their page_id, URL, and title.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It lists the returned fields but does not mention side effects, ordering, or whether it provides a snapshot or live data. Adequate but minimal for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, directly states purpose and output. Perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, but the description explicitly lists the returned fields (page_id, URL, title). For a simple list tool with no parameters, this is sufficient. Lacks mention of whether the list is ordered or filtered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. The description does not add parameter info (none needed). Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and the resource 'all open browser pages', and specifies the output fields ('page_id, URL, and title'). This is specific and distinguishes from sibling tools like 'read_page' or 'navigate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings like 'read_page' or 'navigate'. The description implies it is for getting an overview of open pages, but does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the server is responsive
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states a read-like check, but does not disclose potential timeouts, error handling, or return values. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It is maximally concise for the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is nearly complete. It could mention the return format, but the simplicity makes it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, which is acceptable since none are needed. The baseline for zero parameters is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if the server is responsive' clearly states the action (checking) and the resource (server responsivity). It is distinct from sibling tools like click, navigate, etc., which involve UI interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use ping versus alternatives. It does not mention when-not or suggest other tools for different purposes. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a single keyboard key with optional modifiers, dispatched to the focused element. Use for submitting with Enter, dismissing with Escape, or keyboard navigation (Tab, arrows); use type to enter text. Returns a fresh page snapshot with any resulting changes.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to press on the focused element, e.g. Enter to submit, Escape to dismiss, Tab to move focus, or the arrow keys to navigate. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. | |
| modifiers | No | Modifier keys to hold while the key is pressed (e.g. Control, Shift). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: dispatches to focused element and returns page snapshot. Without annotations, the description carries full burden; it lacks explicit mention of side effects (e.g., deletion with Backspace) but the action is inherently clear. A higher score would require more detail on potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action. No redundant information, every word earns its place. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return value (fresh page snapshot). With three parameters and no complex nested objects, all necessary context is present for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, but the description adds context by giving concrete examples of key usage (Enter, Escape) and noting dispatch to focused element. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Press' and resource 'single keyboard key', with explicit differentiation from sibling tool 'type' (for text entry). The tool's functionality is unambiguously described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (submitting with Enter, dismissing with Escape, keyboard navigation) and when-not-to-use (use type to enter text). Also mentions the return of a fresh page snapshot, aiding agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the main readable content from the page, removing navigation, ads, and clutter. Uses Mozilla Readability (Firefox Reader View engine). Best for articles, blog posts, documentation, and content-heavy pages.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the use of Mozilla Readability, indicating a well-known algorithm for content extraction. It does not discuss failure modes or page requirements, but for a read-only tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and providing additional context in the second sentence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description is fairly complete. It explains what the tool does and when to use it. It could mention the output format (plain text or HTML), but it's not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds context that omitting page_id operates on the most recently used page, which adds value beyond the schema's 'Page ID' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts main readable content and removes clutter. It specifies the engine (Mozilla Readability) and gives typical use cases, distinguishing it from sibling tools which are primarily actions like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Best for articles, blog posts, documentation, and content-heavy pages,' which provides guidance on when to use. However, it does not explicitly state when not to use or list alternatives, though the context makes it fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the current page. Use after a change that only takes effect on reload, or to recover from a stale page. Returns a fresh page snapshot with its interactive elements.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the main outcome: 'Returns a fresh page snapshot with its interactive elements.' However, it does not mention potential side effects like losing unsaved state or network delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no wasted words, and front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one optional parameter, and no output schema, the description covers the essential behavior and usage context adequately. It lacks only minor details about side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'page_id' parameter described in the input schema. The description does not add any information about the parameter beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Refresh the current page' and specifies its purpose: 'after a change that only takes effect on reload, or to recover from a stale page.' It distinguishes from siblings like 'navigate' and 'read_page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'after a change that only takes effect on reload, or to recover from a stale page.' It does not mention alternatives, but the context is sufficiently clear for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the current page or a specific element. Use for visual verification or when layout/rendering matters; prefer snapshot or find for reading structure and text. Returns the image inline, or a file path when the image is large.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | No | Element ID to screenshot. Requires a prior snapshot. Cannot be combined with fullPage. | |
| format | No | Image format: 'png' (lossless, default) or 'jpeg' (lossy with quality control). | png |
| page_id | No | The ID of the page to screenshot. | |
| quality | No | JPEG quality 0-100. Only applies when format is jpeg. | |
| fullPage | No | Capture full page height beyond the viewport. Cannot be combined with eid. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool 'Returns the image inline, or a file path when the image is large,' which is key behavioral info not in the schema. It does not mention if it modifies state, but screenshots are inherently read-only, so this is acceptable. Missing details like rate limits or auth needs, but these are not critical for a screenshot tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and usage guidance. Every sentence adds value: first defines action and resource, second gives usage context and return behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers the core purpose, when to use, and return format. It could mention that the tool does not modify the page (though obvious) or clarify the file size threshold for inline vs. file path, but overall it is sufficiently complete for a screenshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters adequately. The description does not add new meaning beyond the schema for parameters, except implying the use of 'current page' (via page_id) or 'specific element' (via eid), which is already clear from schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Capture a screenshot of the current page or a specific element,' using a specific verb and resource. It distinguishes from sibling tools by advising to 'prefer snapshot or find for reading structure and text,' showing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('Use for visual verification or when layout/rendering matters') and when not to ('prefer snapshot or find for reading structure and text'), providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the viewport up or down by a pixel amount. Use to reveal more of a long page or trigger lazy-loaded content; use scroll_to when you know the target element. Returns a fresh page snapshot reflecting the new scroll position.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Distance to scroll in pixels (default: 500). | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. | |
| direction | Yes | Direction to scroll the viewport: 'up' or 'down'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility. It discloses the return value ('Returns a fresh page snapshot reflecting the new scroll position'), which is valuable. However, it does not explicitly mention whether the operation is idempotent or whether there are any side effects beyond the scroll and snapshot. Still, for a simple scroll action, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences that front-load the essential purpose, usage guidance, and return value. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters (one required), no output schema, and a simple scroll functionality, the description provides all necessary information: what it does, when to use it, how it differs from a sibling, and what it returns. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the schema itself documents each parameter. The description adds context like 'pixel amount' and 'trigger lazy-loaded content' but does not significantly enhance parameter understanding beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('scroll'), the resource ('viewport'), and the manner ('up or down by a pixel amount'). It also distinguishes the tool from the sibling 'scroll_to' by stating when to use which, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to reveal more of a long page or trigger lazy-loaded content') and when not to ('use scroll_to when you know the target element'), providing clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll until a specific element (by eid) is visible in the viewport. Use before clicking or reading an element that find/snapshot reports as off-screen. Returns a fresh page snapshot reflecting the new scroll position.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID of the off-screen element from find results or the page snapshot. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It describes scrolling until element is visible and returning a snapshot, but lacks details on side effects (scroll events), prerequisites (element existence), and whether scrolling is incremental. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. Crucial information is front-loaded: action, target, usage context, and return value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scroll-to-element tool with two well-described parameters and a clear return value (snapshot), the description covers all necessary aspects: what, when, how, and result. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by clarifying that eid comes from find results or snapshot, and mentions page_id's default behavior (operates on most recent page). This enhances understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (scroll to make element visible), the target (element by eid), and distinguishes it from the sibling 'scroll' tool by focusing on a specific element. It also mentions the return of a fresh snapshot, adding purpose completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using before clicking or reading an off-screen element reported by find/snapshot, providing clear context. However, it does not state when not to use or directly compare to alternatives like 'scroll', leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search network calls by URL pattern (substring or regex). Use when you know part of the endpoint URL and want just those calls, optionally with headers and request body; use list_network_calls to browse all traffic. Returns matching requests as XML with optional headers and body details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (default: 25, max: 100). | |
| method | No | Filter by HTTP method. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. | |
| url_regex | No | When true, url_pattern is treated as a regular expression. | |
| status_max | No | Maximum HTTP status code (inclusive). | |
| status_min | No | Minimum HTTP status code (inclusive). | |
| url_pattern | Yes | URL pattern to search for. Substring match by default; set url_regex=true for regex. | |
| include_body | No | When true, include POST body in results. | |
| resource_type | No | Filter by resource type. | |
| include_headers | No | When true, include request and response headers in results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states the return format (XML with optional headers and body details). However, it does not mention whether the tool is read-only or if any state changes occur. For a search tool, this is minor; still, it could be more explicit about non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. The first sentence states the action and matching method; the second gives usage guidance and return format. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no output schema, the description covers the main purpose and differentiation. However, it does not summarize the extensive filtering capabilities (e.g., status codes, method, resource type) which could help an agent understand the full scope. Still, the schema provides those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only mentioning that headers and body can be included optionally. It does not clarify parameter usage or relationships further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches network calls by URL pattern using substring or regex. It distinguishes from sibling list_network_calls by specifying that this tool filters by URL pattern, while the sibling is for browsing all traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when you know part of the endpoint URL and want just those calls. It also provides alternative: use list_network_calls to browse all traffic. This gives clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose an option from a dropdown menu by value or visible text.
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID of the dropdown from find results or the page snapshot. | |
| value | Yes | The option to select - can be either the value attribute or the visible text of the option. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether selection triggers events, validation of option existence, or any side effects. The description is too minimal for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool with no output schema, the description covers the core action adequately. It lacks mention of prerequisites or error conditions, but given low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description restates the dual nature of the 'value' parameter (value attribute or visible text) which is already in the schema, adding no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Choose an option') and the target resource ('dropdown menu') with the specific method ('by value or visible text'). It effectively distinguishes from sibling tools like 'click' or 'type' which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys usage context (dropdown selection) but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-capture the page state without performing any action. Use when the page may have changed on its own (timers, live updates, animations).
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states the tool is non-actional ('without performing any action'), which transparently communicates its behavioral trait. However, it could detail what 're-capture' entails (e.g., updating internal state) but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the verb and resource, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides adequate context: it explains the tool's passive nature and when to use it. It could mention the effect of omitting page_id (defaults to most recent page) but the schema already implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter 'page_id'. The description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Re-capture the page state without performing any action.' It uses a specific verb ('re-capture') and resource ('page state'), and distinguishes from siblings like click or screenshot by emphasizing passivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use when the page may have changed on its own (timers, live updates, animations).' It does not mention alternatives, but the scenario is clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into an input field or text area (by eid). Set clear to replace existing content instead of appending. Returns a fresh page snapshot reflecting the updated field and any resulting changes (validation, autocomplete, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| eid | Yes | Element ID of the input field from find results or the page snapshot. | |
| text | Yes | The text to type into the element. | |
| clear | No | If true, clear the field before typing (replaces content). If false (default), append to existing text. | |
| page_id | No | Page ID. If omitted, operates on the most recently used page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially fulfills the burden by mentioning return of a fresh page snapshot and resulting changes (validation, autocomplete). However, it omits details like focusing the element, waiting for interactivity, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded information. Every sentence provides value: core action, clear behavior, and return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and 27 sibling tools, the description covers the main action and return but lacks comparison to siblings like 'press' and does not mention prerequisites (e.g., element must be input/textarea).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds only minor context (e.g., 'replace existing content' for the 'clear' parameter). It does not significantly enhance understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Type text into an input field or text area') using a specific verb and resource ('by eid'). It distinguishes from sibling tools like 'click' and 'select' by focusing on text input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic context ('by eid', return snapshot) but does not explicitly state when to use this tool versus alternatives like 'press' or 'select'. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatch a mouse wheel event at specific coordinates. Use for scroll-to-zoom (with Control modifier) or horizontal scrolling.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X coordinate where the wheel event is dispatched. | |
| y | Yes | Y coordinate where the wheel event is dispatched. | |
| eid | No | Optional element ID. When provided, x/y coordinates are relative to the element top-left corner. | |
| deltaX | No | Horizontal scroll delta in pixels. Positive scrolls right. | |
| deltaY | Yes | Vertical scroll delta in pixels. Positive scrolls down, negative scrolls up. For zoom: negative typically zooms in, positive zooms out. | |
| page_id | No | The ID of the page. | |
| modifiers | No | Modifier keys to hold during the wheel event (e.g., Control for zoom). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions behavioral effects (zoom with Control, horizonal scroll) but does not elaborate on default behavior, such as what happens without modifiers (vertical scroll) or event dispatching details. Given no annotations, this is adequate but leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the primary action. Every word serves a purpose, with no redundancy or filler. It efficiently conveys both the core function and primary use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of sibling tools like 'scroll' and 'scroll_to', the description adequately captures its distinct purpose. However, it does not explicitly differentiate from those tools or explain the return value, though this is minor for an event dispatch action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so baseline is 3. The description adds context by mentioning 'Control modifier' and 'horizontal scrolling,' which relate to parameters 'modifiers' and 'deltaX', but does not provide additional semantic details beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool dispatches a mouse wheel event at specific coordinates, with explicit use cases for scroll-to-zoom and horizontal scrolling. This distinguishes it from sibling tools like 'scroll' and 'scroll_to' by specifying the exact event type and coordinate-based nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides two explicit use cases: 'scroll-to-zoom (with Control modifier)' and 'horizontal scrolling'. It implies when these scenarios apply but does not explicitly state when not to use this tool or mention alternatives like 'scroll' or 'hover'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_element2 fields changedInput schema / properties / eid / descriptionAdded value: +"Element ID to inspect, obtained from find results or the page snapshot."Input schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."get_field2 fields changedInput schema / properties / eid / descriptionAdded value: +"Element ID of the form field to inspect, from get_form or the page snapshot."Input schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."get_form3 fields changedInput schema / properties / form_id / descriptionAdded value: +"Restrict the result to a single form by its id (from a prior get_form call). If omitted, all forms on the page are returned."Input schema / properties / include_values / descriptionAdded value: +"When true, include each field's current value in the response. Defaults to false; sensitive values (passwords, tokens) remain masked even when enabled."Input schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."go_back1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."go_forward1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."hover1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."navigate2 fields changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."Input schema / properties / url / descriptionAdded value: +"Absolute URL to navigate to, including the scheme (e.g. https://example.com)."press3 fields changedInput schema / properties / key / descriptionAdded value: +"Key to press on the focused element, e.g. Enter to submit, Escape to dismiss, Tab to move focus, or the arrow keys to navigate."Input schema / properties / modifiers / descriptionAdded value: +"Modifier keys to hold while the key is pressed (e.g. Control, Shift)."Input schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."reload1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."scroll3 fields changedInput schema / properties / amount / descriptionAdded value: +"Distance to scroll in pixels (default: 500)."Input schema / properties / direction / descriptionAdded value: +"Direction to scroll the viewport: 'up' or 'down'."Input schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."scroll_to1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."select1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."snapshot1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."type1 field changedInput schema / properties / page_id / descriptionAdded value: +"Page ID. If omitted, operates on the most recently used page."v4.6.4clickclose_pagedragfindget_elementget_fieldget_formgo_backgo_forwardhoverinspect_canvaslist_network_callslist_pagesnavigatepingpressread_pagereloadscreenshotscrollscroll_tosearch_network_callsselectsnapshottypewheelEach tool has a clearly distinct purpose, from navigation (navigate, go_back) to element interaction (click, hover, drag) to form handling (get_form, type). There is no overlap between tools; even similar operations like scroll and wheel are differentiated by mechanism.
Tool names follow a consistent verb_noun pattern, using snake_case for multi-word names (e.g., close_page, list_pages, scroll_to). Single-word verbs (click, drag, hover) are also consistent. No mixing of conventions.
With 26 tools covering navigation, interaction, form handling, network inspection, and canvas analysis, the count is slightly high but justified for a comprehensive browser automation server. Each tool serves a specific need, though a few might be consolidated.
The tool set covers most common browser automation tasks, but notable gaps exist: no explicit wait_for_element or wait_for_navigation, no JavaScript execution, and no cookie management. These omissions may require workarounds for certain scenarios.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Turn any webpage into a structured action manifest — clickable, fillable, submittable elements.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/drisplabs/browser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
