Skip to main content
Glama

screenshot

Read-only

Capture the screen, a window, or a selected region to inspect UI state; use zoom to view small text at original resolution.

Instructions

截图。所有坐标都以不带 zoom 的截图为准。region 截局部;zoom=true 按原始分辨率截(只用来看清小字)。

Input Schema

NameRequiredDescriptionDefault
zoomNo
regionNo[x0,y0,x1,y1]
windowNo窗口标题或应用名的一部分,或 windows 返回的 hwnd;不填就是前台窗口

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: all coordinates are defined against the non-zoom screenshot, so a zoomed capture must not be used for coordinate reference, and zoom is explicitly view-only for small text. That is exactly the kind of trap an agent would otherwise fall into.

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?

Three short clauses, zero redundancy, with the most error-prone constraint (coordinate reference frame) front-loaded. Every sentence earns its place.

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 a three-parameter, all-optional capture tool with no output schema, the description covers the risky semantics: coordinate frame, region behavior, and zoom's limited purpose. Only the default capture behavior when window is omitted is left to the schema, which handles it.

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 67%, with region and window already documented in the schema. The description compensates for the remaining gap by defining the coordinate reference frame (non-zoom screenshot), clarifying that region means partial capture, and pinning down zoom as original-resolution viewing only. This adds meaning well beyond the bare types.

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?

The description states a concrete verb+resource ('截图' / screenshot) and immediately qualifies scope with 'region 截局部'. It is clear what the tool does, but it never contrasts itself with nearby state-reading siblings like observe, find, or check, so the agent must infer when a screenshot is the right call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives conditional guidance for the zoom and region parameters ('zoom=true 按原始分辨率截(只用来看清小字)'), which is real when-to-use advice at the parameter level. However, there is no statement about when this tool should be preferred over observe/windows/status, and no exclusions or prerequisites.

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