Skip to main content
Glama
agy_computer_use.mcp_server

agy_computer_use.mcp_server

by orakulzero

cu_bg_capture

Captures occluded or offscreen Windows by handle, using PrintWindow(PW_RENDERFULLCONTENT) with WM_PRINT fallback and optional synthetic fallback for headless or zero-RGB cases.

Instructions

Capture occluded or offscreen window surface via PrintWindow(PW_RENDERFULLCONTENT) with WM_PRINT fallback.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hwnd": "<hwnd>"
    },
    "name": "cu_bg_capture"
  }
}

Input Schema

NameRequiredDescriptionDefault
hwndYesTarget window handle (HWND).
desktop_nameNoDesktop session name (default 'Default').
fallback_seedNoSynthetic fallback seed if headless or zero RGB.
fallback_widthNoSynthetic fallback width in pixels.
fallback_heightNoSynthetic fallback height in pixels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose the capture mechanism (PrintWindow with PW_RENDERFULLCONTENT and WM_PRINT fallback), which is genuine technical context. However it never states that this is a non-destructive read, nor explains the synthetic-fallback path implied by the fallback_* parameters.

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?

A single front-loaded sentence with no filler; the distinguishing condition appears before the implementation detail. It is arguably too terse for the amount of behavior left unexplained, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter capture tool with no annotations and no output schema, the description leaves critical gaps: what the tool returns (image bytes, file path, buffer handle), whether it is safe/idempotent, and how the synthetic fallback actually behaves. Those omissions matter more than the mechanism name it does provide.

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 coverage is 100%, so all five parameters are already documented; the baseline is 3. The description adds no format, default, or interaction detail (e.g. that fallback_seed triggers synthetic image generation when the capture is headless or zero-RGB).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (capture) and resource (occluded/offscreen window surface), and the qualifier 'occluded or offscreen' scopes it away from a plain on-screen screenshot tool like cu_capture_som. It stops short of naming the differentiating sibling explicitly.

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

Usage Guidelines3/5

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

'occluded or offscreen' implies the usage condition, but there is no explicit when-to-use vs cu_capture_som, no prerequisites (must be a valid HWND on the given desktop), and no statement of when not to use it.

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