Skip to main content
Glama
Sign In
Browser MCP

Browser MCP

by Agent360dk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_navigate

Navigate the active Chrome tab to a URL, reusing the current tab by default or opening a new one. Use it to load pages for scraping or testing while preserving logged-in sessions.

Instructions

Navigate the active browser tab to a URL. Reuses the current tab by default (no tab spam). Pass new_tab=true only when you need to keep the current page open. In the current tab the answer is ok:true only when Chrome took the address and the new page is proven loaded within about 25 s (the wait ends half a second before that limit). If the page asks "Leave site?", the default answer is Stay (an armed browser_handle_dialog answers instead) and the reply is error beforeunload-blocked with the tab's actual url: the page may hold unsaved work, so ask the user (browser_ask_user) before you call again with leave_page:true. Other errors, each with sent (was the address sent to Chrome?) and a note on what to do: navigation-in-progress (another navigate is working in this tab, or - with op_id null - an earlier answer to a dialog on the tab is not confirmed yet; wait a moment), dialog-open (a dialog is on screen - answer it with browser_handle_dialog), tab-not-responding (busy page, or a dialog Chrome does not show us), navigation-failed, dialog-unconfirmed, navigation-unconfirmed (no load proven in time; may_complete_later and pending_url say it can still happen - read the tab before sending it again; a download or a 204 answer never loads a page and ends here too), tab-closed (Chrome no longer has the tab), session-changed (another call changed the session's active tab while this one waited; nothing was sent).

Input Schema

NameRequiredDescriptionDefault
urlYesURL to navigate to
fokuserNoWith eget_vindue: ASK for the new window to get the operating system's focus. Chrome can refuse it. The reply carries what actually happened - read `fokuseret` and `placeret_som_bedt` rather than assuming this worked. Do not rely on vindue_x to keep a run off the user's screen.
new_tabNoOpen in new tab instead of reusing current (default: false). If the session's only tab is still an empty about:blank placeholder, that tab is used instead of opening another.
vindue_xNoWith eget_vindue: the window's left edge in global screen points. A NEGATIVE value is a display to the left of the main one - that is how you put it on another screen. No tool lists the displays: use a coordinate you know is on an unused screen, and read `placeret_som_bedt` in the reply.
vindue_yNoWith eget_vindue: the window's top edge in global screen points.
leave_pageNoAnswer "Leave site?" with Leave instead of Stay (default: false), so unsaved changes on the current page are lost. Only after the user has agreed (browser_ask_user). An armed browser_handle_dialog on the tab takes precedence over this.
eget_vindueNoRequires new_tab. Opens the page in its own Chrome window, without focus unless you pass fokuser:true. Whether Chrome delivers mouse and keyboard input to a window without focus is unmeasured in desktop Chrome (a measurement on 19 Sept probably tested a background tab, because the tab was moved back into the session's first window; fixed in 1.30.2), so read landed in each input tool's answer. On a machine with more than one display, you can put the window on a screen nobody is looking at and pass fokuser:true - but focus is exclusive: while this window has it, whatever the person types lands in it. Use that only on a machine nobody is typing on.
vindue_breddeNoWith eget_vindue: window width in points.
vindue_hoejdeNoWith eget_vindue: window height in points.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.30.3
    • addedInput schema / properties / leave_page
      Added value: +{
+  "description": "Answer \"Leave site?\" with Leave instead of Stay (default: false), so unsaved changes on the current page are lost. Only after the user has agreed (browser_ask_user). An armed browser_handle_dialog on the tab takes precedence over this.",
+  "type": "boolean"
+}
  2. Changed4 schema fields changedv1.30.2
    • changedInput schema / properties / eget_vindue / description
      Previous value: -"Requires new_tab. Opens the page in its own Chrome window. On its own this does NOT make input work: measured 19 Sept, an unfocused window delivers no keystrokes at all, exactly like a background tab - what decides it is whether the WINDOW has the operating system's focus, not whether the tab is the visible one in it. What this is genuinely for: on a machine with more than one display, put the window on a screen nobody is looking at and pass fokuser:true. Then Chrome delivers input and nothing covers the person's work."New value: +"Requires new_tab. Opens the page in its own Chrome window, without focus unless you pass fokuser:true. Whether Chrome delivers mouse and keyboard input to a window without focus is unmeasured in desktop Chrome (a measurement on 19 Sept probably tested a background tab, because the tab was moved back into the session's first window; fixed in 1.30.2), so read landed in each input tool's answer. On a machine with more than one display, you can put the window on a screen nobody is looking at and pass fokuser:true - but focus is exclusive: while this window has it, whatever the person types lands in it. Use that only on a machine nobody is typing on."
    • changedInput schema / properties / fokuser / description
      Previous value: -"With eget_vindue: ASK for the new window to get the operating system's focus, which keyboard and mouse input needs. ⛔ Measured 21 Sept: Chrome often refuses, and the window was on none of the machine's three screens. The reply now carries what actually happened - read `fokuseret` and `placeret_som_bedt` rather than assuming this worked. Do not rely on vindue_x to keep a run off the user's screen."New value: +"With eget_vindue: ASK for the new window to get the operating system's focus. Chrome can refuse it. The reply carries what actually happened - read `fokuseret` and `placeret_som_bedt` rather than assuming this worked. Do not rely on vindue_x to keep a run off the user's screen."
    • changedInput schema / properties / new_tab / description
      Previous value: -"Open in new tab instead of reusing current (default: false)"New value: +"Open in new tab instead of reusing current (default: false). If the session's only tab is still an empty about:blank placeholder, that tab is used instead of opening another."
    • changedInput schema / properties / vindue_x / description
      Previous value: -"With eget_vindue: the window's left edge in global screen points. A NEGATIVE value is a display to the left of the main one - that is how you put it on another screen. Read the displays first; do not guess."New value: +"With eget_vindue: the window's left edge in global screen points. A NEGATIVE value is a display to the left of the main one - that is how you put it on another screen. No tool lists the displays: use a coordinate you know is on an unused screen, and read `placeret_som_bedt` in the reply."
  3. Changed6 schema fields changedv1.30.0
    • addedInput schema / properties / eget_vindue
      Added value: +{
+  "description": "Requires new_tab. Opens the page in its own Chrome window. On its own this does NOT make input work: measured 19 Sept, an unfocused window delivers no keystrokes at all, exactly like a background tab - what decides it is whether the WINDOW has the operating system's focus, not whether the tab is the visible one in it. What this is genuinely for: on a machine with more than one display, put the window on a screen nobody is looking at and pass fokuser:true. Then Chrome delivers input and nothing covers the person's work.",
+  "type": "boolean"
+}
    • addedInput schema / properties / fokuser
      Added value: +{
+  "description": "With eget_vindue: ASK for the new window to get the operating system's focus, which keyboard and mouse input needs. ⛔ Measured 21 Sept: Chrome often refuses, and the window was on none of the machine's three screens. The reply now carries what actually happened - read `fokuseret` and `placeret_som_bedt` rather than assuming this worked. Do not rely on vindue_x to keep a run off the user's screen.",
+  "type": "boolean"
+}
    • addedInput schema / properties / vindue_bredde
      Added value: +{
+  "description": "With eget_vindue: window width in points.",
+  "type": "number"
+}
    • addedInput schema / properties / vindue_hoejde
      Added value: +{
+  "description": "With eget_vindue: window height in points.",
+  "type": "number"
+}
    • addedInput schema / properties / vindue_x
      Added value: +{
+  "description": "With eget_vindue: the window's left edge in global screen points. A NEGATIVE value is a display to the left of the main one - that is how you put it on another screen. Read the displays first; do not guess.",
+  "type": "number"
+}
    • addedInput schema / properties / vindue_y
      Added value: +{
+  "description": "With eget_vindue: the window's top edge in global screen points.",
+  "type": "number"
+}
  4. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does: it discloses the default tab-reuse behaviour, the ~25 s load-proof deadline, the beforeunload 'Stay' default with its error shape, and a full enumeration of failure modes (navigation-in-progress, dialog-open, tab-not-responding, navigation-unconfirmed, tab-closed, session-changed) each with a remediation hint. This is unusually rich behavioural disclosure for a mutation/IO tool.

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

Conciseness4/5

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

Front-loaded with purpose and the primary default in the first two sentences, and every clause carries actionable content. The error enumeration is delivered as one very dense run-on sentence, which hurts scanability for a 9-parameter tool, but nothing is padding.

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

Completeness5/5

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

With no annotations and no output schema, the description must supply the entire operational contract, and it does: defaults, timeout semantics, the ok:true success condition, dialog precedence, and the complete error taxonomy with remediation. An agent has enough to call this correctly and interpret every outcome without further documentation.

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

Parameters4/5

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

Schema coverage is 100% and the schema descriptions are themselves verbose, so the baseline is 3; the description nonetheless reinforces meaning beyond bare field names, e.g. that new_tab reuses an empty about:blank placeholder, that leave_page discards unsaved changes and requires prior user agreement, and that an armed browser_handle_dialog overrides leave_page. It stops short of explaining the spatial parameters (vindue_x/y/bredde/hoejde), which the schema handles.

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

Purpose5/5

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

States a specific verb and resource ('Navigate the active browser tab to a URL') and immediately distinguishes its default behaviour from related siblings ('Reuses the current tab by default (no tab spam)'). An agent can tell it apart from browser_get_new_tab, browser_switch_tab, or browser_fetch without opening their schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance for the branching parameter ('Pass new_tab=true only when you need to keep the current page open') and routes to named alternatives for the hard cases ('ask the user (browser_ask_user)', 'answer it with browser_handle_dialog'). Both the conditions and the sibling tools are named, leaving little to inference.

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

Deploy Server

Other Tools