Which integrations are available for this server?

Provides tools for interacting with Autodesk Fusion designs via a local Fusion add-in bridge, enabling agents to read design information, list and modify parameters, and export designs to STEP, STL, or F3D as background jobs.

How do I use fusion-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fusion-mcp-server Make the bracket 25 mm wide and export it as STEP to ~/Desktop/bracket.step." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

fusion-mcp-server

by gladiatorAsh

Overview Schema Source Related Servers Discussions Admin

Python

Local

fusion-mcp-server

An MCP server for Autodesk Fusion. Ask an agent to read a design, change its dimensions, or export it, from Claude, VS Code, Copilot or any other MCP client.

Status: early. The MCP server, the job model for long exports and the Fusion add-in are written. The server is tested against a fake bridge, and the add-in still needs hands-on testing inside Fusion. See the roadmap.
This is an independent, personal project built from scratch on the public Fusion API. It isn't affiliated with Autodesk.

How it works

MCP client ──stdio / Streamable HTTP──▶ fusion-mcp-server ──HTTP + token──▶ FusionMCPBridge add-in ──▶ Fusion API
 (Claude, VS Code…)                      (this package)        127.0.0.1         (inside Fusion)            (main thread)

Fusion's API only runs inside Fusion and isn't thread-safe, so the system has two parts:

FusionMCPBridge (addin/) is a Fusion add-in that serves a small JSON API on 127.0.0.1. Each request is handed to Fusion's main thread through a custom event. A fresh token is created every session and stored in ~/.fusion-mcp/token, readable only by you, so other local programs can't drive Fusion.
fusion-mcp-server (src/) is the MCP server, built on the official Python SDK 2.x. It exposes typed, annotated tools and calls the bridge.

Tools

Tool	What it does	Annotations
`get_design_info`	Document name, units, component, body, sketch and feature counts	read-only
`list_parameters`	Every parameter with its expression, value and unit	read-only
`set_parameter`	Change an expression (`'25 mm'`, `'width * 2'`); Fusion recomputes the model	write, idempotent
`start_export`	Export to STEP, STL or F3D as a background job	write
`get_job`	Poll a job until it completes or fails	read-only

Why jobs? Exporting a large assembly can take minutes. start_export returns at once and get_job reports progress, so no request stays open for minutes. That fits the stateless 2026-07-28 protocol, and the pattern maps directly onto the MCP Tasks extension, which this server will move to once the Python SDK supports it.

Related MCP server: Fusion Native MCP

Setup

Install the add-in. In Fusion, open Utilities → Add-Ins → Scripts and Add-Ins, click +, choose addin/FusionMCPBridge, and run it.
Install the server:
```
pip install -e .
```

Add it to your MCP client:

{
  "mcpServers": {
    "fusion": { "command": "fusion-mcp-server" }
  }
}

Ask: "What user parameters does this design have? Make the bracket 25 mm wide and export it as STEP to ~/Desktop/bracket.step."

Development

pip install -e ".[dev]"
pytest -q                                              # tools tested through a real MCP client, fake bridge
mcp-tool-bench lint "python -m fusion_mcp"             # 0 errors, 0 warnings

Roadmap

MCP server with typed, annotated tools (Python SDK 2.x, stdio and Streamable HTTP)
Background jobs for exports
Fusion add-in: token-protected localhost bridge with main-thread dispatch
Tests through an in-process MCP client; clean mcp-tool-bench lint
Test the add-in end to end in Fusion on Windows and macOS
Move long-running work to the MCP Tasks extension
More tools: sketch and extrude from a description, timeline inspection, mass properties, screenshots of the viewport
Return exported parts as resources that mcp-cad-viewer can render inline
Tool-selection evals with mcp-tool-bench across several models
Confirmation step (elicitation) before changes that affect many features

License

MIT © Ashutosh Singh

Available Tools

5 tools

get_design_infoA

Read-only

Summarize the active Fusion design: document name, units, and counts of components, bodies, sketches, features and user parameters.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

The readOnlyHint annotation already tells the agent this is a non-mutating read, so the description only needs to add scope, which it does by specifying the 'active' design and framing the result as counts rather than full data. It does not disclose what happens when no design is open or how large the summary is, but with an output schema present the return shape is covered elsewhere.

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?

A single sentence, front-loaded with the verb and resource, followed by the exact fields returned. Every clause carries information; nothing is repeated from the name or title.

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

Completeness4/5

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

For a zero-parameter, read-only summary tool with an output schema and a readOnlyHint annotation, the description covers purpose and scope adequately. The only meaningful omission is behavior when no active design exists, which an agent might want to know before calling.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to explain and the description correctly spends no words on inputs. Baseline 4 applies for a no-argument tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Summarize') and resource ('the active Fusion design'), then enumerates exactly what the summary contains: document name, units, and counts of components, bodies, sketches, features and user parameters. That enumeration makes it easily distinguishable from siblings like list_parameters or set_parameter, though it never names a sibling explicitly.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus alternatives such as list_parameters, which overlaps on the user-parameters portion of the output. The word 'active' implicitly scopes it to the currently open document, but no preconditions (e.g., a design must be open) or exclusions are stated.

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

get_jobA

Read-only

Check the status of a job started by start_export.

Name	Required	Description	Default
`job_id`	Yes	The job_id returned by start_export

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

The readOnlyHint annotation already establishes this is a safe, non-mutating call, so the description is not carrying the safety burden. It adds the lifecycle context (this reads state produced by start_export) but says nothing about terminal states, partial results, or error behavior for an unknown job_id.

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?

A single front-loaded sentence with no filler. The workflow anchor (start_export) is placed at the end where it does the most routing work, and nothing is wasted.

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

Completeness4/5

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

For a one-parameter read tool with an existing output schema and readOnlyHint annotation, the description covers what it does and where the input comes from. Only minor gaps remain (polling expectations, behavior on expired or unknown jobs) that a caller might want.

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 coverage is 100% and the schema already documents job_id as 'The job_id returned by start_export', which is exactly what the description restates. No additional formatting, validity, or reuse guidance is added beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Check the status of a job') and ties it to the sibling that creates jobs ('started by start_export'), so an agent can place it in the export workflow. It does not distinguish itself from the other read-only sibling (get_design_info), but the lifecycle pairing is clear.

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

Usage Guidelines3/5

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

Usage context is implied rather than stated: the phrase 'a job started by start_export' tells the agent this follows start_export. There is no guidance on whether to poll, how often, or what to do once the job reaches a terminal state, and no explicit exclusions.

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

list_parametersA

Read-only

List every parameter in the active design with its expression, evaluated value and unit. Use this before changing dimensions.

Name	Required	Description	Default
`user_only`	No	Only return user parameters, not model parameters created by features

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

The read-only nature is already declared by readOnlyHint=true, and the description is consistent with it. It adds the useful scoping detail that results come from the "active design" only, but says nothing about ordering, volume, or how user versus model parameters are treated beyond what the schema states. With annotations carrying the safety profile, this is modest added value.

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?

Two short sentences, purpose first and the usage directive second. Nothing is padded or repeated from the title, and every clause carries information an agent needs.

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

Completeness4/5

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

With one optional parameter, full schema coverage, an output schema, and readOnlyHint provided, the description only needs to establish purpose and timing, which it does. The only minor shortfall is that it never signals what user_only changes about the result set.

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 sole parameter (user_only) is already fully documented as filtering out feature-created model parameters. The description adds no meaning about that filter, leaving the schema to do all the work, which matches the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List every parameter in the active design with its expression, evaluated value and unit" gives a specific verb (list), resource (parameters), scope (active design), and even the fields returned. It doesn't explicitly name a sibling such as get_design_info or set_parameter, so differentiation is inferred rather than stated.

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

Usage Guidelines4/5

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

"Use this before changing dimensions" gives a concrete when-to-use trigger tied to the obvious follow-up (set_parameter). There are no exclusions or explicit alternatives named, but the read-before-write framing is clear context.

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

set_parameterA

Idempotent

Change a parameter's expression (for example '25 mm' or 'width * 2'). Fusion recomputes the model; returns the old and new values.

Name	Required	Description	Default
`name`	Yes	Exact parameter name, as returned by list_parameters
`expression`	Yes	New expression including units, e.g. '25 mm', '3 deg' or 'width / 2'

Output Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare a non-read-only, idempotent, non-destructive mutation. The description goes beyond that by disclosing the key side effect ('Fusion recomputes the model') and the return payload (old and new values), which an agent needs to sequence calls. It omits failure behavior for invalid expressions, so it is strong but not exhaustive.

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?

A single front-loaded sentence with the verb first, a parenthetical example for the expression format, and the recompute/return consequence last. Nothing redundant.

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

Completeness4/5

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

With only two fully documented parameters and an output schema present, the definition covers what an agent needs: what is changed, that the model recomputes, and that old/new values come back. The only gap is error handling for an invalid expression, which is minor.

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 coverage is 100%, so both parameters are already documented, including an 'as returned by list_parameters' note on name. The description's expression examples largely duplicate the schema's examples, adding little new semantics; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Change a parameter's expression') with concrete examples, making it obviously distinct from list_parameters and get_design_info. Sibling differentiation is implicit rather than explicit, which keeps it just short of a 5.

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

Usage Guidelines3/5

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

The description implies the use case (setting a new expression on an existing parameter) but never states when to use it versus alternatives such as reading parameters via list_parameters, nor any prerequisites. Usage is inferred rather than guided.

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

start_exportA

Idempotent

Start exporting the active design to STEP, STL or F3D. Returns a job id immediately; poll get_job until it completes.

Name	Required	Description	Default
`path`	Yes	Destination file path on the machine running Fusion
`format`	Yes	Output format

Output Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description correctly adds the non-obvious async behavior: it 'returns a job id immediately' and requires polling. It omits edge behavior such as whether an existing file at path is overwritten, which matters for a write operation.

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?

Two compact sentences, zero filler. The core action is front-loaded and the async follow-up is stated second, which matches the order an agent needs it.

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

Completeness4/5

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

With annotations, a full-coverage schema, and an output schema present, the description covers the essential async contract. Minor gaps remain around failure modes (overwrite behavior, invalid path, unsupported design state) that would help an agent handle errors.

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 coverage is 100%, with both path and format documented and the format enum spelled out in the schema, so the description adds little parameter-level meaning beyond restating the formats. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Names a specific verb ('start exporting'), the exact resource ('the active design'), and the supported formats (STEP, STL, F3D). An agent can immediately tell this begins an export job rather than retrieving design data like the get_design_info sibling.

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

Usage Guidelines4/5

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

Explicitly states the follow-up workflow: 'poll get_job until it completes', naming the relevant sibling and the condition that selects it. It stops short of stating when-not-to-use cases (e.g., unsupported formats or already-running exports), so it falls just short of full when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Nov 7, 2026
- First observedget_design_info
- First observedget_job
- First observedlist_parameters
- First observedset_parameter
- First observedstart_export

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-11-07 23:25 across 5 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Revit MCP
com.aecomcps
Read and edit the Revit 2024–2027 model on your PC. Needs the free Revit MCP add-in.
Design Tools App Automation
1
https://revit-mcp.pages.dev/mcp/revit
Open Design MCP
net.digitalpipe.app
Open Design MCP capability governed by DigitalPipe.
Design Tools Software Architecture
2
https://app.digitalpipe.net/p/dCYkJz/mcp
Algenta MCP ServerA
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
14021
https://api.algenta.ai/mcp
autocad-site-mcpA
io.github.blackmoon87
Headless CAD engine & MCP server for 2D/3D drafting, solids, DXF/SVG export, and automation.
Design Tools App Automation
191
https://acad-qlae.onrender.com/mcp

Related MCP Servers

Fusion MCP para Codex
Design Tools
ffelipev2
F
license
Not graded
quality
C
maintenance
Enables AI assistants to inspect and automate Autodesk Fusion 360 through MCP, providing tools for CAD modeling, CAM manufacturing, and document management.
Updated 2 months ago (2026-08-24 17:00 UTC)
-
Fusion Native MCP
Developer Tools
Dawn-Of-Justice
A
license
C
quality
C
maintenance
Enables MCP-compatible assistants to control Autodesk Fusion for mechanical modeling, assembly editing, CAM workflows, inspection, and model export through Fusion's native MCP endpoint.
Updated 2 months ago (2026-09-10 05:29 UTC)
39
1
MIT
self-host-fusion360-mcp
mystify59
A
license
B
quality
B
maintenance
Enables any MCP client to drive Autodesk Fusion 360 locally, with ~100 tools for modeling, assemblies, CAM, inspection, and verification, plus enhanced component targeting and explicit thread creation.
Updated 2 months ago (2026-09-10 02:48 UTC)
108
1
MIT
fusion360-mcp
Design Tools App Automation
bunnyruri99
A
license
A
quality
C
maintenance
Enables controlling Autodesk Fusion 360 from any MCP-compatible AI client through natural language. Exposes tools for creating sketches, drawing rectangles and circles, extruding, revolving, filleting, shelling, drilling holes and bolt-circle patterns, managing user parameters, and exporting STEP/STL files, plus batch generation of parametric variants.
Updated a month ago (2026-10-07 15:41 UTC)
15
MIT