Skip to main content
Glama

Go back or forward

browser_traverse_history

Move the active Firefox tab backward or forward through its session history using a delta value, so AI agents can navigate pages without manual clicking.

Instructions

Move the active tab through its session history (browsingContext.traverseHistory): delta -1 is back, +1 is forward. Fails with "no such history entry" when that direction has nothing to go to, which is a normal answer rather than a broken tool.

Input Schema

NameRequiredDescriptionDefault
deltaYesNegative goes back, positive goes forward (e.g. -1 or 1)
contextNoTab context id (default: the active tab)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=false, so the description carries most of the burden, and it delivers the single most useful behavioral fact: the expected failure mode and its benign interpretation. It does not say what happens to the forward stack after a new navigation, nor what the call returns (no output schema exists), but the error semantics are the high-value disclosure here.

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, no filler, with the core action and delta convention front-loaded and the failure-mode caveat appended where it is needed.

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 2-parameter tool with no output schema and minimal annotations, the description covers purpose, parameter convention, and the expected error case. Remaining gaps — return value and forward-history invalidation behavior — are modest but real.

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 coverage is 100% and the delta property already documents 'Negative goes back, positive goes forward (e.g. -1 or 1)'. The description's '-1 is back, +1 is forward' largely restates the schema, though tying the failure condition to direction adds a little. Baseline 3 is appropriate.

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 — 'Move the active tab through its session history' — and even names the underlying API (browsingContext.traverseHistory). This is clearly distinguishable from siblings like browser_navigate or browser_activate_tab, which also move the active tab but for different reasons.

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?

Explains the delta semantics (-1 back, +1 forward) and, importantly, that a 'no such history entry' failure is a normal answer rather than a broken tool — that tells the agent when this call legitimately has nothing to do. It stops short of explicitly naming alternatives (e.g. use browser_navigate for new URLs instead of traversing), so no exclusion guidance.

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