Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_active_tab

Read-onlyIdempotent

Retrieve the identity of the user's active Chrome tab—ID and domain only, with URL and title redacted until the tab is adopted—to confirm which tab to request access to.

Instructions

Identity of the user's active tab, read-only: id and domain only (url = origin, title null, redacted=true) unless the tab is mine. It stays the user's (to act on it at the user's explicit request: browser_adopt_tab, after which its full title and URL are shown).

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
dataYes
statusYes
warningNoEmergency stop hotkey not held, or similar notice
untrusted_noteNoPage text that looks like instructions aimed at an AI

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv2.31.6
    • addedOutput schema / $defs
      Added value: +{
+  "Tab": {
+    "additionalProperties": true,
+    "description": "Tab. Full title and URL only for this session's tabs (mine); otherwise title null, url reduced to the origin,\nredacted true. state: mine, orphan, other or user.",
+    "properties": {
+      "active": {
+        "type": "boolean"
+      },
+      "adopted": {
+        "type": "boolean"
+      },
+      "favIconUrl": {
+        "type": "string"
+      },
+      "groupId": {
+        "type": "integer"
+      },
+      "id": {
+        "type": "integer"
+      },
+      "index": {
+        "type": "integer"
+      },
+      "mine": {
+        "type": "boolean"
+      },
+      "owner": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "pinned": {
+        "type": "boolean"
+      },
+      "redacted": {
+        "type": "boolean"
+      },
+      "state": {
+        "type": "string"
+      },
+      "title": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "url": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "windowId": {
+        "type": "integer"
+      }
+    },
+    "title": "Tab",
+    "type": "object"
+  }
+}
    • addedOutput schema / additionalProperties
      Added value: +true
    • addedOutput schema / description
      Added value: +"The user's active tab, or null."
    • addedOutput schema / properties / data
      Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/Tab"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • removedOutput schema / properties / result
      Removed value: -{
-  "title": "Result",
-  "type": "string"
-}
    • addedOutput schema / properties / status
      Added value: +{
+  "const": "success",
+  "type": "string"
+}
    • addedOutput schema / properties / untrusted_note
      Added value: +{
+  "description": "Page text that looks like instructions aimed at an AI",
+  "type": "string"
+}
    • addedOutput schema / properties / warning
      Added value: +{
+  "description": "Emergency stop hotkey not held, or similar notice",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "result"
-]New value: +[
+  "status",
+  "data"
+]
    • changedOutput schema / title
      Previous value: -"browser_active_tabOutput"New value: +"ActiveTabAnswer"
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds meaningful context beyond them: URL is reduced to origin, title is null, redacted=true unless the tab belongs to the agent, and adoption changes what is exposed. This goes beyond structured annotations, though it could clarify the 'mine' ownership state more precisely.

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?

The description is compact and front-loads the core identity/read-only purpose before explaining the redaction exception and adoption path. The parenthetical structure is slightly dense and the phrase 'unless the tab is mine' could be clearer, but there is little wasted text.

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

Completeness4/5

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

Given the zero-parameter schema, output schema, and annotations, the description provides enough behavioral context about privacy redaction and the adopt-tab alternative. It is nearly complete, though a direct contrast with browser_list_tabs or browser_select_tab would remove remaining ambiguity.

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?

The tool takes zero parameters, so parameter semantics are not a concern and the baseline of 4 applies. The description does not need to explain any input parameters.

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 clearly identifies the resource ('the user's active tab') and the returned identity fields, with a specific note that it is read-only and privacy-redacted. It distinguishes itself from the adopt-flow alternative, though it does not explicitly contrast with siblings like browser_list_tabs or browser_select_tab.

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

Usage Guidelines4/5

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

It provides a clear condition for using browser_adopt_tab when the user explicitly requests action on the tab, which is a useful routing cue. However, it does not state explicit exclusions or when to prefer other tab-listing/selection tools.

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