Every shop has some version of the same spreadsheet: a time study template that gets copy-pasted for every new part, hand-filled with feeds, speeds, and guesses about how long a toolpath will really take. The numbers are usually close enough to quote a job, but they're rarely exact — because the person filling in the spreadsheet is working from experience and a glance at the CAM tree, not from the toolpath itself.
The Model Context Protocol (MCP) connector for Autodesk Fusion changes that equation. It gives an AI assistant direct, read/write access to whatever is open in Fusion — the design, the CAM setups, the toolpaths, even the machining-time calculator Fusion uses internally. Instead of estimating a cycle time, the assistant can ask Fusion for the real one.
What the connector actually exposes
The Fusion connector isn't just "can see the model." In a recent time study, it was used to:
- Enumerate bodies across the whole design, not just the root component — surfacing the actual solid part (and its real volume, bounding box, and assigned material) even when it was buried under a reference stock surface.
- List every CAM setup and operation, including the strategy each one uses (parallel, contour3D, scallop, radial, morphed spiral, and so on).
- Call
CAM.getMachiningTime()directly, which is the same engine Fusion itself uses to estimate feed time, rapid time, and tool-change time for a operation, a setup, or an entire pattern of operations. - Read each operation's actual programmed tool, RPM, feed rate, and stepover straight from its parameters, rather than assuming a "typical" value.
That last point matters more than it sounds like. A time study built from assumed feeds and speeds is a guess dressed up as a table. A time study built by asking Fusion "what did you actually calculate for this toolpath" is a measurement.
Why this beats the spreadsheet workflow
No transcription errors. Every number in the report — path length, feed time, tool diameter, spindle speed — was read out of the live document, not retyped from a screenshot of the CAM tree.
The comparison is fair. Because the cutting time comes from the toolpath itself, it's identical no matter which machine you're evaluating it against. What actually changes machine to machine is the non-cutting time — load/unload, probing, tool-change speed — which is exactly the part a spreadsheet-based study tends to fudge with a single "estimated setup time" line. Pulling real per-machine handling specs (from a machine database) and layering them onto the same measured cutting time produces an apples-to-apples comparison instead of three separate guesses.
It scales to "do this for every candidate machine" without extra manual work. Once the toolpath data is pulled once, generating a report for a second or third machine is a matter of swapping in that machine's handling and tool-changer numbers — not re-measuring anything.
It closes the loop between design and process planning. The same connector that reads the model can, on the design side, also query or update features — which means the door is open for a future where a DFM pass and a manufacturability time study happen against the same live session, instead of a CAD export, a CAM export, and a spreadsheet all slowly drifting out of sync with each other.
What the workflow looked like in practice
The recent example started from a plain request: "do a machining time study on the current design for the top 3 candidate machines, using our standard template." The process was:
- Query Fusion for the open document and confirm which design and which CAM setup were active.
- Walk every component to find the real solid body (material, volume, bounding box) rather than trusting the first body returned.
- Pull the operation list for the active setup, then call the machining-time API per operation to get real feed distance, feed time, rapid time, and tool-change count.
- Cross-reference a machine database for the handling, probing, and tool-changer specs of three candidate machines, and a workholding database to pick a vise that actually fits the stock.
- Fill the shop's own time-study template — same section headers, same table structure — but every cutting-time number was measured, not estimated.
- Flag the two numbers that had to be assumed (batch quantity and setup time, since neither the model nor the machine database captured them) so the person reviewing the report knew exactly which inputs to double-check.
The result was three ready-to-review Word documents, each following the shop's existing template, each with an identical (measured) cutting time and a machine-specific non-cutting time — built without anyone re-typing a single feed rate.
The takeaway
The value of the Fusion MCP connector isn't that it lets an AI assistant "see" a CAD file. It's that it lets the assistant ask Fusion the same questions a machinist or process planner would ask — what does this toolpath actually do, how long does it actually take, what tool is actually programmed — and get answers straight from the source. For time studies specifically, that turns a document that's normally an estimate into one that's a report: reproducible, machine-comparable, and only ever as stale as the CAM tree it was pulled from.
