web-speed-agent

Overview Schema Source Related Servers Discussions Admin

click

Click an element by CSS selector, with integrated waits for page loads, modal opens, or DOM changes—replacing separate wait calls to avoid flaky timing.

Instructions

Click an element by CSS selector.

The wait arguments all run inside THIS call. Reach for them instead of following a click with a separate wait tool — the extra round-trip costs far more than the wait. Prefer wait_for / wait_for_predicate / wait_until over wait_ms: a fixed sleep is either too short (flaky) or too long (slow), while a condition returns the moment it is satisfied.

Args: selector: CSS selector for the element to click. wait_for_navigation: Wait for a page load after clicking (default True). Set to False for clicks that trigger in-page UI changes like modals, dropdowns, or expanding sections. wait_for: CSS selector to wait for AFTER clicking — use this when the click opens a modal or triggers async UI rendering. The tool waits up to 5 s for the element to appear before returning. wait_ms: Fixed sleep after the click. Discouraged — use wait_until or wait_for_predicate, which finish as soon as the page is ready. wait_for_predicate: JS expression polled (up to 5 s) until it returns truthy, e.g. "!document.querySelector('.spinner')". wait_until: Readiness signal — 'dom_settled' (wait for the DOM to stop changing; the right replacement for wait_ms), 'networkidle', 'load', 'domcontentloaded', 'settle', or 'none'. Defaults to the historical behaviour: settle unless wait_for was given.

Waits that time out do not fail the click — the click already happened. They come back in a warnings list so you can see, for instance, that the modal you expected never opened.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`wait_ms`	No
`selector`	Yes
`wait_for`	No
`wait_until`	No
`wait_for_predicate`	No
`wait_for_navigation`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Sep 16, 2026

addedInput schema / properties / wait_for_predicate

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Wait For Predicate"
+}

addedInput schema / properties / wait_until

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Wait Until"
+}

First observedv0.3.3Aug 5, 2026

TDQS

A5/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 it delivers: it discloses that timed-out waits do not fail the click because the click already happened, that timeout details surface in a warnings list, and that wait_until defaults to 'settle' unless wait_for is given. This gives an agent an accurate model of the tool's runtime behavior.

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?

The description is long but every sentence earns its place. It front-loads the core action, then organizes wait parameters into an Args block with consistent formatting. The added guidance about round-trip costs and timeout behavior is substantive, not filler.

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

Completeness5/5

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

Given the tool's complexity, the 0% schema coverage, and the absence of annotations, the description is remarkably complete. It covers defaults, alternatives, timeout behavior, warnings, and the distinction between navigation waits and UI-rendering waits. The output schema exists, so return-value details are not needed, and nothing material is missing for correct invocation.

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

Parameters5/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 for the bare parameter names, and it does so completely. Every parameter gets a plain-language explanation, a default where relevant, and in most cases usage guidance: wait_ms is discouraged, wait_for_predicate includes a JS example, and wait_until enumerates all accepted readiness signals.

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 description opens with a specific verb and resource: 'Click an element by CSS selector.' It clearly distinguishes this tool from the sibling wait tools by stating that the wait arguments run inside this call, so an agent can immediately tell it apart from wait_for_element, wait_for_predicate, and wait_for_url.

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

Usage Guidelines5/5

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

The description explicitly tells agents when to use the built-in waits instead of a separate wait tool, and even ranks the wait options: prefer wait_for / wait_for_predicate / wait_until over wait_ms. It also gives concrete guidance on setting wait_for_navigation to False for in-page UI changes like modals and dropdowns.

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