The Open Design Alliance (ODA) plans to expose its CAD-format software development kits (SDKs) to AI agents through a set of self-hosted MCP servers, due in Q3 this year. Martyn Day explores why a consortium more closely associated with supporting developers is suddenly relevant to design firms
For more than 25 years, the Open Design Alliance (ODA) has occupied an unusual position in the CAD industry. It is one of the most influential organisations that many end users have never heard of.
The non-profit consortium develops the software development kits (SDKs) that allow software companies to read, write, visualise and manipulate engineering file formats, including DWG, DGN, IFC, STEP, and Revit (RVT).
Hundreds of desktop, cloud and mobile applications rely on ODA technology for interoperability without developers having to reverse engineer proprietary formats or build support themselves. The Alliance is governed by its more than 1,200 members, and by charter, it cannot be acquired – a structural detail that matters far more in the AI era than it previously did.
The ODA’s customers have traditionally been software developers. For example, if an independent software developer (ISV) wanted to build a BIM viewer, a model checker, a clash detection tool, a CAD translator, or an engineering application capable of opening DWG or Revit models, there was a good chance that ODA’s SDKs were doing much of the behind-the-scenes heavy lifting.
Discover what’s new in technology for architecture, engineering and construction — read the latest edition of AEC Magazine
👉 Subscribe FREE here
The arrival of generative AI, however, fundamentally changes who can benefit from those capabilities. Rather than exposing file format functionality solely through C++ or .NET APIs for developers, ODA is now packaging that same technology behind Model Context Protocol (MCP) servers. So, instead of writing code, users interact with engineering models using AI agents such as Anthropic’s Claude, using natural language. This is an important distinction. Most MCP activity to date has focused on connecting AI assistants to existing applications. By contrast, the ODA is exposing the underlying engineering toolset itself. The AI is not simply controlling software – it is interacting directly with the same SDK capabilities on which developers have relied for years.
Sensible approach
The mechanism the ODA proposes is sensible. You do not hand an AI agent a binary CAD file and hope it is able to guess what it’s dealing with, and text-based formats like DXF are too large and intricate to parse efficiently. Instead, the server sits between the agent and the file, and the agent asks for exactly the geometry, properties or structure it needs. The numbers, volume, mass, surface area, clearances and so on come back from the same compiled C++ engine that ships in commercial products, so the same model returns the same answer every time. Parsing happens in compiled code rather than tokens, which keeps costs down and accuracy up.
Early demonstrations show the range of this approach. In one demo, an agent takes a short prompt that requests a mountain road through three named points on real terrain. It then fetches and routes the terrain itself in Python and calls the ODA server to turn the result into a DWG and a technical PDF report, with no human in the loop. In a second demo, recorded inside the Open STEP Viewer, an agent inspects a part, measures it, adds a hole feature and dimensions the drawing. At launch, the servers cover DWG, STEP and IFC, with DGN, Revit and Navisworks following behind.
Neil Peterson, President of ODA, believes this move will dramatically expand the ODA audience. “This will put builder-like capabilities into the hands of a much larger audience, well beyond our current developer audience,” he says. “A non-developer will be able to do sophisticated work with CAD and BIM data with the help of AI.”
Big opportunity
It is perfectly reasonable to suggest that the biggest opportunity here lies in areas beyond the ODA’s typical reach. An architectural practice, engineering consultancy or contractor, for example, could deploy ODA’s MCP servers entirely within their own infrastructure, loading IFC files, DWGs and other supported datasets into a secure environment, with Revit to follow as the toolkit matures. Those servers can then be connected, via MCP, to whichever large language model (LLM) or AI framework the organisation chooses to use.
Instead of developing bespoke integrations against multiple file formats, practices could build their own AI agents that understand project information directly. An internal agent could interrogate BIM models, answer technical questions or generate schedules. It might also identify missing information, compare design revisions, extract quantities and check standards compliance. Critically, all these tasks could be performed while project data remains inside the firm’s own network. In effect, ODA becomes the data access layer that sits between proprietary engineering models and enterprise AI.
That could prove particularly attractive to larger firms in pursuit of AI sovereignty. The servers are self-hosted by members, rather than run as an ODA cloud service, and ODA is folding the capability into its Core SDKs Package at no additional cost, royalty-free under the existing annual subscription.
Rather than uploading sensitive project information into third-party cloud services, organisations can keep both their BIM data and their AI workflows firmly under their own control, while still benefiting from state-of-the-art language models.
Peterson freely acknowledges that this may create some friction. ODA is reworking its licensing so that a member cannot simply expose the technology to, say, Gemini’s entire user base without further terms. He anticipates some tension as members work out the implications.
Rather than uploading sensitive project information ‘‘ into third-party cloud services, organisations can keep both their BIM data and their AI workflows firmly under their own control, while still benefiting from state-of-the-art language models
His framing of why ODA is doing this anyway is the most telling part. “It’s inevitable that someone will provide this technology, and we believe ODA should be leading it and steering it in a good direction, rather than watching from the sidelines or taking a defensive position.”
A member-governed body that cannot be bought, offering self-hosted, model-agnostic access to the formats, is about as close to a firm-level data sovereignty play as this industry has produced.
There is a hurdle to cross, however, and Peterson does not pretend otherwise. Revit write-back is a longer-term project, constrained by ODA’s underlying C++ toolkit for Revit. The servers can write some elements today, but creating a full parametric model of a building is still a long way off, and the AI layer can only ever be as capable as the toolkit beneath it.
He is blunt in stating that closing the gap will require a significant increase in funding for the ODA’s RVT project. So the immediate gains look set to land first in mechanical and drawing-oriented work, where Peterson points to automated annotation placement as an especially promising area, and where AI-assisted product data management (PDM) starts to look credible. While none of this is shipping yet, the direction is clear. From my perspective, it is the right one. The most valuable thing the ODA owns is not any single format, but its new neutral, self-hosted access to all the standards that matter. Handing that to the agents represents a more durable answer to the AI question than a proprietary model sat behind a vendor’s MCP toll booth.
