lyra-browser

Official

Overview Schema Source Related Servers Discussions Admin

click

Activate the first element matching a CSS or Playwright text selector; declare form submits or downloads to request permission and avoid blocked actions.

Instructions

Click the first element matching selector (CSS or Playwright text=).

Set submits=true when the control sends a form or completes a purchase — that asks for the permission it needs. If the page submits anyway without you declaring it, the request is stopped, so declare it when you mean it. reason is shown to the user when they are asked.

Fails fast instead of hanging. A selector that matches nothing answers not_found, and a match that cannot be used hidden or disabled — each after at most a few seconds' wait for a page that is still building or enabling its controls, and before anyone is asked. Once clicking, timeout_ms (default 10000, max 30000) bounds the wait, and a failure answers timeout (the click may have landed — look at the page before clicking again), element_not_actionable (covered, detached) or page_closed.

The reply says how many elements matched (matches; the first is clicked) and what was hit (clicked: tag, role, name), so a wrong pick is visible.

If the click makes the page navigate and the browser refuses it — no approval covers the destination, or a form was sent without submits=true — the reply is blocked_by_policy (with url, where the tab still stands, and redirected_to when the site redirected the browser elsewhere) and the tab has not moved: navigate to the destination to be asked for it. A click that opens a tab answers new_tab: true and tab_count; the new tab is the one every later call reads and acts on (tabs goes back).

Set download=true when the click is meant to save a file: that asks for permission to write one, and the reply carries download (filename, path, bytes, url_origin) once it is saved. A click that starts a download without it is cancelled and answered download_blocked — nothing is saved, so repeat the click with download=true. The permission pays for one file and ends with the call.

A native dialog the page raised is answered at once and listed under dialogs in the reply; handle_dialog chooses the answer beforehand.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`reason`	No
`confirm`	No
`submits`	No
`download`	No
`selector`	Yes
`timeout_ms`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers: fail-fast behavior, the not_found/hidden/disabled/timeout/element_not_actionable/page_closed failure modes, the policy-stop semantics of submits, one-file download permission that ends with the call, tab-following behavior, and dialog handling. This is unusually rich disclosure of what can go wrong and why.

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?

The core action is front-loaded and most sentences carry distinct behavioral facts (blocked_by_policy, download_blocked, new_tab). It is nonetheless long and dense enough that a few clauses, such as the repeated 'asks for the permission it needs' phrasing, could be tightened.

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 six-parameter mutation tool with no annotations and 0% schema coverage, the description is nearly complete, covering failure modes, permissions, and side effects; an output schema exists so return fields need not be detailed, though it still names the key reply fields. The unexplained 'confirm' parameter is the one meaningful hole.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it explains reason, submits, download, selector syntax, and timeout_ms (default 10000, max 30000). It never mentions the 'confirm' parameter, so one of six parameters remains undefined anywhere.

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?

The opening sentence states a specific verb, resource, and selector syntax ('Click the first element matching selector (CSS or Playwright text=)'), which cleanly separates it from siblings like hover, type_text, and select_option. An agent knows exactly what action this performs without opening the schema.

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?

It gives explicit conditional guidance: set submits=true when the control sends a form or completes a purchase, set download=true when saving a file, and use handle_dialog beforehand for dialogs. However, it never routes the agent to a sibling for adjacent needs (e.g. hover before click, or navigate when blocked), leaving some alternative-selection to inference.

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