Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

capture_screenshot

Capture a screenshot of the viewport or a specific pane tab.

Instructions

Capture a screenshot of the viewport or a specific pane tab.

The image is written to disk only; open output_path with your file reader to look at it. Prefer get_geometry_info, get_node_info or get_scene_summary unless visual confirmation is genuinely needed. A Scene Viewer capture names the network it shows (viewer_network); viewer_note says when that is a DOP network, drawn as the simulation's objects rather than the SOP display; visible_objects_note, when the viewport's Visible Objects pattern leaves out the object the viewer is in, so the frame shows none of it.

Args: output_path: Image file path. Default: a new PNG in the temp dir. pane_name: Pane tab name. settle_seconds: Wait this long before capturing, without blocking Houdini, so a Karma viewport can converge after a change. Use this instead of a shell sleep between calls. Capped at 120.

Input Schema

NameRequiredDescriptionDefault
pane_nameNo
output_pathNo
settle_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / output_path / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / output_path / default
      Added value: +null
    • removedInput schema / properties / output_path / type
      Removed value: -"string"
    • removedInput schema / required
      Removed value: -[
-  "output_path"
-]
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does: it discloses the disk-write side effect and that the agent must open output_path to see the image, explains that settle_seconds waits without blocking Houdini (use instead of shell sleep) and is capped at 120, and pre-announces the returned viewer_network / viewer_note / visible_objects_note fields.

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?

The lead sentence and the 'prefer X unless Y' sentence are front-loaded and waste-free. The middle paragraph on viewer_network / viewer_note / visible_objects_note is dense and slightly cryptic, but it is conditional context rather than 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?

For a zero-annotation, no-output-schema, 3-param capture tool, the description covers target, side effects, return metadata, parameter defaults and timing behavior. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 0%, so the Args section is essential and complete: output_path default (new PNG in temp dir), pane_name meaning, and settle_seconds with its rationale (Karma convergence), non-blocking semantics, and hard cap. All three parameters gain meaning beyond the bare schema titles.

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 viewport or a specific pane tab'), scoping it apart from render_viewport, render_quad_view and capture_network_editor. An agent immediately knows what it produces and what it targets.

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 names preferred alternatives ('Prefer get_geometry_info, get_node_info or get_scene_summary unless visual confirmation is genuinely needed'), giving both the when-not and the substitute tools. This is the strongest form of routing guidance.

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