debug

TD Debug

Systematically investigate TouchDesigner node errors within a scope, classify each one, and propose fixes.

Workflow

1. Resolve the scope to inspect: use the node-path argument if the user supplied one; otherwise default to /project1 if it exists, else / (a project launched by opening the tox as a document has no /project1 — the component sits at the root). If neither is available and the default seems wrong for the user's project (e.g. they referenced a specific component earlier), ask which path to scope to before continuing.

2. Optionally call get_td_info first if connectivity hasn't been confirmed this session — if it fails, stop and point the user at /touchdesigner:setup rather than proceeding against a dead connection.

3. Call get_td_node_errors with nodePath set to the resolved scope. This tool requires a nodePath but aggregates errors from that node and all of its descendants, so one call against /project1 (or whatever scope was resolved) covers the whole subtree — there's no need to call it once per node.

4. Read the report as it is actually rendered, and decide what it licenses you to say. By default it comes back as markdown rather than the raw schema: a ## Node <path> heading, an - Errors: N · Warnings: M line, and — when there is anything to list — a table whose rows are | Level | Node | Type | Message |, warnings included. Three things follow from that shape:

   • Warnings are findings, not noise. A missing file, a dangling operator reference and a shader that will not compile are all reported as warnings rather than errors, so a warning row is usually the answer rather than a footnote to it.
   • _No errors or warnings reported._ is the only all-clear. That sentence is withheld whenever a message stream could not be read, the warning stream was never inspected (an older mcp_webserver_base.tox, predating warning collection), or the reported counts disagree with the rows returned — those cases print a > ⚠️ blockquote instead. An empty table without that sentence is a scope that could not be fully seen, not a clean one. Say which of the two it was rather than reporting both as "no errors".
   • Even a genuine all-clear is not proof the node cooked. This tool reads the operator error and warning streams only. An exception raised inside a Script OP callback — a scriptCHOP's onCook, an Execute DAT's callback — lands on neither stream and is reported nowhere here, producing exactly the same empty report as a healthy node.