Skip to main content
Glama
shaun0927

OpenChrome

by shaun0927
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

navigate

Navigate to URLs or move forward/back in a controlled Chrome browser, supporting new tabs, stealth mode to bypass anti-bot pages, and auto-retry on WAF blocks.

Instructions

Navigate to URL or go forward/back. Omit tabId for new tab.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL, "forward", or "back"
tabIdNoTab ID. Omit for new tab
headedNoForce navigation in headed (non-headless) Chrome. Bypasses CDN/TLS-level blocking by using a real Chrome user-agent and TLS fingerprint. Requires a display. Default: false.
laneIdNoTask-scoped browser lane id. When supplied with taskId, navigate uses/records the lane-owned target.
recallNoOverride OPENCHROME_AUTO_RECALL for this call. true forces domain skill injection; false suppresses it even when the flag is on.
taskIdNoTask id when routing through a task-scoped browser lane.
stealthNoCDP-free mode: opens tab via Chrome debug API without CDP attachment during page load. Use for Cloudflare Turnstile or similar anti-bot pages. CDP attaches after page settles.
workerIdNoWorker ID for parallel ops. Default: default
autoFallbackNoAuto-retry with stealth when CDN/WAF block is detected (access-denied, bot-check, captcha). Default: true. Set false to disable.
stealthSettleMsNoHow long to wait (ms) before attaching CDP in stealth mode. Default: 8000. Range: 1000-30000.
capture_artifactNoWhen true, stage a replay artifact navigation step for oc_skill_record after a successful URL navigation. Default false is a strict no-op.
profileDirectoryNoChrome profile directory name (e.g., "Profile 1"). Use list_profiles to see available profiles. Launches a separate Chrome instance for each profile. If omitted, uses the server default. Cannot be combined with workerId.
allowHeadedFallbackNoExplicit permission to launch a visible fallback browser for this request. May change foreground on first launch. Default false returns a user-interaction checkpoint.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.15.0
    • addedInput schema / properties / allowHeadedFallback
      Added value: +{
+  "default": false,
+  "description": "Explicit permission to launch a visible fallback browser for this request. May change foreground on first launch. Default false returns a user-interaction checkpoint.",
+  "type": "boolean"
+}
  2. First observedv1.12.8

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already set readOnlyHint=false and destructiveHint=false. The description adds useful context about history navigation (forward/back) and the new-tab behavior when tabId is omitted, which the annotations do not convey. It does not mention the more complex fallback/stealth behaviors, but these are documented in the schema.

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 short sentences, front-loaded with the core action and the key alternative behavior. No filler words; every phrase earns its place.

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

Completeness3/5

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

Given the tool's complexity (13 params, no output schema, many sibling operations), the description is extremely terse and omits any return-value or success/failure semantics. The schema covers parameter meanings, but the description does not orient the agent on how navigate relates to sibling tools or what the result of a successful navigation looks like.

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 the schema already carries the full burden of parameter documentation. The description's 'Omit tabId for new tab' restates the schema's own note for tabId, adding no new semantic value beyond what is already present.

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 states a clear verb (Navigate) and the resource (URL or forward/back), making the action unambiguous. It does not explicitly differentiate from sibling navigation tools like crawl, act, or page_reload, but the core purpose is evident.

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

Usage Guidelines2/5

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

The description offers no guidance on when to prefer this tool over siblings like page_reload, crawl, or tabs_create. The only guidance is 'Omit tabId for new tab', which is parameter-level instruction rather than tool-selection 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