Skip to main content
Glama
munimtechnologies

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Screenshot

screenshot
Read-onlyIdempotent

Capture an app window or display as an image to verify outcomes, inspect canvas/video, and map image pixels to click or hover coordinates.

Instructions

Capture an app's largest window, or a whole display, as an image. The result text states the capture's screen origin and pixels-per-point so an image pixel can be converted into click or hover coordinates. Prefer get_app_state for interaction, which is cheaper and returns clickable element ids; use screenshot to verify an outcome or to see content the accessibility tree cannot describe (canvas, video, custom drawing), and zoom to read small text. Read-only; the captured window is not raised or focused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoApp name, bundle id, or pid exactly as reported by list_apps. Captures that app's largest window. Provide either app or display, or "frontmost" for the app the user is looking at
formatNoImage encoding (default png). Use jpeg for live remote viewing.
displayNo0-based display index from list_displays. Captures the whole display instead of an app window.
qualityNoJPEG quality from 1 to 100 (default 55). Ignored for png. Raise it when small text must stay sharp.
max_widthNoDownscale the image to this width in pixels (default 1400). Lower it to save tokens.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.2
    • changedInput schema / properties / app / description
      Previous value: -"App name, bundle id, or pid exactly as reported by list_apps. Captures that app's largest window. Provide either app or display."New value: +"App name, bundle id, or pid exactly as reported by list_apps. Captures that app's largest window. Provide either app or display, or \"frontmost\" for the app the user is looking at"
    • addedInput schema / properties / quality
      Added value: +{
+  "description": "JPEG quality from 1 to 100 (default 55). Ignored for png. Raise it when small text must stay sharp.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
  2. Changed3 schema fields changedv0.3.1
    • changedInput schema / properties / app / description
      Previous value: -"App name, bundle id, or pid"New value: +"App name, bundle id, or pid exactly as reported by list_apps. Captures that app's largest window. Provide either app or display."
    • changedInput schema / properties / display / description
      Previous value: -"Capture a whole display by index (see list_displays) instead of an app window"New value: +"0-based display index from list_displays. Captures the whole display instead of an app window."
    • changedInput schema / properties / max_width / description
      Previous value: -"Downscale to this width in pixels (default 1400)"New value: +"Downscale the image to this width in pixels (default 1400). Lower it to save tokens."
  3. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds traits they do not cover: the captured window is not raised or focused, and the result text carries screen origin plus pixels-per-point so image pixels convert to click/hover coordinates. That is genuine extra behavioral context beyond the structured hints.

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 densely-packed sentences with the primary action, the alternative tool, and the side-effect disclosure front-loaded in that order. No filler and every clause carries actionable information.

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 correctly compensates by explaining the result text's coordinate-conversion data. Combined with the full schema for parameters and annotations for the safety profile, an agent has everything needed to call and interpret this tool.

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 description coverage is 100%, so the schema already documents app/display/format/quality/max_width including defaults and valid values; that establishes the baseline of 3. The description adds only the loose hint that zoom helps read small text (related to quality/max_width) and otherwise does not extend parameter meaning.

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 and resource: capture an app's largest window or a whole display as an image. It also names the output semantics (screen origin, pixels-per-point) and explicitly distinguishes itself from sibling get_app_state and zoom, so an agent can pick it 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 Guidelines5/5

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

Explicitly says to prefer get_app_state for interaction because it is cheaper and returns clickable element ids, and defines exactly when screenshot is the right choice: verifying an outcome or seeing content the accessibility tree cannot describe, using zoom for small text. This is a full when/when-not/alternatives routing.

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