Abstract
Integrating generative AI into Architecture, Engineering, and Construction (AEC) workflows requires systems that can translate natural language instructions into reliable actions on standardized building data models. We present an open-source, tool-based framework that enables Large Language Models (LLMs) to directly query, create, and edit Industry Foundation Classes (IFC) building models. The framework includes predefined parametric tools for creating and modifying common building elements, a dynamic code generation system for handling tasks beyond the fixed toolset, and retrieval-augmented generation (RAG) to support code generation using relevant IFC documentation. All tools are exposed through JSON schemas and can be invoked by any MCP-compatible LLM client, providing an extensible interface for IFC manipulation without relying on proprietary BIM APIs. Evaluated with Claude Sonnet 4.5 and GPT 5.4, the framework achieves up to 86% accuracy on a custom benchmark and 73.3% on the IFC-bench-v1 querying benchmark, showing significant improvements over baseline approaches. We also demonstrate multi-turn design workflows, analyze common failure modes, and release the framework as open source for research and development.
News
- 2026
- New paper: IFC-Copilot: A Tool-Based Framework for LLM-Driven IFC Building Design.
- Nov 2025
- MCP4IFC preprint released on arXiv.
Motivation: BIM Tools Are Built for Humans, Not for LLMs
BIM software already ships with powerful primitive tools: the Bonsai add-on in Blender, Revit, and other authoring environments all provide operations like create wall or set properties that let a designer start working immediately, and free-form flexible tools for more complex tasks. The problem is that these primitives are not single-step operations: they pass Python objects and internal state between each other, spread one action over several GUI steps, and are therefore not directly usable by LLMs. LLMs are text in, text out. They need well-defined function calls with explicit parameters and structured results. Designing new tools, or adapting the existing ones, specifically for LLMs is the main goal of this work, and it is what makes LLM-driven BIM editing work reliably.
The goal
Enable natural-language design, such as “add an entrance door to the south wall”, executed directly on the open IFC standard.
The problem
BIM software is built for mouse-and-menu interaction, and existing AI-BIM systems depend on proprietary APIs. LLMs need self-describing functions with typed parameters and structured results.
Our approach
Convert multi-step GUI interactions into single, LLM-ready tool calls operating directly on IFC, focused on the 3D design phase and semantic editing.
create_wall(**params) tool call.Design principles for LLM-ready tools
- Self-describing. Every tool ships a name, a natural-language description, and a JSON Schema, making it usable through in-context learning without model training.
- One tool, one operation. Clearly defined parameters, single responsibilities, and structured JSON outputs improve reliability in multi-step workflows.
- Encode domain knowledge. Tools bake in correct IFC patterns (spatial containment, geometric representations), so the LLM only supplies parameters.
- Feedback loops. Every call returns a success status, element GlobalIds, and diagnostics, allowing the LLM to observe, diagnose, and correct itself.
Why MCP?
The Model Context Protocol is a standard for connecting AI applications to external tools, data, and services. Delivered as an MCP server, the same IFC tools work with any MCP-compatible LLM client: reusable tools with consistent behavior across models, and no per-LLM integration overhead.
Three-Tier Architecture
IFC-Copilot consists of three separate programs on one machine, connected over local links: an LLM agent (any MCP-compatible client), the IFC-Copilot MCP server exposing the tools, and Blender with the Bonsai add-on where the IFC model is edited. Inside the server, three complementary tiers cover everything from routine element creation to fully custom IFC edits:
1 Predefined parametric tools
Structured tools for scene query, element creation and modification, materials and styles, and visual feedback. They encode correct IFC patterns, return GlobalIds for chaining, and replace verbose code with compact tool calls.
2 Dynamic code generation
For tasks beyond the fixed toolset, the LLM writes and executes IfcOpenShell Python at runtime in a restricted sandbox (blocked file/network access, execution timeouts), receiving structured feedback to iteratively correct failures.
3 RAG knowledge system
IfcOpenShell documentation (30+ modules) indexed in a ChromaDB vector store grounds generated code in correct
API usage, accessed through semantic search tools such as search_ifc_knowledge.
The Toolset: 52 Tools in 7 Categories
Each tool is a single, self-describing operation with a JSON Schema interface. Browse the full toolset below; click any tool for details.
Tool names and one-line descriptions follow the paper’s taxonomy (Table 1); see the repository for full, up-to-date schemas.
Representative interface; see the repository for the full JSON schema.
Results
Experiment 1 Custom IFC benchmark
Setup
- 100 tasks: 44 retrieval, 30 creation, 26 editing, across three IFC models of varying complexity.
- Three settings: Code-Once (a single code block, no execution feedback), Code-Exec (iterative code execution with error feedback), and All Tools (the full suite of 52 tools).
- Scored automatically with the IfcTester library; evaluated with Claude Sonnet 4.5 and GPT 5.4.
Results: overall accuracy and output tokens
Claude Sonnet 4.5
GPT 5.4
Tokens: total output tokens generated across all 100 tasks. All Tools matches the accuracy of Code-Exec at 2.3× (Sonnet 4.5) and 2.6× (GPT 5.4) fewer output tokens, and lifts complex-task accuracy from 39.0% to 80.5% with Sonnet 4.5.
Experiment 2 Scene querying on IFC-bench-v1
Setup
- 103 questions from the public IFC-bench-v1 benchmark, answered with the full toolset and no task-specific tuning.
- Three models compared: GPT-5.4, Claude Sonnet 4.5, and GPT-5 mini.
- Question categories: direct (read straight from the model), indirect (requires aggregation or computation), and insufficient (the answer is not in the model and must be recognized as unanswerable).
Results: accuracy by category
| Category | GPT-5.4 | Sonnet 4.5 | GPT-5 mini |
|---|---|---|---|
| Direct (44) | 81.8 | 77.3 | 70.5 |
| Indirect (30) | 40.6 | 40.0 | 36.7 |
| Insufficient (29) | 96.6 | 96.6 | 86.0 |
| Total (103) | 73.3 | 71.8 | 65.0 |
Accuracy in %. Models reliably detect whether information exists in the model; indirect questions that combine multiple values remain the hardest at around 40%.
Experiment 3 IFC generation and interactive workflows
Setup
- One generative prompt per building structure, run through Claude Desktop as the LLM client.
- Two settings compared: the full toolset vs. code execution only.
- Multi-turn workflows tested by building structures incrementally over several instructions.
Results: coherence of generated geometry
Findings
Execution feedback matters most
Letting the model observe errors and revise lifts Sonnet 4.5 from 53.2% to 86.0%.
Tools cut cost
Predefined tools match code-generation accuracy with 2.3-2.6× fewer output tokens.
Complex tasks benefit most
On complex tasks, Sonnet 4.5 improves from 39.0% to 80.5% with the full toolset.
Aggregation is the bottleneck
Indirect questions that combine multiple values stay around 40% across all models.
Structured tools yield coherent geometry
Predefined tools produce connected structures where code-only synthesis often fails.
Open and portable
IFC-native and MCP-based, so it works with any LLM client and IFC-compatible platform.