A power outlet for AI: what MCP means for AEC

Your AI assistant can draft the RFI response, summarize a spec section, and clean up the meeting minutes. Ask it which girder on level 3 has the highest demand-to-capacity ratio, and it guesses. Not because it isn’t smart enough, but because it has no way into your model.

That gap is closing. The Model Context Protocol, or MCP, is an open standard that lets AI applications connect to the software and data that engineers already use. Think of it as a power outlet for AI: one standard socket, and every tool plugged into it becomes something the AI can actually work with.

I come at this from two sides. My work with Dlubal Software puts me in an environment where MCP is already part of the product, and I’m developing my own model-review software for IFC models. This article explains what MCP is, what it’s good for in AEC, and why connecting our tools to the AI platforms engineers already use usually makes more sense than building yet another chatbot.

MCP doesn’t make AI smarter. It gives AI a standard way to reach things outside itself: your models, your analysis engines, your project data.

Picture the temporary power spider box on a jobsite. It doesn’t care whether you plug in a saw, a grinder, or a work light, because every tool has the same plug. Before MCP, connecting an AI to an application meant custom wiring for every pair: five AI apps and twenty programs meant up to a hundred one-off integrations. With MCP, each AI application implements support for a common protocol, and each program exposes the required tools through a server. This removes much of the custom integration work for individual pairs. Each connection still needs the right setup and permissions.

The host AI application can manage multiple MCP clients, typically one for each connected server.

Anthropic released MCP as an open standard in November 2024. In December 2025, it handed the standard over to the Agentic AI Foundation under the Linux Foundation, backed by OpenAI, Google, Microsoft, and AWS, among others. Today ChatGPT, Claude, Gemini, Microsoft Copilot, GitHub Copilot, and Cursor all support it.

Three roles, in plain terms:

• Host: the AI application you type into, such as ChatGPT, Gemini, Claude, or your company’s own chatbot.
• Client: the connector inside the host that keeps the line open to one server.
• Server: a small program on the software side that tells the AI what it can do. RFEM, Revit, and an IFC review tool would each get their own.

What a server offers:

• Tools are actions the AI can call: check a model against the project’s data requirements, compare two model versions, start an analysis.
• Resources are data the AI can read: a model summary, a list of load cases.
• Prompts are prepared workflows: “review the changes between versions A and B.”

The key detail is discovery. Each tool comes with a description and a structured definition of its inputs. When you ask a question, the AI uses those to choose a tool and supply the information it needs. Nobody hard-codes which button to press, but the application decides which tools are available.

A server can run locally, right next to your desktop application. The model file stays on your machine; only the answers the tools return are sent to the AI. Or it can run remotely over HTTPS with a proper sign-in, which suits cloud platforms. If IFC is how a model describes a building, MCP is how an AI asks that model questions.

MCP turns AI from a confident guesser into a coordinator that hands each task to a tool engineers already trust. That distinction matters more in our industry than almost anywhere else.

A general-purpose language model predicts plausible text. Ask it to check a beam and you get a well-formatted, confident answer that may simply be wrong, because it never ran the numbers. With MCP, the AI delegates: the calculation goes to the analysis engine, the question about the model goes to the model, and the AI does what it’s genuinely good at. It understands the question, runs the steps in the right order, and explains the result in plain language. It can still choose the wrong filter or misread a result, so the connection alone doesn’t make an answer reliable. It makes it checkable.

MCP isn’t the only way to get project information into an AI, so it helps to see where it fits. Copying and pasting a results table into chat works, but it’s a manual snapshot that goes stale the moment the model changes. Retrieval-augmented generation (RAG) lets AI search documents, such as a design standard, a BIM Execution Plan, or a product manual, and quote what it finds.

These aren’t competing technologies. MCP is the connection; a document search is one kind of tool you can connect. It can sit behind an MCP server just as well as a tool that queries a live model or runs a check. The useful difference is what each tool can do. A document search answers “what does the standard say?” A model tool answers “what does my model say, and does it pass?” Most serious AEC workflows will use both.

Custom integrations, like a vendor’s built-in assistant, also reach live data, but each one wires one AI to one application. MCP makes the same tools reusable by any AI app that supports it, within the limits of each app’s setup. The AI can do exactly what the tools allow, nothing more.

What does that look like on a real project? These requests are already possible with servers that exist today:

• Model queries: “Find every fire-rated door on level 2 without a hardware set and select them.” Autodesk’s official Revit server can search the model and select the results.
• Quantities: “How many cubic yards of concrete are in the slabs, story by story?” Open-source servers read this straight from an IFC file, as long as the model holds reliable quantities.
• Coordination: “Which issues from last week’s coordination meeting are still open?” Coordination platforms such as Revizto now offer MCP servers, and community servers reach issues and RFIs in Autodesk Construction Cloud.
• Analysis results: “What’s the maximum deflection of the floor beams under service load combinations, and is it within L/360?” The answer comes from the analysis program, not from the AI’s memory.

Let the AI companies do language; let AEC software do engineering. Every few months someone in our industry announces a proprietary assistant. Building your own chatbot doesn’t mean building your own language model, though. Most custom assistants run on the same commercial models behind their own interface. The real question is where the engineering tools live, and MCP keeps them reusable whichever interface your team ends up using. Here’s why starting with the AI platforms your team already uses usually makes sense.

1. You get the most capable AI models, and they keep improving. No engineering firm or AEC vendor can match the research budgets of Anthropic, Google, OpenAI, or Microsoft. As the models improve, they tend to get better at choosing tools and explaining results. That isn’t automatic for every workflow, so retest what matters when the AI model changes.
2. Engineers already work there. Many firms already pay for Microsoft 365 Copilot, ChatGPT, Claude, or Gemini. A new standalone chatbot adds another interface that the team has to learn and fit into its workflow. If the assistant your firm already has supports the connection you need, an MCP server shows up where people already work.
3. Build once, plug in anywhere. The same server can be reused in Claude, ChatGPT, Gemini, Copilot, and AI assistants a firm builds for itself. Each app still needs its own connection setup, and not every product supports every feature. But if your firm switches AI providers, the engineering tools don’t have to be rebuilt. Even direct competitors such as OpenAI, Google, and Microsoft back the standard.
4. Tools start working together. One conversation can query the model, run an analysis, fill a spreadsheet, and file the result in your document system. That kind of cross-tool workflow used to require a custom script for every step.
5. Your expertise stays yours. The vendor keeps the validated solver, the design-standard checks, and the data model. The AI platform supplies the conversation layer on top. Domain knowledge stays the competitive advantage, which is exactly where it belongs.

There is a sixth, quieter benefit. The big hosts bring enterprise plumbing that a small AEC tool would never build on its own: admin approval of connectors, permission prompts before a tool runs, and sign-in through standard protocols. In Microsoft 365 Copilot and Gemini Enterprise, for example, an IT admin can register a custom MCP server once for the whole organization.

The right question isn’t whether to let AI into your model, but what it may do there. Your firm decides that, not the AI. MCP makes the boundary visible because every server declares exactly which tools exist. What matters is what those tools can do and the permissions behind them, not the label on the server.

Reading. The AI queries models and data: it lists the fire-rated doors on a level or pulls the properties of a single element. Read-only access limits changes to the model. It doesn’t make the information less sensitive, and it doesn’t prevent a misleading answer.

Checking. The AI runs checks: an IDS validation, a clash report, a comparison between revisions. IDS is a buildingSMART standard for expressing selected information requirements in a machine-checkable form. You specify which elements need which data, and a checker tests the model against those rules. It checks the information, not whether the building is correctly designed. The findings inform decisions, so a person reviews them.

Writing. The AI changes the model itself: it fills in parameters, moves elements, or creates new ones. That needs controlled permissions, a review of each change, and a way to undo it.

Autodesk’s Revit servers show how vendors are drawing these lines. The first Revit MCP server, released in June as a technical preview, was read-only. In September, Autodesk added a Trusted-Write server, which lets you review every change an agent makes, and an Experimental server with broader editing tools, which Autodesk describes as “use at your own risk.” Both are technical previews for Revit 2027. For most firms, reading is the right place to start, on a test model the firm has approved.

To test how high the barrier really is, I built a read-only MCP server for the model-review software I’m developing. It already checks IFC models against IDS requirements and compares model versions. The validation itself isn’t new; the software did it before. What the server adds is a way to ask follow-up questions, connect the steps, and jump straight to the affected elements.

server.registerTool(
  "get_properties",
  {
    title: "Element properties",
    description:
      "Returns all property sets, quantities with units and the material " +
      "of one element. Use it to inspect an element found with list_elements.",
    inputSchema: z.object({
      version,
      guid: z.string().describe("IFC GlobalId of the element, 22 characters."),
    }),
    outputSchema: z.looseObject({
      summary: z.string(),
      guid: z.string(),
      property_sets: z.array(z.unknown()),
    }),
    annotations: { readOnlyHint: true, idempotentHint: true },
  },
  async ({ version, guid }) =>
    run("get_properties", { version, guid }, () =>
      elementProperties(catalog, version, guid),
    ),
);

The server is called ifc-review and exposes six tools, all read-only:

• get_model_summary: project, versions, stories, element counts
• list_elements: find elements by IFC class, story, or load-bearing flag
• get_properties: property sets, quantities, and materials of one element
• run_ids_check: validate a version against an IDS file
• compare_versions: what was added, removed, or modified between two versions
• get_viewer_link: a link that opens the 3D viewer with the relevant elements highlighted

Then I ran the test on a real model: a concept model of a residential building in Prague, with a street-level garage, three residential levels, and an attic, checked against an IDS file with 14 information requirements. I asked which requirements failed and which elements were affected. Two requirements failed on 13 elements: two roof windows without a thermal value and 11 doors without a fire rating. The door names said the fire rating would be set in the fire safety design. That explains why the value is missing. It doesn’t provide one, and whether the value is required at this stage is a decision for the project team.

For the test, I then prepared a second revision with some of the gaps filled in, and asked the question every team asks after a revision: what got fixed, and what’s still missing? The AI called the comparison and validation tools, and the results were matched by element ID. Ten of the 13 elements were fixed. Three doors on Residential Level 3 still lacked a fire-rating value in the required model property. Then the AI handed me a link that opened the model with exactly those three doors highlighted.

I ran the whole demo in two different AI apps: ChatGPT, and Gemini in Google Antigravity. In that test, both reached the same findings with the same server and the same tools. That doesn’t mean every AI app connects the same way; each product has its own setup and limits. But the server didn’t need to know which AI was asking. That is the point of a standard.

Writing the code was the easy part. Three things mattered more:

• Tool descriptions are the user interface. The AI picks tools by reading them, so they deserve the same care as button labels.
• Summaries beat data dumps. Return counts and the top results, with details on request. Sending the AI an entire model overloads its working memory and makes answers worse.
• Units and IDs, always. Every number carries its unit and every element its GUID. Ambiguity is where AI starts guessing again.

None of this replaces the checker. It makes the checker easier to question.

In under two years, MCP went from an experiment to a feature that major AEC vendors ship with their products.

Anthropic released the standard in November 2024. Since then, AEC vendors have started shipping MCP connections, each with its own scope and conditions:

• Revit (Autodesk): a read-only MCP server since June, joined in September by Trusted-Write and Experimental servers. All are technical previews for Revit 2027.
• Revu (Bluebeam): an MCP connection to Claude. It requires a Bluebeam Max plan, Revu 21.9 or later, and the Claude desktop app.
• SketchUp (Trimble): a Claude connector that creates new SketchUp models from a conversation. It can’t edit existing files, and Claude is currently the only supported AI provider.
• RFEM 6 (Dlubal Software): Dlubal introduced an MCP server for RFEM 6 in January 2026. It works through the Dlubal API and is installed separately under the current setup procedure. Details are in Dlubal’s knowledge base article and API documentation.

These products change quickly, so check the current conditions before you plan around them, and don’t assume any of them connects to every AI app out of the box.

Vendors also make different design choices. Some servers expose a few narrow, purpose-built tools. Others let the AI write scripts against the program’s API, much like a Dynamo or Grasshopper script, except the AI writes it. The reach depends on what the server exposes and the permissions behind it. Narrow tools give everyone safe defaults; scripting gives power users more reach, at the price of reviewing and testing the code the AI writes. My own server sits firmly at the narrow end.

Long-running jobs, such as a large analysis or a heavy model check, have their own pattern in MCP: Tasks. They started as an experimental feature, and the July 2026 specification moved them into an official extension. They only help when both the AI app and the server implement them.

MCP removes the friction between engineering judgment and its execution. It does not replace the judgment, and it brings a few new risks of its own.

• Responsibility stays put. Using AI doesn’t remove the engineer’s responsibility to review the result. The AI doesn’t stamp drawings, and how liability is allocated is a question for your contracts and legal advice.
• Garbage in, garbage out, faster. MCP automates a messy process just as faithfully as a clean one. Inconsistent parameters and missing classification codes (UniFormat, OmniClass) will surface sooner, not disappear.
• AI-written code needs review. When a server runs scripts that the AI writes, some of those scripts will be wrong. Review the code, test on a copy, and keep analysis results under version control.
• Know where the data goes. A local server keeps the model on your machine, but the AI host still sees whatever the tools return, and read-only access doesn’t change that. Check your AI provider’s data-retention and training terms before connecting live projects.
• Model data can carry instructions. A property value or a document comment can contain text that tries to steer the AI. Read-only access limits changes to the model; it doesn’t prevent misleading answers or data exposure. Start with a trusted server, restricted access, and a test model your firm has approved.
• It isn’t free. Budget for AI subscriptions, API access or add-on licenses on the software side, and workstations that can keep up.

How to start on Monday

Start small: one project, one read-only task, one person who’s curious. Before that, ask your software vendors five questions:

Then run a pilot. Choose one recurring task, such as checking a model revision against the project’s information requirements, and a test model your firm has approved. Compare your current workflow, including any checker you already use, with the AI-assisted version. Count the review time, missed issues, and false alarms as well as the time saved, and repeat it on another revision before deciding. That comparison will tell you more than any vendor demo.

MCP won’t design a building. What it does is let AI reach the tools that already do the engineering, so the hours between a question and its answer shrink.

Picture the next step. One outlet finds the elements that changed in the latest model revision. A second sends them on to the next tool, an analysis program or a coordination platform, provided the models and their element IDs are linked, which is still one of the hardest parts of the job. The AI connects the steps and puts the result in front of the person who decides. The pieces exist today; every step still needs someone who checks the result.

The AEC software we rely on is excellent at engineering. The AI platforms are excellent at language and reasoning. MCP is the outlet between them, and it’s worth learning how it works before your competitors do.

My own view: access to good building data helps AI answer questions about a specific project more effectively. I trust the large U.S. providers with it. Your contracts still set the rules for each project. In a few years, asking an AI about a model will be as ordinary as searching Google.

Prefer to listen? This article has a companion episode of the Insights podcast, built around the same test.

Insights Podcast · EP 02 · 14:05

Listen to the conversation

Martin and his co-host Sarah work through this article with a practical case, in English.

Play episode All episodes →

Chapters

1. 0:00The doors that don't exist
2. 0:21Welcome
3. 0:57An outlet, not a brain
4. 2:19Guessing vs. checking
5. 3:49"Have you actually tried it?"
6. 5:36Thirteen elements, three doors
7. 6:52One server, two AI apps
8. 8:03"Why give our data to big tech?"
9. 9:25The weekend GitHub server
10. 10:50Who's actually shipping this?
11. 11:43What do I tell my boss?
12. 13:09Close

TranscriptSynced with audio

MartinImagine asking an AI which doors are missing a fire rating. It gives you a perfect table. There's just one problem: none of those doors exist in your model.0:00 SarahThen how do you get an answer you can actually check?0:11 MartinWelcome back to Insights. I'm Martin Motlík. I work where software meets structural engineering. Today we're looking at the Model Context Protocol, or MCP, through a model-review test I built myself.0:21 MartinSarah is back as our fictional marketing lead at an engineering firm in Portland. Her boss has a question.0:36 SarahHe's forwarded another vendor email: "Should we be doing this MCP thing?" I need an answer I can take back to the team.0:43 MartinLet's work through it. What can it do, what still needs checking, and where would you start?0:51 SarahOkay, start from zero. What is it?0:57 MartinMCP is an open standard that lets AI apps connect to the software and data you already use. It doesn't make the AI smarter. It gives it a way to reach things outside itself. Your models, your analysis software, your project data.1:00 SarahSo, a plug.1:17 MartinPretty much. Picture the temporary power spider box on a jobsite. It doesn't care if you plug in a saw, a grinder or a work light, because every tool has the same plug. Before MCP, connecting an AI to a program meant custom wiring for every single pair.1:18 SarahAnd now?1:35 MartinNow software can expose its tools through an MCP server, and compatible AI apps can connect to it. You still need the right connection and permissions. Anthropic introduced the standard in late 2024.1:36 SarahWe pay for Copilot. So in that picture, Copilot is...1:49 MartinThe host. The app you type into. On the other side, a small server sits next to Revit, or next to the tool that reads your IFC files, and tells the AI what it can do.1:54 SarahTells it how?2:05 MartinEach tool has a description and a structured definition of its inputs. The AI uses those to choose a tool and supply the information it needs. The application controls which tools are available.2:06 SarahSo back to the doors. What would have been different?2:19 MartinThe AI would have a way to query the actual model. A tool can open the IFC file, find the doors and return their properties. We can check those results. The AI can still choose the wrong filter or misread an answer, so the connection alone doesn't make it reliable.2:22 SarahSo the AI is more of a coordinator.2:41 MartinExactly. Like a good BIM coordinator, actually. It doesn't author the model. It knows where to look, and it brings back the answer.2:44 SarahBut here's the thing. Copilot already reads our documents. Our BIM Execution Plan, our standards. Isn't that the same?2:53 MartinThat's a different tool, and a good one. The AI searches documents and quotes them. It answers "what does the BIM Execution Plan say?"3:01 SarahAnd MCP?3:10 MartinMCP can connect both kinds of tools. One searches your documents; another queries the model or runs a check. The useful difference is what the tool can do. Most serious workflows will use both.3:12 SarahGive me something real. What would our team actually ask?3:25 MartinFind the doors on level two with a missing fire-rating property, and show me where they are. Or total the concrete quantities in the slabs, floor by floor, if the model contains reliable quantities. Those are questions the connected tools can answer.3:29 SarahAnd the doors would have been real doors.3:45 SarahCan I be honest? Everything I read about this is a vendor demo. Have you actually tried it yourself?3:49 MartinI have. I'm building a model-review prototype, a web app for IFC models. It already checks models against information requirements and compares versions. So I wrote a small MCP server for it. Six tools, all read-only.3:56 SarahRead-only meaning...4:13 MartinIt can look, it can't touch. List elements, read their properties, run a check, compare two revisions, and hand me a link into the 3D viewer. That's it.4:15 SarahBut couldn't your model checker already do that without AI?4:26 MartinYes. The checker already did the validation. What I added was a way to ask follow-up questions, connect the steps, and jump straight to the affected elements.4:29 SarahAnd what did you test it on?4:39 MartinA real model. A residential building in Prague, a concept model with a garage, three apartment floors and an attic. Plus an IDS file with the project's data requirements.4:41 SarahIDS. Remind me?4:53 MartinIDS is a buildingSMART standard for expressing selected information requirements in a machine-checkable form. You specify which elements need which data. A checker then tests the model against those rules. It checks the information, not whether the building is correctly designed.4:56 SarahOh. That's literally what our BIM coordinator does every Friday before a submittal. By hand.5:14 MartinThen she'll like this part. I asked: check the model against the IDS file. Which requirements fail, and which elements are affected? Two requirements failed. Thirteen elements, mostly doors without a fire rating.5:21 SarahDoors with no fire rating. That sounds bad.5:36 MartinThe door names said the fire rating would be set in the fire safety design. That explained why the value was missing. It didn't actually provide a fire rating.5:40 SarahSo the check found a real gap, but it didn't tell you whether the design was wrong.5:50 MartinExactly. You also need to know whether that information is required at this project stage. The check flags the missing value. A person decides what it means.5:55 SarahThen what?6:06 MartinThen I prepared a second revision for the test, with some of the gaps filled in. And I asked the question every team asks after a revision: what got fixed, and what's still missing? Show me the rest in the model.6:07 SarahAnd?6:21 MartinThe AI called the comparison and validation tools, and the results were matched by element ID. Ten of thirteen fixed. Three doors on residential level three still without a fire rating. Then it gave me a link that opened the model, and there they were. Three doors highlighted, the rest of the building dimmed.6:22 SarahSo the doors in the chat and the doors on screen are the same doors.6:41 MartinSame element IDs. That's the part I'd show any project team first.6:46 SarahOkay, but which AI did you use? We're a Copilot shop.6:52 MartinI tested the same server with ChatGPT and with Gemini in Google Antigravity. In that test, both reached the same findings. That doesn't mean every AI app connects in the same way. With Copilot, you need to check the specific product and your company's setup.6:57 SarahWas building the server the hard part?7:15 MartinWriting the code wasn't the hard part.7:17 SarahWhat was?7:19 MartinThree things. First, the tool descriptions. The AI picks tools by reading them, so they're really the user interface. They deserve the same care as button labels.7:20 SarahCopywriting. Finally something in my lane.7:31 MartinHonestly, yes. Second, summaries beat data dumps. Return counts and the top results, with details on request. Send an AI a whole model and you overload its working memory. The answers get worse.7:35 SarahAnd third?7:50 MartinUnits and IDs, always. Every number carries its unit, every element its ID. Ambiguity is exactly where the AI starts guessing again.7:51 SarahHere's where I push back a bit. Why would we connect our projects to OpenAI or Google or Microsoft? Wouldn't it be safer to build our own chatbot?8:03 MartinFair question. Let me separate two things: where the model lives, and where the answers go. A local server keeps the model file on your machine. Only what the tools return goes to the AI.8:13 SarahWhich can still be a lot.8:27 MartinIt can. So check your provider's terms on data retention and training before you connect live projects. And some clients and contracts don't allow commercial AI services at all. Then you don't.8:29 SarahOkay. And the chatbot idea?8:43 MartinBuilding your own chatbot doesn't mean building your own language model. You can use the same commercial models behind a custom interface. The question is whether that interface solves a real problem for your team. MCP lets you reuse the engineering tools either way.8:45 SarahAnd my engineers already have Copilot open all day.9:03 MartinThen it makes sense to start with the interface they already use, if it supports the connection you need. A custom assistant may still be useful for a specific workflow.9:07 SarahSo it's not either-or.9:17 MartinNo. Keep the engineering tools reusable, then choose the interface that works for your team.9:19 SarahOkay, confession number two. One of our younger engineers found a community Revit server on GitHub and hooked it up to ChatGPT over the weekend. On a live project.9:25 MartinOf course he did.9:38 SarahOur IT guy is not amused.9:39 MartinYour IT guy has a point. I separate three kinds of access. First, reading: querying the model and pulling properties. That limits changes to the model, but the information can still be sensitive.9:42 SarahAnd the second?9:56 MartinChecking: IDS checks, clash reports, comparisons between revisions. People need to review the findings because they inform decisions. Third is writing: changing parameters or moving and creating elements. That needs controlled permissions and a way to review and undo changes.9:57 SarahAnd the GitHub server?10:16 MartinYou need to inspect what that particular server can do and what access it has. Autodesk now offers separate read, write and experimental server options as technical previews. The capabilities and permissions matter more than the label.10:18 SarahAnything else I should tell IT?10:32 MartinModel data can contain text that tries to steer the AI. Read-only limits changes to the model; it doesn't prevent misleading answers or data exposure. Start with a trusted server, restricted access and a test model your firm has approved.10:34 SarahWho is actually shipping this in our industry?10:50 MartinAutodesk has Revit servers in technical preview. Bluebeam connects Revu with Claude. Trimble has a SketchUp connector, and Dlubal provides access to its analysis applications. The capabilities, supported clients and licenses differ. But these are actual products you can evaluate.10:53 SarahDo they all give the AI the same kind of access?11:14 MartinNo. Some expose a few defined actions. Others let the AI write scripts against an API. The reach depends on what the server exposes and the permissions behind it.11:17 SarahWhich would you start with?11:29 MartinA small set of read-only tools for one task. Scripting can go further, but you need to review and test the code. I've linked the product details in the article, because those are changing quickly.11:31 SarahOkay. That email from my boss. And our senior engineer asked me to ask you one thing: who's liable if the AI gets it wrong?11:43 MartinUsing AI doesn't remove the engineer's responsibility to review the result. The AI doesn't stamp drawings. How liability is allocated is a separate question for the firm's contracts and legal advice.11:53 SarahSo we still need a review process. What else do I write back?12:07 MartinThat it won't clean up your data. It automates a messy process just as faithfully as a clean one. If your parameters are inconsistent, you'll just find out faster. And that it isn't free. AI subscriptions, and sometimes API access or add-on licenses on the software side.12:12 SarahAnd then?12:30 MartinThen a few questions for every vendor. Do you ship an MCP server, official or community? Is it read-only, and are read and write separated? Where does project data go? The full list is in the article.12:31 SarahAnd how do we know if it's worth it?12:44 MartinChoose one recurring task and a test model your firm has approved. Compare your current workflow, including any checker you already use, with the AI-assisted version. Count the review time, missed issues and false alarms as well as the time saved. Repeat it on another revision before deciding.12:46 SarahThat's our Friday model check.13:04 MartinThat's your Friday model check.13:06 SarahIf you had to sum it up in one sentence?13:09 MartinMCP lets AI reach the engineering tools we already use. We still need to verify the result.13:12 SarahAnd personally? Would you share your own models with these AI companies?13:20 MartinI would. Sharing building data with AI models is how they get better at our work, and I trust the large U.S. providers with it. Your contracts still set the rules for each project. In a few years, asking an AI about a model will be as ordinary as searching Google.13:24 SarahAnd the first question to take back to the office?13:41 MartinPick one question you ask about a model every week. Check whether your existing software can expose the answer, and how your team would verify it.13:44 SarahIn the article, you can see the tool result and the same three doors highlighted in the model. It's on martinmotlik.com, under Insights.13:53 MartinThanks for listening. See you in the next one.14:01

Episode produced with AI voices from this article. Script reviewed by Martin.

Martin Motlík

Independent AEC digital strategist and Head of Web Content at Dlubal Software. Writing about AI, BIM and engineering-software marketing.

Keep reading

AI in AEC Be the source: getting AEC data ready for AI search Oct 6, 2026 · 8 min read · Podcast 14 min

All insights →