Skip to main content
Glama
yogesh-joshi-0333

browser-control-mcp-server

Navigate Back

browser_navigate_back

Return to the previous page in browser history, equal to clicking the browser back button. Use after navigating to a page and needing to go back.

Instructions

Navigate back to the previous page in browser history — equivalent to clicking the browser back button. Use after navigating to a page and wanting to return to the previous one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoForce a specific mode.
sessionIdNoPuppeteer session ID. Skips mode selection.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations exist, so the description carries the full behavioral burden. It does disclose the state-changing effect (browser history traversal) via the back-button comparison, but says nothing about what happens when history is empty, whether it waits for the page load to settle, or how it interacts with the session/mode context.

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?

Two short sentences, front-loaded with the core action and the back-button analogy, which is a genuinely useful clarification. The trailing usage sentence is mildly redundant given the action is self-evident, but nothing is wasted.

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?

For a zero-required-parameter navigation tool with no output schema and full schema coverage, the description supplies what an agent needs to select and call it. Only edge-case behavior (no history available, load-wait semantics) is missing, which is a minor gap for this tool's complexity.

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 mode and sessionId are already documented in the schema. The description adds no additional parameter context, which is acceptable at this coverage level but leaves 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?

States a specific verb ('Navigate back') and the exact resource/scope ('previous page in browser history'), and the back-button analogy pins down the semantics unambiguously. It distinguishes itself from sibling browser_navigate_forward by direction, though it never names that sibling or browser_navigate/reload explicitly.

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?

'Use after navigating to a page and wanting to return to the previous one' gives a clear trigger condition, which is more than most siblings provide. It stops short of stating when NOT to use it (e.g., when there is no history entry, or when browser_reload is what is actually wanted).

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