fusion-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Tools for reading and editing the active Autodesk Fusion design. Read the design and its parameters before changing anything.
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 |
|---|---|
| get_design_infoA | Summarize the active Fusion design: document name, units, and counts of components, bodies, sketches, features and user parameters. |
| list_parametersA | List every parameter in the active design with its expression, evaluated value and unit. Use this before changing dimensions. |
| set_parameterA | Change a parameter's expression (for example '25 mm' or 'width * 2'). Fusion recomputes the model; returns the old and new values. |
| start_exportA | Start exporting the active design to STEP, STL or F3D. Returns a job id immediately; poll get_job until it completes. |
| get_jobA | Check the status of a job started by start_export. |
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 5 tools
Each tool has a distinct action-object pairing: design summary, job polling, parameter listing, parameter mutation, and export initiation. The only mild overlap is get_design_info (which reports a count of user parameters) versus list_parameters, but the descriptions make the boundary clear.
All five tools follow a consistent snake_case verb_noun pattern (get_*, list_*, set_*, start_*). The get_job/start_export pairing is named predictably enough that the async relationship is obvious.
Five tools is well within the sweet spot and each one supports the narrow workflow of inspect design, read/adjust parameters, then export. Nothing feels redundant or padded.
The core lifecycle (inspect -> list parameters -> set parameter -> export -> poll job) is fully covered with no dead ends. Minor gaps exist: no create/delete parameter, no job cancellation or job listing, and no way to drill into individual components/bodies beyond counts.