This server has severe definition quality gaps. Tool descriptions are present but lack LLM-optimized guidance on WHEN to use each tool and what it returns. Input schemas are partially visible but incomplete: most tools lack explicit type definitions for all parameters, and output schemas are entirely undocumented. Parameter descriptions are sparse or missing. No error handling guidance. The tools appear to be TouchDesigner-specific builders and data bridges, but the definitions do not meet production standards for agent reasoning.

• Add explicit output schema documentation to every tool. Example: 'Returns: {results: [{id, name, status, local_path, details}], total_count: int, errors: []}'. This enables LLMs to chain tools and extract the right fields.
• Expand tool descriptions to 100-200 characters following the pattern: WHAT it does, WHEN to call it, WHAT it returns. Example: 'Fetches vetted TouchDesigner community toolkits from a registry and stores them locally. Call this first to populate the toolkit library before building scenes. Returns a list of fetched toolkits with local paths and metadata.'
• Document all parameter types and constraints explicitly. For 'registry' (Path), add: 'Must be a valid JSON file with schema: {toolkits: [{id, name, fetch: {mode, repo, ...}}]}'. For 'poll_ms' (int), add: 'Range: 100-10000 milliseconds; default 500.'
• Add error handling guidance to each tool. Example: 'If registry file not found, returns error with available registry paths. If git clone fails, returns error with retry guidance and network diagnostics.'
• For build_spotify_fluid_map and build_brain_vj, add explicit input schemas with parameter types. Example: build_brain_vj should document 'parent' as type OP with description 'TouchDesigner operator reference; default /project1. Must be a valid container operator.'