Skip to main content
Glama

browser_click_and_wait_navigation

Clicks a link or submit button and waits for the resulting page navigation to complete, combining both steps to avoid race conditions in browser automation.

Instructions

Click an element, then wait for the resulting navigation to complete.

Atomic operation — far more reliable than browser_click followed by browser_wait_for_url for links/submit buttons. Listens for tabs.onUpdated(status='complete').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tab_idNo
timeoutNo
selectorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does add real mechanism detail — it listens for tabs.onUpdated(status='complete'), which tells the agent exactly what completion means. However it omits error/timeout behavior (what happens if navigation never completes within the 15s default) and any side-effect or permission notes for what is effectively a click/mutation.

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?

Front-loaded with the core action, followed by the differentiation note and then the mechanism. Three tight sentences with little waste, though the mechanism detail is slightly technical relative to the routing value.

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?

No annotations, no output schema, and 0% parameter coverage mean the description should carry more than it does. Purpose and completion semantics are well covered, but the failure mode on timeout and the meaning of the three parameters are left entirely unexplained, leaving real gaps for a callable mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 3 parameters, so the description must compensate and does not: `selector`, `tab_id`, and `timeout` are never mentioned or explained. The only indirect relevance is that the wait mechanism implies what `timeout` governs, but no syntax, format, or default semantics are added.

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 compound action — click an element, then wait for navigation — with a clear verb and resource. It explicitly distinguishes itself from siblings by naming `browser_click` + `browser_wait_for_url` and declaring itself the more reliable atomic alternative for links/submit buttons.

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?

Clearly signals when to use it (links/submit buttons that trigger navigation) and names the alternative sequential tools it replaces, which is strong routing guidance. It stops short of stating when NOT to use it, e.g. for clicks that do not navigate, where plain `browser_click` would be correct.

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