Substance-3D-Designer-MCP
Related Servers
Alternatives to Substance-3D-Designer-MCP
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceA security-focused MCP server for Adobe Substance 3D Designer that reads application state, creates and manipulates nodes, and saves packages, with the runtime isolated outside Designer.291MIT
- AlicenseNot gradedqualityAmaintenanceAdapter that runs an MCP server inside Substance 3D Designer, enabling tools to inspect and interact with the active designer session and its packages through natural language.254 PyPI1MIT
- AlicenseNot gradedqualityAmaintenanceEnables agents to observe, batch, script, recover, bake, and export Adobe Substance 3D Painter scenes through a Model Context Protocol server with specialist schemas and persistent tooling.MIT
- FlicenseNot gradedqualityBmaintenanceEnables MCP clients to drive Blockbench Desktop locally for Minecraft model, UV, texture, animation, and export workflows. It provides typed operations, high-level task workflows, native controls, and inspection/verification tools over an authenticated loopback connection.3-
- FlicenseAqualityCmaintenanceEnables MCP clients to drive ArmorPaint 1.0 through a file-based bridge plugin, letting agents open projects, inspect and edit materials and node graphs, paint, and export textures on an unmodified ArmorPaint installation.581-
- AlicenseNot gradedqualityCmaintenanceA local MCP server that enables MCP-compatible AI clients to inspect and control the currently open scene in a running Autodesk VRED Professional 2027 instance via a secure bridge, supporting read-only inspection and gated mutations like selection, visibility, transforms, and screenshots.MIT
TDQS
Scored across 29 tools
Most tools have clearly distinct resource-action pairs (e.g., create_node vs create_instance_node vs create_graph). However, sd_ping, sd_get_application_info, and sd_get_capabilities all report version/status/capability information, creating some overlap that could confuse an agent.
All tool names follow a consistent 'sd_verb_noun' snake_case pattern (e.g., sd_list_packages, sd_create_node, sd_delete_nodes). The only minor deviation is sd_get_active_graph using an adjective, but it still fits the pattern.
With 29 tools, this exceeds the 25+ threshold for 'too many' per the calibration. While the domain is broad, there is noticeable redundancy in info-gathering tools (ping, get_application_info, get_capabilities) and some niche tools (validate/apply_graph_patch) that could be consolidated or omitted.
The tool set covers the core lifecycle for packages, graphs, and nodes: create, read, update, delete, connect/disconnect, save, and export. Missing operations like package deletion, undo, or copy/paste are minor gaps that don't block primary workflows.