Node Atlas for Autodesk Fusion

Map your Autodesk® Fusion® Design's parametric dependencies as an interactive Node Graph.

Trace patterns, assess impact before a change, and localize rebuild failures fast.


See the structure behind your Fusion design.

Contriver Node Atlas reads the parametric dependency structure of your active Fusion design and renders it as an interactive node graph

• Parameters
• Sketches
• Features
• Bodies
• and Construction Geometry

with the directed relationships between them laid out as a map you can explore.

Fusion's timeline shows you the order operations happened in.

Node Atlas shows you how they depend on one another.

what drives what, what a change will ripple into, and where a rebuild failure actually originates. 

Key Capabilities:

- Interactive Dependency Graph: 

Pan, zoom, and focus any node; trace its upstream or downstream chain to see exactly what it depends on and what depends on it.

- Child Centers: 

Group related features — for example a run of surface operations that stitch into a single body — into named container units; 

So you can reason about a region as one thing instead of a scatter of loose nodes.

- Record Relationships the API Doesn't Expose: 

Some real structural dependencies aren't reported by the Fusion API at all — notably Project-to-Surface and open-profile Thin Extrude. 

Node Atlas lets you record these explicitly, so they become part of the traversable graph instead of invisible gaps.

- Provenance on Every Edge: 

Each relationship is labeled by how it was established, across four provenance classes — explicit (reported directly by the API), recovered, associative, and manual (recorded by you).

You can always tell what the API reported from what was added by hand.

- Saved Views and Live Updates:

Save arrangements you return to, and let the graph refresh automatically as you change the timeline or parameters.

- Portable Export: 

Node Atlas writes the graph to a local JSON file — the same export the companion MCP server reads (see the +MCP listing).

Where it helps

- Impact Analysis Before a Change: 

see every downstream dependent of a parameter or feature before you touch it.

- Fault Localization: 

when a model breaks on rebuild, resolve the cause to a named region instead of combing the whole timeline.

- Design Comprehension and Handoff:

understand an unfamiliar model's structure, or make your own legible to someone else.

- Teaching parametric Design: 

a live map of design intent for instruction and review.

Contriver Node Atlas + MCP

Your Fusion design's dependency structure, readable by AI.

Everything in Contriver Node Atlas, plus a companion MCP server that exposes your design's dependency graph to AI assistants; 

so you can reason over your model's structure in a conversation with tools like Claude Desktop, Claude Code, Cursor, or VS Code.

The add-in builds and visualizes the graph inside Fusion. 

The MCP server makes that same graph available to an AI client as a set of read-only tools, so an assistant can trace impact, explain how a design is wired, and localize a failure to a named region.

Grounded in your actual dependency structure rather than guesses about it.

Everything in the stand-alone add-in

The full interactive dependency graph, Child Centers, manual-edge recording, provenance on every edge, saved views, and live refresh — all included.

What the MCP adds — 14 read-only tools

• get_graph — Returns the complete dependency graph in either a simplified Child Center view or the full raw graph.
• get_node — Inspects one node, its relationships, and any Child Center that contains it.
• trace_dependencies — Follows the upstream or downstream structural dependency chain from a selected node.
• get_manual_edges — Lists recorded dependencies that Node Atlas preserves where Fusion does not expose the relationship directly.
• get_provenance — Summarizes how graph relationships were established, with counts by provenance type.
• resolve — Finds nodes and Child Centers by name and returns convenient short handles for later queries.
• find_nodes — Searches and filters nodes by category, type, label, health, or suppression state.
• find_edges — Searches and filters relationships by type, provenance, class, recovery kind, or broken state.
• describe_child_center — Provides a detailed breakdown of a Child Center, including its members, internal relationships, boundaries, and entry points.
• get_anomalies — Checks the graph for broken relationships, unhealthy or orphaned nodes, disconnected parameters, and other structural concerns.
• get_parameters — Returns the model’s parameter table, including expressions, units, and the nodes each parameter controls.
• what_drives — Identifies which parameters control a selected node.
• trace_tree — Builds a bounded, multi-level dependency tree outward from a selected node.
• get_summary — Provides a compact overview of the model, including node, edge, provenance, and Child Center counts.
  

Read-only by Design

The MCP server is strictly read-only. it makes no external network calls and sends nothing to any AI provider on its own.

it reads the local graph file the add-in writes and returns it to your client and your clients own model does the reasoning.

When you use tools in a conversation, the graph data travels to your AI Client's model provider as part of that conversation,

exactly like any file you choose to share. The server never modifies your design.

Where it Helps

- Faster fault-finding:

Point the assistant at a broken body and let it localize the cause to the named feature that produces it

- Structure-Aware Conversations:

Bring your designs actual dependencies into the same workflow you already use for thinking, writing, and code.

Node Atlas v2.0.0 is a major release that turns the dependency graph from a read-only view into a structured, group-able, AI-readable model of your design.

Child Centers — group related features (such as a run of surface operations that stitch into one body) into named container units you can trace and reason about as a whole

Edge provenance — every relationship is now labeled by how it was established (explicit, recovered, associative, or manual), so dependencies reported by the API are distinguishable from ones you recorded by hand

Semantic container view — collapse each Child Center into a single bounded node to keep large designs legible while preserving the relationships that cross its boundary

Automatic local graph export — Node Atlas maintains a structured local export of your design's dependency graph, refreshed automatically as the model changes, for use with companion tools including the free Node Atlas MCP for AI assistants

Improved parameter-change detection — the graph responds to parameter value edits, not only timeline structure changes

Updated privacy disclosure to reflect the local graph-file export

1 — Build your first graph

Open a design in Fusion, then open the Node Atlas panel from the Fusion toolbar. Click Refresh to build the graph for the active design.

Node Atlas reads the design's dependency structure and lays it out as a node graph. Each node is a design element (a parameter, sketch, feature, body, or piece of construction geometry); each directed edge is a dependency, pointing from the element that drives a relationship to the element that depends on it.

2 — Read the graph

Nodes are typed by what they represent — parameters, sketches, features, bodies, and construction geometry — so you can tell at a glance what kind of element each one is.

Edges carry direction. Following an edge downstream shows you what a given element affects; following it upstream shows you what it depends on. A node with many outgoing edges is load-bearing — a lot of the model rests on it.

Provenance is recorded on every edge — a label for how the relationship was established, across four classes:

- explicit — reported directly by the Fusion API

- recovered

- associative

- manual — a relationship you recorded by hand (see Record dependencies the API doesn't expose)

Provenance lets you always distinguish what the API reported from what was added manually, so you know how much to trust each connection.

3 — Navigate and trace

Pan and zoom to move around the graph, and fit the view to bring the whole design back into frame. In a large model, the fastest way to find your bearings is to focus a single node and trace outward from it.

Trace dependencies from any node to follow its chain:

- Downstream answers "if I change this, what breaks?" — every element that ultimately depends on the one you selected.

- Upstream answers "what does this rest on?" — everything the selected element depends on, back to its roots.

Tracing is the core move for impact analysis. Before you edit a driving parameter or delete a feature, trace it downstream to see the full blast radius first.

4 — Group with Child Centers

Complex models accumulate regions that belong together — for example a run of surface operations (lofts, patches, trims) that stitch into a single body. Individually they clutter the graph; together they're one idea. Child Centers let you group them.

Select the elements that form a region and create a Child Center to bind them into a single named unit. A Child Center behaves as a first-class part of the graph: you can trace to and from it, and reason about the region as a whole rather than as a scatter of loose nodes.

Each Child Center carries a header you can right-click to add elements to it, remove elements from it, or delete the grouping.

Collapse a Child Center to draw it as one bounded container node. The interior detail is hidden, but every relationship that crosses the container's boundary stays visible — so a dense design stays legible without losing the connections that matter. Expand it again whenever you need the detail back.

5 — Record dependencies the API doesn't expose

Some real structural dependencies in Fusion are not reported by the API at all — notably Project-to-Surface and open-profile Thin Extrude relationships. Left alone, they show up as gaps: elements that clearly relate in the model but sit disconnected in the graph.

When you spot one, record a manual edge between the two elements. Once recorded, it becomes a full part of the traversable graph — it appears in traces, and it's tagged with manual provenance so it's always distinguishable from a relationship the API reported on its own. This is how you close the gaps the API leaves, without overstating what was recorded: the edge means exactly what you asserted, no more.

 6 — Keep the graph current

Node Atlas rebuilds automatically as you work. Editing the timeline — adding, reordering, or suppressing features — and changing parameter values both trigger a refresh, so the graph stays in step with the design without you having to think about it. You can also click Refresh at any time to rebuild on demand.

Each rebuild also updates a local export file that companion tools read (see Use with the free Node Atlas MCP).

7 — Save and return to views

Once you've arranged and focused the graph a particular way — collapsed certain regions, framed a subsystem — save the view so you can return to it later without rebuilding the arrangement by hand. Saved views are useful for the parts of a model you revisit often, and for walking someone else through a design in a consistent layout.

A command palette is available for quick actions, so you can reach common operations without hunting through the interface.

Tips

- Start from a node, not the whole graph. On a large model, focus one element and trace outward rather than trying to read everything at once.

- Trace before you edit. A downstream trace of any driver shows the full impact before you commit to a change.

- Group as you go. Turning finished regions into Child Centers keeps the graph legible as the model grows.

- Watch for gaps. Two elements that clearly relate but sit disconnected usually mean an API-invisible dependency worth recording as a manual edge.

Contriver Node Atlas is proprietary software.
Copyright (c) 2026 Brett Bailey / Contriver Guitars. All rights reserved.

Unauthorized copying, redistribution, resale, sublicensing, rebranding, public posting, source-code sharing, or derivative commercial use is prohibited without prior written permission from the copyright holder.

Autodesk, Fusion, and Fusion 360 are trademarks or registered trademarks of Autodesk, Inc.
Contriver Node Atlas is an independent add-in for Autodesk Fusion. It is not owned, sponsored, endorsed, or certified by Autodesk unless explicitly stated by Autodesk.

Some relationships are not exposed by the Fusion API. Fusion's API does not report certain real structural dependencies — notably Project-to-Surface, open-profile Thin Extrude, and Stitch Result relationships. These appear in the graph as gaps. This is a limitation of what the API exposes, not of your design.

Large designs produce large graphs: Very large models generate correspondingly large graphs, which can take longer to lay out and can be dense to read at full extent. Turn off "Animations" in the Views menu for better performance.