Skip to main content
Glama
Sign In
Seleniumboot MCP

Seleniumboot MCP

by seleniumboot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

click

Triggers a web page element using CSS, XPath, ID, name, tag, class, or link selectors to activate buttons, links, and interactive controls during browser automation.

Instructions

Click on an element.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "selector": "<selector>"
    },
    "name": "click"
  }
}

Input Schema

NameRequiredDescriptionDefault
byNoStrategycss
timeoutNoSeconds
selectorYesLocator value

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.9.3
    • changedInput schema / properties / by / description
      Previous value: -"Locator strategy"New value: +"Strategy"
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector, XPath, or other locator value"New value: +"Locator value"
    • changedInput schema / properties / timeout / description
      Previous value: -"Wait timeout in seconds"New value: +"Seconds"
  2. First observedv0.3.7

TDQS

C2.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and does almost nothing with it. It does not say whether the click scrolls into view, blocks until actionable, what happens on a missing element, or whether the action is waited on per the timeout parameter. The only signal is the implicit fact that it mutates page state, which the verb already conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five words is maximally concise with zero redundancy, and the verb is front-loaded. But the terseness is under-specification rather than efficiency: for an interactive primitive with a 3-parameter schema, the brief does not give the agent enough to call it confidently.

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

Completeness2/5

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

With no annotations and no output schema, and a sibling set full of overlapping interaction tools (hover, type_text, send_keys, wait_for_element), the description is too thin. It omits the waiting semantics tied to the timeout parameter and any failure behavior, leaving an agent to discover these by trial.

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 coverage is 100%, so the selector, by-strategy enum, and timeout are already documented in structured fields. The description adds no meaning beyond the schema — nothing about how selector is interpreted under each by-strategy or what timeout governs. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb ("click") and target ("an element"), which is enough to identify the action. However, it gives no scope boundary or differentiation from nearby interaction siblings such as hover, type_text, or send_keys, so the agent must infer that this is the plain mouse-click primitive.

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?

"Click on an element" offers no when-to-use guidance, no prerequisites (element must exist/be visible, whether it implicitly waits), and no mention of alternatives like send_keys or hover. The agent must guess whether click waits for the element or fails fast.

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