Retrieves connection information for a TouchDesigner operator path, with selectable detail levels and YAML or JSON output.
Alias of conn.get.
path (<class 'str'>): Operator path.
detail (str | None): full (default) | summary (long lists cut to 25 + count) | minimal (top-level scalars only).
response_format (str | None): yaml (default, token-cheap) | json.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| detail | No | ||
| response_format | No |
Changes observed during successful MCP inspections.
v0.4.0Input schema / properties / detailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Detail"
+}Input schema / properties / response_formatAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Response Format"
+}v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry all behavioral disclosure. It only says 'alias of conn.get' and gives parameter options, with no mention of side effects, read-only nature, error behavior, or return structure. The description is silent on what happens on success or failure.
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 text is short but poorly structured. The leading 'Alias of conn.get' is not informative and wastes space. Parameter explanations are crammed into a single line, making them harder to parse. It could be more concise and organized.
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?
With no output schema and no annotations, the description is severely lacking. It does not explain what a connection is, what the return value looks like, how errors are reported, or any constraints on path. It is insufficient for an agent to confidently invoke this tool correctly.
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?
Despite the schema having no descriptions, the description provides meaningful detail: path is an operator path, detail has three explicit modes with explanations, and response_format offers yaml or json with token-efficiency noted. This adds genuine value beyond the schema.
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 'Alias of conn.get' which is not a clear purpose. It implies retrieval but doesn't specify what 'connection' means, what 'path' refers to, or what operation is performed. It doesn't distinguish from sibling conn_get or other connection tools.
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?
No guidance on when to use this tool vs alternatives. There is a sibling conn_get that appears to be the original, but no relationship or selection criteria is provided. The agent has no basis to choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.