Skip to main content
Glama
IlyasKhallouki

hypruse

by IlyasKhallouki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

screenshot

Read-only

Capture the focused monitor, a window, or a region on a Wayland desktop and return the image plus geometry/scale metadata for pixel-to-global mapping.

Instructions

Capture the focused monitor, a window (window: "active" or an address from desktop, cheapest for reading one app), or a region "x,y,WxH". Returns the image (or a file path to read) + JSON metadata with geometry/scale for pixel→global mapping. A window on a hidden workspace or under another window is still captured as itself (metadata source "window"; without grim -T a shown window is cropped from the screen, source "screen", and a hidden one is refused); visible says whether the compositor draws it, and a hidden one may show how it last looked (many apps stop drawing while hidden). Window captures are refused while the session is locked. scale 0.1-1.0: optional deliberate downscale, usually leave unset. stable=true waits (up to 2s) until two consecutive frames match, so a capture right after an action is not taken mid-animation; metadata gains stable. Captures are fast JPEG by default; lossless=true returns PNG for pixel-exact work. Before clicking a small control, follow with zoom at the estimated point.

Input Schema

NameRequiredDescriptionDefault
scaleNo
regionNo
stableNo
windowNo
losslessNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.4
  2. Removedv0.6.0
  3. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / lossless
      Added value: +{
+  "default": false,
+  "title": "Lossless",
+  "type": "boolean"
+}
  4. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / stable
      Added value: +{
+  "default": false,
+  "title": "Stable",
+  "type": "boolean"
+}
  5. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, so safety is covered, yet the description adds substantial non-obvious behavior: hidden-workspace and occlusion handling, the `source` window-vs-screen distinction, refusal while the session is locked, the 2s `stable` two-frame wait, and JPEG-vs-PNG defaults. This is exactly the operational context annotations cannot carry.

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?

It is front-loaded on the capture modes, which is good, but the middle becomes a dense thicket of parentheticals and implementation detail (grim -T, compositor internals) that is harder to parse than an agent needs. Several clauses could be tightened without losing actionable meaning.

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 5-parameter, zero-coverage schema the description is comprehensive: capture modes, failure conditions (locked session, hidden-window refusal), timing behavior, and output format are all addressed. Since an output schema exists it is not obligated to detail returns, and it stays appropriately brief on that front.

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 description coverage is 0% (only titles and defaults), so the description must carry all five parameters — and it does: `window` ('active' or a desktop address), `region` ('x,y,WxH'), `scale` (0.1-1.0, usually unset), `stable` (two-frame wait), and `lossless` (PNG). Every parameter gets meaning the bare schema lacks.

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?

The description states a specific verb (capture) and enumerates the three selectable resources (focused monitor, window, region) with the exact syntax for each. It also routes to the `zoom` sibling for the follow-up case, so an agent can distinguish it from adjacent tools without opening a schema.

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 gives real selection guidance: window is flagged as 'cheapest for reading one app', and the closing sentence tells the agent to follow with `zoom` before clicking small controls. What is missing is explicit when-not-to-use framing or named alternatives for full-screen vs region tradeoffs beyond the cost hint.

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