Skip to main content
Glama
faze79

WpfVisualTreeMcp

by faze79
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

wpf_capture_screenshot

Capture a screenshot of the WPF window or a specific element. Returns an image that can be visually analyzed. Use element_handle to capture a specific element, or omit for the entire window.

Instructions

Capture a screenshot of the WPF window or a specific element. Returns an image that can be visually analyzed. Use element_handle to capture a specific element, or omit for the entire window. mode='auto' (default) uses screen capture when native HwndHost content is present, otherwise render; the response states the mode. Native content needs a visible unobstructed desktop. Explicit mode='render' rejects native content instead of returning a blank image, and re-renders the visual off-screen — works even if the window is covered, but CANNOT see open Popups, ComboBox dropdowns, context menus or tooltips. mode='screen' captures the actual on-screen pixels (GDI) and DOES include them — use it right after clicking something that opened a popup/menu; requires the window to be visible and unobstructed. Set full_content=true with render mode to capture all content in a ScrollViewer, including unscrolled and virtualized content; the original scroll position is restored.

Input Schema

NameRequiredDescriptionDefault
modeNoauto
max_widthNo
max_heightNo
full_contentNo
element_handleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.1
    • changedInput schema / properties / mode / default
      Previous value: -"render"New value: +"auto"
  2. Changed1 schema field changedv0.12.1
    • addedInput schema / properties / full_content
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does: it names a real failure mode (render returns a blank image for native content, so explicit render 'rejects native content'), lists exactly what render cannot see (popups, ComboBox dropdowns, context menus, tooltips), notes screen mode uses GDI on actual pixels, and discloses the side effect that full_content restores the original scroll position.

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?

Purpose is front-loaded in the first sentence, then mode behavior in decreasing order of importance. Despite being a long paragraph, nearly every clause adds decision-relevant information (which mode, what each can and cannot see, the scroll-restore side effect); nothing is filler.

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?

With no output schema and no annotations, the description usefully states that it returns an image for visual analysis and that the response reports the mode used, which covers the return-value gap. The remaining hole is how max_width/max_height affect output size/aspect, which matters for an agent consuming the image.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema has no descriptions, so the description must compensate. It gives real semantics for mode (auto/render/screen with distinct behaviors), element_handle ('omit for the entire window'), and full_content (requires render mode, includes virtualized content). max_width and max_height are never mentioned, leaving their scaling behavior undocumented.

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 a screenshot of the WPF window or a specific element') and immediately delimits scope with 'or a specific element... or omit for the entire window'. An agent can distinguish this from tree/property inspection siblings like wpf_snapshot or wpf_get_visual_tree without opening the 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 routes between the three modes: 'use it right after clicking something that opened a popup/menu' for screen, render when the window is covered, and auto as the default that picks based on native HwndHost content. It also states the preconditions for each (visible unobstructed desktop) so the agent can decide rather than guess.

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