Skip to main content
Glama
GaNotchVFX

touchbridge

by GaNotchVFX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

project_import_tox

Load a .tox component into a TouchDesigner parent COMP. Validates the file path under allowed roots and returns a configurable summary of the imported content.

Instructions

Load a .tox into a parent COMP. Path must be under the project folder or $TOUCHBRIDGE_TOX_ROOTS; .toe refused.

path (<class 'str'>): The .tox file.

parentPath (str | None): COMP to load into (default '/project1').

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
detailNo
parentPathNo
response_formatNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.0
    • addedInput schema / properties / detail
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Detail"
+}
    • addedInput schema / properties / response_format
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Response Format"
+}
  2. First observedv0.2.0

TDQS

A4.3/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 of behavioral disclosure. It reveals that .toe files are refused, that the path must be under specific roots, and details how the 'detail' and 'response_format' parameters alter output (e.g., summary cuts lists to 25 + count, yaml is token-cheap). This is substantial behavioral context, though it stops short of describing side effects or error behavior.

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 compact and efficiently structured: a one-sentence purpose with constraints, then a per-line parameter list. No filler or repetition; every sentence adds value. It is front-loaded with the most critical information first.

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?

Given the tool's complexity (4 parameters, no output schema, no annotations), the description covers purpose, constraints, and parameter semantics thoroughly. It does not explicitly describe the return value or error handling, but the response_format parameter implies the output is a yaml or json document, and for an import tool this is likely sufficient. The gap is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description fully compensates by explaining each parameter: path is the .tox file, parentPath defaults to '/project1', detail has three explicit levels with behavior, and response_format has two options with default and token efficiency. This adds significant meaning beyond the bare schema types and titles.

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 opens with a clear, specific verb and resource: 'Load a .tox into a parent COMP.' It immediately adds scoping constraints (path must be under project folder or $TOUCHBRIDGE_TOX_ROOTS; .toe refused), which distinguishes it from export and other node operations. This is unambiguous and easily differentiated from siblings like project_export_tox.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides path constraints but does not explicitly state when to use this tool versus alternatives or when not to use it. It implies usage context (importing a tox into a COMP) but lacks explicit 'use this instead of X' guidance. The constraints on path are more about validation than usage routing.

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