tdmcp

Export network docs to the vault

export_network_to_vault

Convert a TouchDesigner network into an Obsidian note with a Mermaid flowchart and wikilinks, making the vault graph view a clickable patch map.

Instructions

READ an existing TD network's topology and WRITE it as an Obsidian note: a Mermaid flowchart plus [[wikilinks]] for every operator and connection, so the vault's graph view becomes a clickable map of the patch. The note (Networks/.md by default) is fully rewritten on each call. Use this to persist a browsable map in the vault; use document_network to get the same documentation back as a tool result without touching the vault. Returns the note path and the node/connection counts (and whether output was truncated). Requires a configured TDMCP_VAULT_PATH.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "export_network_to_vault"
  }
}

Input Schema

Name	Required	Description	Default
`note`	No	Vault note path (defaults to Networks/<path>.md).
`path`	No	Network root to document.	/project1
`recursive`	No	Include all descendants (otherwise just the direct children).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.1Aug 2, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that the note is 'fully rewritten on each call,' which is important behavioral context beyond the annotations. Also describes the side effect (vault graph becomes a clickable map) and return value (note path, node/connection counts, truncation flag). No contradiction with readOnlyHint=false or destructiveHint=false.

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 every sentence carries essential information: what it does, output format, default behavior, alternative usage, return values, and prerequisite. No filler or redundant repetition of schema/annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with no output schema, the description adequately covers what is returned, the file behavior, the environment requirement, and the distinction from a sibling. This gives an agent enough context to invoke it correctly and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters (note, path, recursive). The description adds little additional parameter-level meaning beyond what is in the input schema, so baseline 3 is appropriate.

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 states a specific action: READ an existing TD network's topology and WRITE it as an Obsidian note, including Mermaid flowchart and wikilinks. It also distinguishes itself from the sibling document_network by clarifying that this tool persists to the vault while the alternative returns documentation without touching the vault.

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

Usage Guidelines5/5

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

Explicitly says 'Use this to persist a browsable map in the vault; use document_network to get the same documentation back as a tool result without touching the vault.' This gives clear when-to-use guidance and names the alternative tool. It also notes the TDMCP_VAULT_PATH requirement, which is a prerequisite for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server