Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

capture_network_editor

Capture a screenshot of the network editor to visually confirm node wiring. Optionally frame a given node path and save the image to disk for inspection.

Instructions

Capture a screenshot of the network editor.

With node_path the view is put on that node at once (no animated flight), and the reply says what the frame shows: visible_bounds, node_bounds and node_in_view, all in network space.

The image is written to disk only; open output_path with your file reader to look at it. Prefer get_node_info or list_children for inspecting node connections unless visual confirmation of wiring is genuinely needed.

Args: output_path: Image file path. Default: a new PNG in the temp dir. node_path: Node path to frame before capture.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
node_pathNo
output_pathNo

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/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and mostly delivers: it discloses the write-to-disk side effect ('image is written to disk only; open output_path with your file reader'), the non-animated framing of node_path, and the fields the reply returns (visible_bounds, node_bounds, node_in_view in network space). It omits failure/error behavior and any dependency (e.g. needing a live Houdini session), so it falls short of full transparency.

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?

Front-loaded with the core purpose, then engineering details, then the alternative-tool guidance, with an Args block that adds semantics rather than restating names. It is a touch long for a two-parameter tool but every sentence carries information.

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 two-parameter screenshot tool with no output schema and no annotations, the description covers purpose, side effects, output location, the frames the reply reports, and when not to use it. Remaining gaps (error cases, connection prerequisites) are minor and not required to invoke it correctly.

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 description coverage is 0%, so the description must compensate, and it does: output_path is documented with its default ('a new PNG in the temp dir') and node_path with its effect ('Node path to frame before capture'). Both parameters gain meaning beyond the bare anyOf/null schema, though format details (e.g. accepted node path syntax) are absent.

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?

States a specific verb and resource: 'Capture a screenshot of the network editor,' and the node_path framing behavior narrows the scope further. It does not, however, distinguish itself from the closely related sibling capture_screenshot or render_viewport, which an agent could plausibly reach for instead.

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?

Gives explicit routing guidance: 'Prefer get_node_info or list_children for inspecting node connections unless visual confirmation of wiring is genuinely needed.' This names concrete alternatives and the condition that selects them. It stops short of 5 because it never addresses the nearest siblings (capture_screenshot / render_viewport) that overlap in purpose.

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