Retrieve methods, properties, and docstrings for any TouchDesigner class or attribute. Use this to inspect class details directly from your MCP client.
Methods/properties/docstring for a td class.
name (<class 'str'>): Class or attribute name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
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 must fully disclose behavior, but it only says 'Methods/properties/docstring for a td class', lacking details on output format, possible errors, or side effects. For a documentation tool, it is non-destructive, but that is not stated, and the expected result structure is not described.
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 short and to the point, but the parameter line is redundant, which wastes space. The structure is front-loaded with the purpose, but the inclusion of a bare parameter line adds clutter without substantive information.
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?
For a single-parameter tool, the description is minimal and leaves out expected output, error behavior, or any additional context. While the tool is simple, an agent could benefit from knowing what format the returned methods/properties/docstring will take, which is entirely absent.
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 coverage is 0%, and the description merely repeats the parameter name ('name (<class 'str'>): Class or attribute name.'), which adds no meaningful elaboration beyond the schema's own label. With no schema documentation and a description that only states the type, the parameter semantics are essentially undeveloped.
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 that the tool returns 'Methods/properties/docstring for a td class', which identifies the resource as a TouchDesigner class detail. However, it lacks a clear verb and does not differentiate from sibling tools like script_module_help or script_class_list, leaving the purpose somewhat vague.
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?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools include script_class_list (listing classes) and script_module_help (module help), but the description does not mention them or when to prefer one over another. This gap for a developer-tool context is significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.