Would You Use an MCP-Based AI Assistant for Dynamo?

AI
, , , ,
1

I’ve developed an MCP bridge that let AI assistants to access Dynamo and automate the workflows with-in Revit and other supported applications.

Example Video : Revit Dynamo MCP : Type a Prompt and Build Graph

Potential use cases include:

  • Graph creation from natural language prompts
  • Detecting and fixing broken Dynamo graphs
  • Model validation, compliance checks, and QA/QC automation
  • Data extraction and reporting
  • Python code generation, debugging, and optimization

I’m curious to hear how others see this fitting into their workflows.

What capabilities would be most valuable to you? Are there specific tasks in Dynamo that you’d like to automate using AI?

2

I guess the question I always have is how abstract is too abstract. Dynamo itself is already visual/somewhat beginner friendly, but I appreciate the goals here - suspect Autodesk team is cooking up similar things currently.

The main value I could see is if someone has no idea where to begin, and prefer to learn by example - it could be handy to break in a user’s ‘aha’ moment maybe. Some of the use cases you’ve mentioned for diagnosing dynamo graph issues seem broader in use case for general users.

3

Thanks Gavin, that’s a good perspective. I agree that Dynamo is already fairly visual and approachable, so I’d be cautious about abstracting things to the point where users lose visibility into what’s actually happening.

I also want to separate this from anything Autodesk may or may not be working on. This is really an independent experiment around what becomes possible when an AI assistant can interact directly with Dynamo through MCP.

I think you’re right that the strongest value may not be full graph generation. Personally, I’m finding the more interesting use case are around diagnosing broken graphs, understanding existing workflows, debugging Python, and helping users navigate large or unfamiliar graphs. Those are areas where even experienced Dynamo users can spend a lot of time.

The learning-by-example aspect is also something I think could be powerful, especially for helping users get past that initial “where do I start?” moment.

4

In reality, the true value lies in generating a complete, end-to-end, ready-to-use script. The reason is simple: standard AI models are trained almost exclusively on traditional code that flows strictly top-to-bottom. However, there is virtually no training data for visual, node-based workflows that progress left-to-right. On top of that, fulfilling a request in this domain requires visualizing the workspace canvas, placing every node neatly without overlaps to keep the graph readable, correctly wiring all nodes, executing the script, and if errors occur: reading the log, diagnosing the issue, and looping through retries… As if all that weren’t enough, it must also leverage the latest Dynamo nodes, including those from custom packages.

That sounds great, but what will all of this cost the end user—especially when factoring in the iterative trial-and-error loops? How much will a user pay without even knowing whether the final script actually works? Will they be forced to run the most expensive, flagship AI model on the market just to boost the success rate? In short: how much will a single script cost them?

Simply put, we are talking about a highly isolated, extremely niche domain within the AI landscape that operates on its own unique internal dynamics. Protocols like MCP (Model Context Protocol) are merely communication channels—much like USB-C. If you have the connector, you use it; you can’t bend or tweak a protocol to solve complex, domain-specific execution challenges on its own.

I’ve been working on this exact challenge for a long time. The project is still under active development, and whenever I find time, I share demos on LinkedIn. Although those demos lag slightly behind the current state of the project, they still give a solid idea of what’s happening under the hood. CoderAI operates as an orchestrator and a parallel multi-agent ecosystem. It coordinates the entire process by being self-healing and learning from its own experiences. In this way, it delivers complete, functional and executable scripts efficiently and cost-effectively.

5

Fair points. I don’t see MCP as the solution itself, just the bridge.

The reason I’m exploring this is because I’ve been building ML/ AI-assisted workflows across several technology stacks, including MCP and A2A, for quite some time, with some encouraging results. What I’ve found is that users don’t necessarily need a perfect end-to-end solution, or in this case, perfect graph generation, to see real value.

In practice, helping users create a starting graph, diagnose failures, understand existing workflows, and iterate faster can already save a significant amount of time. The question I’m trying to answer is how far we can push this with direct Dynamo interaction and execution feedback.

Full autonomous graph generation may ultimately be the destination, and perhaps where Autodesk and others are headed, but there’s a lot of value to unlock between where we are today and that end goal.

6

really love this thread here, and will certainly get the hang of it in time…I actually view Dynamo as smarter in its own right than any MCP, AI, or LLM… I know that’s an unpopular opinion in these AI-driven times where everything is supposed to be solved by AI, but Dynamo is actually quite easy to learn, faster than “vibe coding,” doesn’t cost tokens, and has other perks too—once you’ve practiced a bit. Plus, Dynamo forces you to understand what’s actually going on—something many “vibe coders” don’t know. I realize that’s an unpopular stance these days, but that’s just my two cents… and I’ll certainly keep learning and improving over time.

7

Hey all,

I’ll weigh in not as an Autodesker but as someone who’s spent some time playing in this space and who also cares deeply about automation in AEC.

Yes, the Autodesk team is working on something in this space. See here: Introducing Agentic workflows in Dynamo.

Yes, there is a plethora of potential value streams here.

  • Finding nodes to connect which will make the graph work
  • Troubleshooting an error
  • Updating an existing tool to do even more
  • Building partial workflows based on a prompt
  • Building complete workflows based on a prompt
  • Converting to or from Python or C# or design script
  • Building Python to expose host APIs without nodes
  • Finding packages
  • And so much more

Dynamo and visual programming is and will continue to be the fastest most configurable way to automate in AEC. LLMs are already proving to be a great way to augment and expand skills of all users in this space.

Experimentation in this space is always good and should be encouraged! But anyone thinking of formally providing tools in this space needs to put a lot of effort into the non-software aspects, including:

  • UX and UI - how one interfaces with Dynamo
  • Guard rails to prevent unintended and detrimental outputs
  • Data sovereignty and security including handling of the prompts and outputs
  • Configurability of the LLM provider
  • Billing
8

so agree :wink: and in the end the last “billing” :wink: :wink:

9

Dynamo is an incredibly useful platform and will remain a core part of the Revit ecosystem for a long time, largely because it’s the only native visual programming environment available for Revit today. In reality, there isn’t much direct competition in that space unless someone brings up Rhino.Inside and Grasshopper.

That said, I think whether it’s the fastest way to automate depends heavily on the use case. Dynamo shines for model-centric and file-based workflows, but when the problem expands into multiple files, cloud platforms, APS, databases, APIs, enterprise integrations, or long-running processes, other approaches are a much better fit.

On the billing side, this is where things get interesting. Most organizations already spend significant amounts on Revit, cloud platforms, APS, plugins, infrastructure, and training. In comparison, adding an LLM-powered capability is often a relatively small line item if it delivers measurable productivity gains. The discussion shouldn’t be about the cost of tokens alone, but whether the outcome justifies the investment.

The same applies to technology choices. Sometimes a Dynamo graph is the right answer, sometimes a Python script, sometimes a C# plugin, and increasingly sometimes an AI-assisted workflow. Each comes with its own dependencies, maintenance overhead, deployment considerations, and costs. The goal isn’t to force every problem through AI, Dynamo, or code. It’s to choose the most effective tool for the job.

That’s why I don’t see Dynamo, APS, MCP, A2A, APIs, and AI as competing technologies. They’re different layers of the same stack. The challenge isn’t choosing one over the other, it’s knowing where each adds the most value.

One area where I continue to see value for A2A in AEC is decision-making across disciplines rather than pure automation.

Most automation workflows are deterministic. If the process is known, a Dynamo graph, Python script, C# add-in, or APS workflow will usually do the job more efficiently.

A2A becomes interesting when multiple domain perspectives need to evaluate a problem and negotiate a solution. Below example, a clash is not just a geometric issue.

10

The time it takes most to build a scaled and stable APS tool is about a month for a skilled full time employee. About two weeks for an add-in. Dynamo is usually hours to build even very elaborate graphs and automations. And cloud files are really desktop files once you open them so that’s moot. Multiple files are a breeze with Dynamo multi-player. It is likely that Dynamo as a service is also going to change a lot of that mindset, assuming you adopt it.

Its specialty is in deterministic workflows though. The real question around LLM driven output should be is how much is a probabilistic workflow worth? If I charged you $300 for an answer which was probably right, would you buy it? What if that was $300/day for answers which are probably right? What if it was the cost of three more full time employees?

Those aren’t fake numbers by the way, but extrapolated values from various follow ups to success stories LLMs have had in the past.

Deterministic workflows cost nothing to run by comparison, and you know they are right once they’ve been built and tested. But anything using an LLM is a ‘best guess’ and needs to be treated as such. You’re handing over engineering judgement to a slot machine that cannot be held liable for its output. For high stakes,‘Claude said this was the best option’ won’t hold up in court when a building falls over. And at the other end of the spectrum ‘well yeah we should have carried the price to tile those walls, but ChatGPT carried them as paint’ won’t help anyone get out of the hot seat.

Managing the combination of deterministic and probabilistic is the next thing that computational design and automation experts will have to learn. There isn’t going to be an easy button here.

11

Fair on liability but liability was never about who produces the first draft, it’s about who signs off before it’s acted on. Nobody puts “the intern said so” in a courtroom either; the stamp belongs to whoever verified it. Same principle applies here: LLM proposes, deterministic rules check it before it touches a model or a decision. You’re not liable for the guess, you’re liable for the gate. That’s the actual engineering problem worth solving not whether the guess is allowed to exist at all.

12

Would You Use an MCP-Based AI Assistant for Dynamo?

john puts on his customer hat :cowboy_hat_face: :upside_down_face: :partying_face:

YES, and I do daily. But it is Autodesk’s own DynamoMCP server.

I for one have been using the heck out of our MCP and Autodesk Assistant integration while working on some sample graphs for a project lately.

Recently I had to disable it for some testing and I found that grouping a graph, naming the groups and cleaning up the node layouts are something that I have grown very dependent of it on.

john puts on dynamo product manager hat again :partying_face: :upside_down_face: :cowboy_hat_face:

One thing that is cool about utilizing the built-in Autodesk Assistant experience with Dynamo, is, it just works. Our users do not have to worry about api keys, system prompts, third parties having access to their data, etc.

With that being said, it is very cool that you are exploring this as well @MohammedM, and I encourage you to share more of what you are up to.

For anyone reading this thread who are curious about what the Dynamo team has been up to, head over to Autodesk Assistant in Dynamo + Agentic Node Alpha

You can also look at daily builds to test stuff even quicker on dynamobuilds.com, specifically the latest 4.2.x builds :smirking_face:

13

:thinking:

Hmmm…

:thinking:

I wonder…

:thinking:

Yep. That settles it.

We need images of John wearing his many respective hats to clearly convey which type of insights he’s providing!

14

And that verification has to happen in stages to prevent burn out during their review. The human brain can take so much incoming data before it goes numb and stops doing a quality job. The intern in your example produces much slower than the LLM which we are envisioning here. Do you think that the human in the loop of the QA process maintain the standard when the volume of work to review is returned at that LLM speed while maintaining all their other responsibilities? I am of the opinion that tight guardrails, recommendations and options not final outcomes, and decision assistance has more value.

In many ways it’s the same concern that many of the veterans had during the in the switch from hand drawing to CAD in the 80s and 90s. The act of putting pencil to paper is part of what helped them to make the right decisions for the project. Proponents of CAD argued that putting finger to mouse was that same process. I don’t know that ‘here is 200 pages of PDF to review’ is the same for most on the design side. This may partially be due to the fact I never reached that stage when I was in the industry (well not outside of projects I was already working on for ages on end), but my experience when I have seen people undergo such efforts is that the sooner you got them into the job the more readily they were able to navigate the decisions to make as they had more context.

The clash detection example you posted is a good example of the application (though I always argue a good use of tech and a reliable design process prevents the clash so there isn’t anything to resolve) as it has clear guard rails - though I would prefer a ‘human approval of a set of options’, it may not be needed in such uses.

In any case this is the sort of thing which has yet to be fully worked out. Keep up the explorations on all fronts though!