Skip to main content
Glama
bigduu

Nova

by bigduu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

left_click

Perform a grounded left click in the latest capture’s pixel space, using OCR-center or visual coordinates, and report which grounding route was used.

Instructions

Last-resort grounded left click in the most recent capture's pixel space. Pass source=ocr_center when x/y came from focused OCR; otherwise source=visual_coordinate (the default) means a focused screenshot/zoom. The result reports that route.

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
sourceNoGrounding source for route reporting. Use `ocr_center` only for a center returned by the immediately preceding OCR result. Omit/default `visual_coordinate` for a focused screenshot/zoom coordinate.
backgroundNoDeliver in the background to the captured window's process (native apps only; browsers/Electron ignore it). Default false = foreground.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.0
    • addedInput schema / $defs
      Added value: +{
+  "CoordinateActionSource": {
+    "oneOf": [
+      {
+        "const": "ocr_center",
+        "description": "Center returned by the immediately preceding focused OCR result.",
+        "type": "string"
+      },
+      {
+        "const": "visual_coordinate",
+        "description": "Coordinate read from the immediately preceding focused screenshot/zoom.",
+        "type": "string"
+      }
+    ]
+  }
+}
    • addedInput schema / properties / source
      Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/CoordinateActionSource"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Grounding source for route reporting. Use `ocr_center` only for a center\nreturned by the immediately preceding OCR result. Omit/default\n`visual_coordinate` for a focused screenshot/zoom coordinate."
+}
    • removedInput schema / title
      Removed value: -"ClickParams"
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the operating space ('most recent capture's pixel space') and that the result reports the grounding route, which is real behavioral context. But it says nothing about side effects of a click (focus changes, foreground vs background behavior), failure modes when no capture exists, or permissions.

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?

Three short sentences, front-loaded with the core action and operating space before the parameter-routing guidance. Efficient, though the source explanation is dense and partly duplicates the schema.

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 4-parameter, no-annotation, no-output-schema action tool, the definition covers purpose, grounding source, and route reporting, but omits background behavior, click side effects, and what happens when no capture is available. Adequate but with clear gaps.

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 50%. The description explains source=ocr_center vs source=visual_coordinate, but that largely mirrors the schema's own source description, so it adds little beyond structured data. It adds no meaning for x/y (undocumented in both) and does not touch the background parameter, so it only partially compensates for the coverage gap.

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?

States a specific verb and resource: a left click executed in the most recent capture's pixel space, with the 'last-resort/grounded' framing signaling it is a fallback rather than a primary interaction. It implicitly separates itself from sibling ax_click/click_mark/chrome_* tools, but never names them, so the differentiation is inferred rather than explicit.

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?

'Last-resort' gives clear ordering context (use only when other interaction paths fail), and the source guidance tells the agent how to pick the correct grounding route. However, no alternatives are named (e.g. ax_click, click_mark, chrome_click) and there is no explicit when-not condition.

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