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

sandboxed-browser-mcp

by smkamranqadri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Navigate

browser_navigate

Loads a URL in a sandboxed browser tab and returns the page as structured text, with each element on its own line and a ref for acting on it.

Instructions

Loads a URL in the browser tab and returns the page as text: each element on its own line, with a ref for acting on it. browser_back returns to the previous page; browser_snapshot looks again without moving.

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": {
      "url": "<url>"
    },
    "name": "browser_navigate"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesWhere to go: a complete URL including its scheme, e.g. https://…
profileNoWhich browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.default

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / profile
      Added value: +{
+  "default": "default",
+  "description": "Which browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.",
+  "type": "string"
+}
  2. Changed2 schema fields changedv1.1.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / url / description
      Previous value: -"Full URL with scheme, e.g. https://example.com/page"New value: +"Where to go: a complete URL including its scheme, e.g. https://…"
  3. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare openWorldHint=true and readOnlyHint=false, so the agent knows this is an outward-facing, state-changing operation; the description adds the non-obvious behavioral fact that the response is a line-per-element text rendering with refs, which is essential for subsequent actions. It stops short of mentioning that navigating away discards the current page state, redirects, or load/wait behavior, so it is strong but not exhaustive.

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, front-loaded with what the tool does and what it returns, followed by the disambiguation clause. Every clause carries information and nothing is padded.

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?

With no output schema, the description correctly compensates by explaining the returned text format and refs, which is the key thing an agent needs to chain calls. The only gap is behavioral edge context (losing current page state, waits/redirects) for a tool that is not read-only and operates on the open web.

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%, including the full-URL-with-scheme requirement and the profile selection rule, so the schema already carries parameter meaning. The description adds nothing about either parameter, leaving it at the baseline for a fully documented 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 and resource ('Loads a URL in the browser tab') and goes further by describing the result shape: text with one element per line and a ref for acting on it. It explicitly contrasts itself with browser_back and browser_snapshot, so an agent can distinguish it from those siblings without opening any schema.

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?

Names two alternatives with the exact condition that selects each: browser_back for returning to the previous page, browser_snapshot for re-reading without moving. That implicitly and clearly frames navigate as the tool for changing location, which is precisely the routing decision an agent must make among these siblings.

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