Skip to main content
Glama
Sign In
tdmcp

tdmcp

by lucasmaher-hash
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Preview a TOP

get_preview
Read-only

Capture a TOP node's current output as an inline PNG to see what was created, or use a low-res RGBA grid to quickly check its state and color—all without modifying the network.

Instructions

Capture a TOP node's current output as an inline PNG image so you can see what was created — read-only, it creates and modifies nothing. Returns the image (scaled to width×height) plus a caption with the node path and actual dimensions; only TOPs can be previewed (CHOP/SOP/etc. have no image). For a much cheaper check (is it alive / roughly what colour?) pass sample_grid=N to get an N×N grid of RGBA samples + per-channel stats as JSON instead of an image.

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": "get_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
widthNoWidth of the captured preview image in pixels (1–4096; default 640).
heightNoHeight of the captured preview image in pixels (1–4096; default 360).
job_idNoCollect a previously deferred capture (from a delay_frames call) by its job_id.
node_pathNoPath of the TOP node to capture. Required unless collecting a deferred job by job_id.
pre_pulsesNoParameters to pulse in the SAME frame immediately before capturing — e.g. reset a feedback loop or fire a timer so a transient is actually visible. All targets are validated before any fires (all-or-nothing).
sample_gridNoWhen set (2–16), return a lightweight N×N grid of RGBA samples + per-channel min/max/mean as JSON instead of an image — 10–50× cheaper. Use this when you only need to know whether the output is alive / roughly what colour it is, not its spatial detail.
delay_framesNoDefer the capture by N frames (to catch an event that appears a few frames after a pulse). Returns a job_id + wait_ms instead of the image; call get_preview again with that job_id to collect the result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.1

TDQS

A4.3/5.0
Behavior5/5

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

While annotations already declare readOnlyHint=true, the description adds behavioral specifics: 'it creates and modifies nothing', and details the return format (image with caption, RGBA samples with per-channel stats). This goes well beyond the simple safety hints and sets expectations for output.

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?

The description is three sentences with each serving a purpose: main action, output format/limitation, and cheaper alternative. It is front-loaded with the core purpose and avoids fluff.

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

Completeness3/5

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

The description thoroughly explains the direct image mode and sample_grid mode, but omits key usage paths such as delay_frames/job_id and pre_pulses, which are documented only in the schema. Since there is no output schema, the return values for these modes are not described in the description.

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?

The input schema provides exhaustive descriptions for all 7 parameters (100% coverage), so the description offers little additional parameter semantics; it mainly restates the sample_grid trade-off ('cheaper check') already captured in the schema.

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 clearly states a specific action: 'Capture a TOP node's current output as an inline PNG image'. It also distinguishes from other tools by noting 'only TOPs can be previewed' and by contrasting with the sample_grid variant.

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?

It explicitly gives a cheaper alternative ('For a much cheaper check... pass sample_grid=N') and an exclusion ('only TOPs can be previewed (CHOP/SOP/etc. have no image)'). However, it does not mention the deferred capture workflow via delay_frames/job_id, nor does it differentiate from the sibling get_inline_preview.

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