SoftGlaze Browser MCP

Overview Schema Source Related Servers Discussions Admin

Click an element

page_click

Moves the mouse to an element and clicks it like a person, targeting it by CSS selector or ARIA role from a page snapshot. Use it to trigger buttons, links, and UI controls inside a profile page.

Instructions

Moves the mouse to an element and clicks it, like a person (the macro engine's click). Target it with a CSS selector or aria/Name[role="button"] from page_snapshot. Asks once per profile.

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": {
      "profileId": "<profileId>",
      "selector": "<selector>"
    },
    "name": "page_click"
  }
}

Input Schema

Name	Required	Description	Default
`selector`	Yes
`profileId`	Yes
`timeoutMs`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Beyond the annotations, it discloses that the interaction is a human-like mouse move plus the macro engine's click path (implying trusted input events rather than DOM dispatch) and that a prompt occurs once per profile. It does not say whether the call waits for navigation or what a failure/timeout looks like.

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?

Two short sentences, front-loaded with the core action, with no filler. The trailing "Asks once per profile" is terse to the point of ambiguity about what exactly is being asked.

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

Completeness3/5

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

For a three-parameter mutation tool with no output schema, it covers the target and the consent nuance but leaves the timeout parameter, navigation-wait behavior, and any return value unaddressed. Adequate to call, but an agent would still be guessing at edge-case behavior.

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 description coverage is 0%, so the description must carry parameter meaning; it explains the selector format (CSS or aria/Name[role="button"]) which is genuinely beyond the bare string schema. It says nothing about timeoutMs, and profileId is only obliquely referenced through "once per profile."

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

Purpose4/5

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

"Moves the mouse to an element and clicks it" gives a concrete verb plus resource, and the clause "(the macro engine's click)" distinguishes it from a synthetic JavaScript click. It never names a sibling, so the differentiation from page_type or page_press_key is only implicit.

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 states where to obtain the selector target (from page_snapshot) and which selector grammar to use, which is exactly the guidance an agent needs before calling. It stops short of any exclusion such as when to prefer page_type for text entry or what to do if the element is absent.

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