Skip to main content
Glama

ocr

Idempotent

Recognizes text in a specified screen region or window, matches expected text, and returns screen-absolute coordinates for clicking; saves a screenshot on failure.

Instructions

OCR 识别文本并给屏幕绝对坐标(可直接用于点击)。只对给定 ROI 做(实测整屏 4.1s vs ROI 数十 ms)。

matched_count==0 是「本次没找到」而非「不存在」; save_on_failure 可在没匹配到时留下截图证据。

这是「弱视觉」的主力:验收时绝大多数判断只需要 「屏幕上有没有这几个字、它在哪」。

只对给定的区域做 OCR(实测整屏 2560x1440 要 4.1 秒,而 ROI 通常几十毫秒)—— 这也是同类项目的标配做法。

坐标一律是屏幕绝对坐标,可直接喂给点击;coordinate_space 字段会明说是 screen_absolute,避免「拿裁剪图坐标去点」这个经典坑。

匹配 expected 时的语义(重要): · matched_count == 0 的意思是「本次没找到」, 不等于「游戏里没有」—— 可能界面还没加载、或文字被 OCR 拆成了多个框。返回里的 note 会写明这一点。 · best_match 取的是置信度最高的那条,不是第一条。

Args: region: "x,y,w,h" 屏幕绝对坐标;与 window 二选一。 window: 窗口标题子串;用它定 ROI。 expected: 期望出现的文本;给了就把命中的单独列出来。 match: contains(默认)/ exact / regex。 threshold: 置信度下限,低于它的丢弃(默认 0.3)。 case_sensitive: 文本匹配是否区分大小写。 max_items: 最多返回多少个文本框。 save_on_failure: 给了路径时,若没匹配到就把当时的截图存到这里 (等价 MaaFramework 的 save_on_error)—— 失败要留证据。

Returns: {ok, engine, count, results: [{text, score, box, center, click_point}], texts, matched, matched_count, best_match, click_point, coordinate_space: "screen_absolute", image, ...}

Input Schema

NameRequiredDescriptionDefault
matchNocontains
regionNo
windowNo
expectedNo
max_itemsNo
thresholdNo
case_sensitiveNo
save_on_failureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds real behavior beyond the annotations: cost profile (4.1s full-screen 2560x1440 vs tens of ms for ROI), the critical semantic that matched_count==0 means 'not found this run' rather than 'does not exist', that best_match is highest-confidence rather than first, and that coordinate_space is guaranteed screen_absolute. It also explains the file write implied by readOnlyHint=false via save_on_failure, so description and annotations are consistent.

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?

Front-loaded with the key claim, but the ROI-vs-full-screen point is repeated three times and the 4.1s vs tens-of-ms benchmark is stated twice verbatim, plus the matched_count==0 caveat appears both in prose and again in the 'matching semantics' block. Roughly a third of the text is redundant.

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

Completeness5/5

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

With no output schema, the description fully specifies the return shape (ok/engine/count/results/texts/matched/matched_count/best_match/click_point/coordinate_space/image) and the field semantics that matter. For an 8-parameter, open-world, side-effecting tool, nothing an agent needs to call it correctly is missing.

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 coverage is 0% with no enums and no defaults documented in prose, so the description carries full burden — and it does: it gives the 'x,y,w,h' screen-absolute format for region, the window-title-substring alternative, the three match modes (contains/exact/regex, which the schema does not enumerate as an enum), the threshold 0.3 default, and the failure-screenshot semantics of save_on_failure.

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 verb+resource (OCR recognition of screen text) plus the differentiating output guarantee (screen-absolute coordinates directly usable for clicking). An agent can immediately distinguish this from siblings like capture_screen, wait_for, or verify_state.

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?

Explicitly frames the tool as the 'weak vision' workhorse and gives the decision rule — most acceptance checks only need 'are these characters on screen and where'. It also names the region-vs-window choice and the save_on_failure option. It stops short of naming sibling tools or stating when NOT to use it (e.g. when pixel-level visual comparison is needed).

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