Skip to main content
Glama

tool_skyshot

Read a window's UI as a text tree, then diff each capture to show only changes. Cheaper than screenshots and names elements hit-testing misses, like inputs in Chromium pages.

Instructions

Read a window's UI as a compact TEXT tree instead of a screenshot — far cheaper than an image, and it names elements a hit-test cannot reach (e.g. an input inside a Chromium page, which element_at_point reports only as the enclosing 'document'). Each line is '{index} {indent}{role} {name}{Value: ...}{(state)}'. Every shot after the first is a DIFF against the previous one: unchanged lines are omitted, '' marks a changed line, '+' an added one, and removed indices are summarised as ranges. So a second call is usually a few lines, not the whole tree — an unchanged window costs about 100 characters. INDEXES ARE POSITIONAL: each shot numbers the tree it just walked, so a number is only valid against the shot that printed it. '' and '+' lines carry THIS shot's index and may be acted on; unchanged lines carry no index, so reaching one needs disable_diff=true for a full render. An index read from an older shot is not a durable handle — re-check it with a fresh shot before acting if the window may have changed. The result includes shot_key (the window the diff baseline belongs to — the baseline lives server-side and outlives your session, so this is how you confirm it was taken against the window you meant). Pass include_offscreen=true to include elements that are scrolled out or hidden. The result reports minimized, because a minimized window does not always expose its full tree (measured on Edge and on Explorer; Notepad was unaffected) — so a small tree is not proof that the window is empty, and include_offscreen does not recover it. Restore the window once and read again if the result matters. NOTE: this reads element VALUES, so the text can contain whatever is on screen in that window. Read-only — no input injection, no focus change; safe to call while the user works.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hwndNo
titleNo
max_depthNo
max_nodesNo
disable_diffNo
include_valuesNo
include_offscreenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so unusually well: read-only with no input injection or focus change, server-side diff baseline that outlives the session, positional indexes valid only against the shot that printed them, and the minimized-window caveat (measured behavior on Edge/Explorer). It even warns the text may contain whatever is on screen.

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?

Long (~300 words) but front-loaded with the core purpose and diff semantics, and nearly every sentence carries non-derivable information given zero annotations and zero schema docs. The index-validity point is stated twice, which is the main redundancy.

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?

For a tool with an output schema, the description needn't restate return shape, yet it usefully explains the line format, shot_key, minimized, and diff markers. Combined with the schema and output schema, an agent has everything needed to call it correctly and interpret the result.

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 description coverage is 0% across 7 parameters, so the description must compensate: it explains disable_diff (full render), include_offscreen (scrolled-out/hidden elements and its limits), and include_values implicitly via the VALUES note. hwnd, title, max_depth, and max_nodes remain undefined anywhere, which keeps this below 5, but the added meaning for the behaviorally tricky flags is substantial.

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 ('Read a window's UI as a compact TEXT tree') and immediately differentiates it from tool_capture_window by contrast with 'a screenshot' and from element_at_point by naming what a hit-test cannot reach. An agent can place this tool among its 18 siblings without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes against alternatives: use this instead of an image because it is cheaper, and it reaches elements that element_at_point reports only as the enclosing 'document'. It also states the condition selecting disable_diff=true and tells the agent to re-check with a fresh shot before acting when the window may have changed.

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