browser_go_forward
Navigate forward in browser history to return to a previously visited page during web automation.
Instructions
Go forward to the next page.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Navigate forward in browser history to return to a previously visited page during web automation.
Go forward to the next page.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what happens when there is no forward history, whether the tool waits for page load, or whether it returns any status or error. The description is too sparse to convey important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly concise sentence that immediately conveys the action. Every word earns its place, and there is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is minimally viable but lacks context about browser history behavior, failure modes, or relation to sibling navigation tools. It is complete enough for a trivial action, but omits edge-case behavior that could surprise an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema provides no parameter semantics. Per the rubric baseline, a zero-parameter tool receives a 4, and there is no additional parameter information needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go forward to the next page' clearly identifies the action (go forward) and the target resource (next page). It distinguishes this tool from its sibling browser_go_back, which would be the natural alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_go_back or browser_navigate. The description implies navigation through browser history, but it never explicitly states the prerequisite of having previously navigated back or that it only works within the current tab's history stack.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mazamakasa/octo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server