Read CHOP channel values from a TouchDesigner operator, with optional downsampling to a maximum sample count for manageable data retrieval.
Read CHOP channel values (uniformly downsampled).
path (<class 'str'>): CHOP operator path.
max_samples (int | None): Max samples per channel (default 1024).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| max_samples | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does mention that values are 'uniformly downsampled' and that max_samples has a default of 1024, which is useful, but it says nothing about return format, error behavior, or what happens when the path is invalid or when multiple channels exist. This is a significant gap for a tool with no structured behavioral annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line core statement followed by parameter descriptions. The key scoping phrase 'uniformly downsampled' is front-loaded. It earns its place, though the parameter descriptions embedded in the text could be formatted more cleanly if they were part of the schema. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no output schema, no nested objects), and the description covers the essential purpose and parameters. However, the absence of an output schema means the agent has no idea what the return shape is (e.g., typed arrays, sample counts, timestamps), and no mention is made of typical usage context or limitations. For such a minimal tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents both parameters: path as a CHOP operator path, and max_samples as max samples per channel with a default of 1024. This compensates well for the bare schema. However, there is a discrepancy: the schema default is null while the description states 1024, which creates ambiguity and prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and a specific resource ('CHOP channel values'), which clearly indicates what the tool does. It is distinguished from siblings like data_top, data_sop, and data_dat by naming the CHOP data type, but it does not explicitly contrast itself with those alternatives. Slightly more explicit differentiation would make this a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling data tools (data_top, data_sop, data_dat), nor any mention of prerequisites, exclusions, or alternative selection criteria. The description only states the operation, leaving the agent to infer usage from the tool name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.