Antigravity Desktop MCP

Overview Schema Source Related Servers Discussions Admin

desktop_screenshot

Read-only

Capture Windows screens, displays, windows, or regions and return images with physical-pixel coordinates and frame IDs for accurate click, drag, and scroll projection.

Instructions

Capture the Windows screen, a specific display, a specific window (even overlapped via PrintWindow), a screen/window region, or a foreground-plus-related-windows bundle. Returns the image directly plus physical-pixel coordinate metadata and a frame_id for accurate click/drag/scroll projection.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "desktop_screenshot"
  }
}

Input Schema

Name	Required	Description	Default
`clip`	No	Clip region to virtual desktop / window bounds instead of failing.
`scale`	No
`format`	No		png
`region`	No	Rectangular crop { x, y, width, height }.
`stable`	No
`window`	No	Window handle (hwnd from desktop_windows) to capture.
`display`	No	0 for primary monitor, 1..N for secondary monitors, or "all" for the entire virtual desktop.
`quality`	No
`surface`	No		window
`captures`	No	Set "related" to capture related owned dialogs/tool windows of `window`.	single
`save_path`	No	Optional local file path to copy the screenshot to.
`settle_ms`	No
`max_related`	No
`region_space`	No		screen
`stability_ms`	No
`require_window`	No	Refuse instead of falling back to screen capture if window cannot render.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds valuable behavioral context beyond that: it discloses the return payload (image plus physical-pixel coordinate metadata and a frame_id) and notes that overlapped windows can be captured via PrintWindow. It does not describe failure modes or the clip/require_window fallback semantics, which are only in the schema.

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?

Two sentences, densely packed with zero wasted words. The capture modes come first, the return-value contract second, and the frame_id mechanism is appropriately front-loaded.

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 16-parameter screenshot tool with no output schema, the description is fairly complete: it covers every capture mode and explicitly describes what is returned (image, coordinate metadata, frame_id). It falls short of a 5 because several parameters (stability, settle timing, scale, format) receive no explanation, leaving the agent dependent on the partially documented schema.

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 only 44% across 16 parameters, so the description must carry more weight. It adds meaning for the high-level capture modes (window, display, region, related bundle) but leaves many parameters—clip, scale, format, quality, stable, settle_ms, stability_ms—undocumented in both description and schema. The partial coverage is enough to be viable but not 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 opens with a specific verb+resource ('Capture the Windows screen') and then enumerates every capture mode: full screen, specific display, specific window (including overlapped windows via PrintWindow), region, and related-window bundles. An agent can immediately distinguish this from desktop_windows (which enumerates windows) or desktop_click (which acts on coordinates).

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?

The enumeration of capture modes implicitly tells the agent when each mode is applicable, and the mention of a `frame_id` for 'accurate click/drag/scroll projection' clearly links this tool to the click/drag siblings. However, there is no explicit 'use this instead of X' statement or any when-not-to-use guidance.

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

Deploy Server