Skip to main content
Glama
yfe404

proxy-mcp

by yfe404
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

humanizer_click

Click page elements by CSS/XPath, role+name, text, label, or coordinates. Automatically waits for locators to be visible and actionable, avoiding fragile clicks.

Instructions

Click an element. Pass one of: selector (CSS/XPath), role + optional name, text, label, or raw x+y coords as fallback. Locator-based calls auto-wait for visible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoX coordinate fallback when no locator is given
yNoY coordinate fallback when no locator is given
nameNoAccessible name; used with role (e.g. 'Sign in')
roleNoARIA role (e.g. 'button', 'link', 'textbox')
textNoVisible text to match (e.g. 'Accept cookies')
labelNoForm-field label text (e.g. 'Email address')
buttonNoMouse button (default: left)left
selectorNoCSS or XPath selector (e.g. 'button.submit', '//button[@id="go"]')
target_idYesTarget ID from interceptor_browser_launch
timeout_msNoMax ms to wait for locator to be visible + actionable (default: 15000)
click_countNoNumber of clicks (default: 1, use 2 for double-click)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.5.3
    • changedInput schema / properties / target_id / description
      Previous value: -"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"New value: +"Target ID from interceptor_browser_launch"
  2. Changed1 schema field changedv3.3.2
    • changedInput schema / properties / target_id / description
      Previous value: -"Browser target ID from interceptor_browser_launch"New value: +"Target ID from interceptor_browser_launch or interceptor_camoufox_launch"
  3. Changed10 schema fields changedv2.3.0
    • addedInput schema / properties / label
      Added value: +{
+  "description": "Form-field label text (e.g. 'Email address')",
+  "type": "string"
+}
    • removedInput schema / properties / move_duration_ms
      Removed value: -{
-  "default": 600,
-  "description": "Base duration for mouse movement (default: 600)",
-  "type": "number"
-}
    • addedInput schema / properties / name
      Added value: +{
+  "description": "Accessible name; used with role (e.g. 'Sign in')",
+  "type": "string"
+}
    • addedInput schema / properties / role
      Added value: +{
+  "description": "ARIA role (e.g. 'button', 'link', 'textbox')",
+  "type": "string"
+}
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector to click (resolved via getBoundingClientRect)"New value: +"CSS or XPath selector (e.g. 'button.submit', '//button[@id=\"go\"]')"
    • changedInput schema / properties / target_id / description
      Previous value: -"Chrome target ID from interceptor_chrome_launch"New value: +"Browser target ID from interceptor_browser_launch"
    • addedInput schema / properties / text
      Added value: +{
+  "description": "Visible text to match (e.g. 'Accept cookies')",
+  "type": "string"
+}
    • addedInput schema / properties / timeout_ms
      Added value: +{
+  "default": 15000,
+  "description": "Max ms to wait for locator to be visible + actionable (default: 15000)",
+  "type": "number"
+}
    • changedInput schema / properties / x / description
      Previous value: -"X coordinate (used if selector is not provided)"New value: +"X coordinate fallback when no locator is given"
    • changedInput schema / properties / y / description
      Previous value: -"Y coordinate (used if selector is not provided)"New value: +"Y coordinate fallback when no locator is given"
  4. Addedv1.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, the description carries the behavioral burden, and it adds a genuinely useful trait: locator-based calls auto-wait for visibility while coordinate calls are a fallback. It doesn't describe timeout failure behavior or the 'humanized' nature implied by the name, but it does disclose the most important runtime distinction for an agent to invoke it correctly.

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?

Two short sentences, front-loaded with the action, and every clause contributes information about target selection or waiting behavior. There is no duplication of schema fields or filler.

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 an 11-parameter tool with no output schema, the combination of the description and the fully documented schema is sufficient to invoke the tool: target_id, timeout, button, click_count, and locator options are all described. The main remaining gap is non-critical behavioral detail (failure/return behavior), so it is complete rather than exhaustive.

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 coverage is 100%, so the baseline is 3, but the description adds real grouping semantics beyond the field descriptions: 'pass one of' establishes mutual exclusivity, 'role + optional name' defines a compound locator, and 'raw x+y coords as fallback' states precedence. This makes the parameter surface easier to reason about than the flat schema alone.

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 names a concrete action and object ('Click an element') and enumerates the accepted targeting strategies. That verb+resource statement is enough to tell it apart from sibling humanizer_type/move/scroll tools, and it is not a tautology.

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?

The intended use is explicit: when a click is required, pass one of the listed locator forms or fall back to coordinates. It doesn't name sibling alternatives or exclusion cases, but the action is unambiguous and the locator-selection guidance is practical, meeting the 'clear context, no exclusions' bar.

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