fusionwright
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FUSIONWRIGHT_HOME | No | Directory where outputs are written. Defaults to ~/fusionwright-projects/. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fusion_statusB | Check that Fusion and the bridge add-in are reachable; report the active document. |
| fusion_apiA | Look up the real Fusion API. Pass an exact class name (e.g. 'ExtrudeFeatureInput') to list its members with docs, or keywords (e.g. 'rectangular pattern') to find classes. Use this before writing fusion_run code. |
| fusion_runA | Run Python inside Fusion's main thread (90 s limit). Predefined: app, ui, design, root, adsk, P3, VI, FO, IN,
coll(), board(name,x,y,z,sx,sy,sz) in inches. Set |
| fusion_rollbackA | Delete every timeline item after |
| fusion_inspectA | Compact state of the active design: counts, overall size (in), volume, timeline problems, invalid bodies. detail='full' adds per-body boxes and user parameters. |
| fusion_checkB | Validate the design: body validity, timeline health, body-to-body interference (kernel), and optionally the overall X/Y/Z size in inches. Returns pass/fail plus the reasons. |
| fusion_lookA | Screenshot the active Fusion viewport from named views: iso, front, back, left, right, top, bottom. |
| fusion_renderB | Photoreal render of the active design with Fusion's local renderer (quality 25-100; higher is slower). |
| fusion_exportA | Export the active design to step, stl, f3d, obj, 3mf, iges or sat. Local file only (never the cloud). |
| fusion_ui_commandB | Run any of Fusion's ~3,000 UI commands by id (what a menu click does), or search ids/names with |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have clearly distinct roles: run vs. rollback vs. render vs. export vs. look are unambiguous, and fusion_api is clearly scoped to doc lookup. The one soft overlap is the diagnostic trio fusion_status / fusion_inspect / fusion_check, all of which report document and timeline health, though their descriptions differentiate reachability, summary state, and validation. fusion_run vs. fusion_ui_command is also a mild boundary (Python vs. UI command id) but the descriptions clarify it.
Every tool uses the same fusion_ prefix followed by a single lowercase verb or noun, in consistent snake_case (fusion_status, fusion_run, fusion_rollback, fusion_inspect, fusion_check, fusion_look, fusion_render, fusion_export). No camelCase or verb-style mixing appears anywhere in the set.
Ten tools sits squarely in the ideal range and each one maps to a distinct stage of the CAD workflow: connectivity, API research, execution, rollback, inspection, validation, visualization, rendering, export, and UI automation. None feel redundant padding, and no obvious capability is left to a missing tool.
The surface covers the full create-modify-verify-visualize-export lifecycle, with fusion_run serving as a general escape hatch for anything not exposed directly. Minor gaps remain: there is no explicit save or document open/create tool, so persisting work or switching documents must be done through fusion_run or UI commands. These are workable but not obvious from the tool list.