Skip to main content
Glama
Agent360dk

Browser MCP

by Agent360dk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_navigate

Navigate the active browser tab to a target URL, reusing the current tab to prevent tab spam. Pass new_tab to keep the existing page open and open the link in a separate tab.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to navigate to
fokuserNoWith 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_tabNoOpen in new tab instead of reusing current (default: false)
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. Read the displays first; do not guess.
vindue_yNoWith eget_vindue: the window's top edge in global screen points.
eget_vindueNoRequires 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.
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. 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"
+}
  2. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/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. It discloses the 'no tab spam' behavior (reuses current tab) but omits potential side effects, error conditions, or the quirks of the window/focus parameters (like Chrome refusing focus) that are only described in the schema. Basic behavior is covered, but not the full scope.

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

Conciseness5/5

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

Two sentences with zero waste, front-loading the main action and the default behavior. Efficient and well-structured.

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

Completeness2/5

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

With 8 parameters and no output schema, the description is insufficient. It only covers basic navigation and doesn't hint at the window management capabilities (eget_vindue, fokuser) or describe what happens after navigation (e.g., return value, page load). An agent reading only the description would be unaware of the tool's full feature set.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds context for new_tab (why to use it) but ignores the other 6 parameters entirely, providing only marginal value beyond the schema.

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

Purpose5/5

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

States a specific verb+resource: 'Navigate the active browser tab to a URL.' It clearly differentiates from sibling tools like browser_click or browser_fill by focusing on navigation, and even clarifies the default tab-reuse behavior.

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

Usage Guidelines3/5

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

Provides clear guidance on when to use new_tab ('Pass new_tab=true only when you need to keep the current page open'), but doesn't mention the advanced window parameters (eget_vindue, fokuser, etc.) or discuss alternatives to this tool. Guidance is limited to basic tab behavior.

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