Skip to main content
Glama
Sign In
real-browser-mcp

real-browser-mcp

by ofershap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_tabs

Control browser tabs and the extension-managed tab group: list, create, close, focus, name, or ungroup tabs, and set group titles.

Instructions

Manage browser tabs and the extension-managed tab group. list/create/close/focus tabs. name puts the tab into a Real Browser MCP tab group and sets the group title (emoji in the title is shown as the group icon). ungroup removes the tab from its group.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "browser_tabs"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoURL for create action
colorNoTab group color for name. Random if omitted when creating a new group.
tabIdNoTab ID for close/focus/name/ungroup. Defaults to the active tab for name/ungroup.
titleNoGroup title for name. Emoji is allowed and Chrome shows it as the group icon.
actionYesTab action. name creates or updates the managed tab group title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.3.0
    • changedInput schema / properties / action / description
      Previous value: -"Tab action"New value: +"Tab action. name creates or updates the managed tab group title."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "list",
-  "create",
-  "close",
-  "focus"
-]New value: +[
+  "list",
+  "create",
+  "close",
+  "focus",
+  "name",
+  "ungroup"
+]
    • addedInput schema / properties / color
      Added value: +{
+  "description": "Tab group color for name. Random if omitted when creating a new group.",
+  "enum": [
+    "grey",
+    "blue",
+    "red",
+    "yellow",
+    "green",
+    "pink",
+    "purple",
+    "cyan",
+    "orange"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / tabId / description
      Previous value: -"Tab ID for close/focus"New value: +"Tab ID for close/focus/name/ungroup. Defaults to the active tab for name/ungroup."
    • addedInput schema / properties / title
      Added value: +{
+  "description": "Group title for name. Emoji is allowed and Chrome shows it as the group icon.",
+  "type": "string"
+}
  2. First observedv1.2.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose real side effects: name moves the tab into a Real Browser MCP tab group and sets its title, and ungroup removes it from that group. It does not state whether close is destructive, whether focus changes the active window, permission requirements, or what list returns, leaving meaningful behavioral gaps.

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?

Four compact sentences, front-loaded with the resource and the action list before the group-specific semantics. Slight redundancy with the schema's own title/emoji and color wording, but no padding.

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

Completeness3/5

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

The tool has 6 actions and 5 parameters with no annotations and no output schema. The description covers the group-related actions well, but leaves the list action's return shape and the close action's consequences unstated, so an agent still lacks some information needed to invoke it confidently.

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 schema already documents each parameter including the title/emoji and color/random semantics. The description largely restates those facts (emoji as group icon, group assignment), adding little new parameter meaning beyond the baseline.

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

Purpose4/5

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

The description names a concrete resource (browser tabs and the extension-managed tab group) and enumerates the specific actions: list/create/close/focus/name/ungroup. It is far more specific than a generic 'manage tabs' and no sibling tool overlaps this tab-management domain, though it never explicitly differentiates itself from the page-interaction siblings.

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?

The description explains what name and ungroup do, which implicitly tells the agent when those actions apply, and lists the other available actions. However, it gives no when-to-use vs alternative guidance (e.g., when to focus vs navigate, or when to close vs leave a tab) and no prerequisites.

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