Skip to main content
Glama

click

Select and invoke one or more elements matching a CSS or text selector. Supports nth, all visible matches, parent scoping, scrolling, and visibility conditions.

Instructions

Click one or more elements matching a selector.

This is the primary element-clicking tool. The selector may be a CSS selector or SeleniumBase text-matching selector such as 'a:contains("Sign in")'.

Args: selector: Target CSS selector or text-matching selector. nth: Click only the Nth matching element, using 1-based indexing. Takes priority over all_matches. all_matches: Click every currently visible matching element, in order. Ignored when nth is provided. only_if_visible: Attempt the click only when the target is already visible. Does not wait for the element to become visible. parent_selector: Restrict the nested lookup to a parent element. Useful for elements inside iframes or nested containers when supported by SeleniumBase. timeout: Seconds to wait for a basic click when no specialized mode is selected. Defaults to 7 seconds. scroll: Scroll the target into view before clicking.

Tool selection: - Click one matching element -> basic click. - Click a specific matching occurrence -> set nth. - Click every visible match -> set all_matches=True. - Click only when already visible -> set only_if_visible=True. - Click an element nested inside another element -> set parent_selector.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nthNo
scrollNo
timeoutNo
selectorYes
all_matchesNo
only_if_visibleNo
parent_selectorNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv4.53.7
    • removedInput schema / properties / timeout / anyOf
      Removed value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / timeout / type
      Added value: +"number"
  2. Changed1 schema field changedv4.53.2
    • changedInput schema / properties / timeout / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "type": "integer"
      +  },
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  3. Changed5 schema fields changedv1.0.1
    • addedInput schema / properties / all_matches
      Added value: +{
      +  "default": false,
      +  "title": "All Matches",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / nth
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Nth"
      +}
    • addedInput schema / properties / only_if_visible
      Added value: +{
      +  "default": false,
      +  "title": "Only If Visible",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / parent_selector
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Parent Selector"
      +}
    • changedInput schema / properties / timeout / default
      Previous value: -nullNew value: +7
  4. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: nth takes priority over all_matches, all_matches is ignored when nth is set, only_if_visible does not wait for visibility, and timeout defaults to 7 seconds. This is substantive, though it does not describe failure behavior or what happens when no element matches.

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?

Well-structured with Args and Tool selection sections. The Tool selection list somewhat recaps the Args details, but it serves as a useful decision aid. Overall, the description is appropriately sized for the complexity of the tool and information is easy to scan.

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?

Given an output schema exists, return-value details are not required. The description covers selector syntax, parameter precedence, timeout behavior, visibility handling, and parent scoping. It is nearly complete, but it omits behavior for zero matching elements and any potential side effects of clicking.

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 fully compensates by explaining every parameter in the Args section. The inclusion of a concrete selector example ('a:contains("Sign in")') adds valuable syntax guidance beyond the schema's bare property titles.

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 action ('Click one or more elements matching a selector') and identifies itself as the primary element-clicking tool. This clearly distinguishes it from sibling tools like hover_with_action and gives immediate clarity about its resource and scope.

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?

Provides an explicit 'Tool selection' section that maps use cases to parameter choices (basic click, nth, all_matches, only_if_visible, parent_selector). It does not explicitly contrast with sibling tools, but the guidance is concrete and actionable for choosing the right invocation mode.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seleniumbase/SeleniumBase'

If you have feedback or need assistance with the MCP directory API, please join our Discord server