Skip to main content
Glama
munimtechnologies

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Screenshot

screenshot
Read-onlyIdempotent

Capture an app's largest window or entire display as an image to verify outcomes and view content that accessibility trees cannot describe, including canvas, video, and custom drawings.

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.
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.
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. 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."
  2. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that the captured window is not raised or focused, and explains that the result text includes screen origin and pixels-per-point for coordinate conversion. These are meaningful behavioral details not present in the annotations.

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?

Every sentence adds distinct value: the core action, coordinate mapping details, usage guidance with alternatives, and side-effect disclosure. The description is compact, front-loaded, and contains no filler.

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?

Given the annotations, complete parameter schema, and sibling context, the description covers all essential behavioral and usage information. It explains what the result contains, how to interpret image pixels, and when to prefer other tools, making it sufficient for reliable invocation.

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?

The input schema already documents all four parameters thoroughly, including app vs. display semantics, format defaults, and max_width purposes. The tool description mostly restates app and display behavior, so it adds little beyond the schema, but the schema coverage is complete.

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 clearly states the primary action: capturing an app's largest window or a whole display as an image. It also distinguishes this tool from get_app_state by explaining that screenshot is for verifying outcomes or viewing content the accessibility tree cannot describe.

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?

The description gives explicit guidance: prefer get_app_state for interaction because it is cheaper and returns clickable element ids, use screenshot for verification or non-accessibility-tree content, and use zoom to read small text. This directly helps an agent choose the correct tool among siblings.

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