---
title: 'MCP4IFC: IFC & LLM Integration Platform'
url: https://www.emergentmind.com/topics/mcp4ifc
type: topic
---

# MCP4IFC: IFC & LLM Integration Platform

Searching arXiv for the cited MCP4IFC and MCP security papers to ground the article.
MCP4IFC is an open-source framework for IFC-based building design with large language models, built around the Model Context Protocol as the interface between an AI client and BIM operations on Industry Foundation Classes data. It is intended to let an LLM query, create, and edit IFC models directly rather than through proprietary authoring APIs or preprocessed database surrogates, and it combines a fixed BIM tool library with dynamic code generation and retrieval-augmented generation for tasks beyond the predefined toolset [2511.05533].

## 1. Conceptual scope and motivation

MCP4IFC is situated at the intersection of openBIM, LLM tool use, and agentic design workflows. Its immediate problem setting is the complexity of IFC as the neutral open BIM standard defined in ISO 16739-1:2024: IFC encodes hundreds of entity types, geometric and topological structure, spatial hierarchies such as project-site-building-storey-space, and a wide range of properties and relationships. In existing practice, creating and editing IFC models remains dominated by GUI-based BIM systems such as Revit, Vectorworks, and Archicad, typically operated by expert users [2511.05533].

The framework is motivated by three limitations identified in recent LLM+BIM systems. First, many systems are written against proprietary APIs and therefore exhibit vendor lock-in. Second, many do not operate on IFC itself, which weakens interoperability. Third, most frameworks emphasize either querying or generation/editing rather than both, so capability expansion often requires bespoke engineering. MCP4IFC addresses these limitations by exposing BIM functions at the IFC level through IfcOpenShell while using MCP to standardize tool discovery and invocation [2511.05533].

A common misconception is that MCP4IFC is merely a natural-language query layer over IFC. The framework is explicitly designed for unified query, edit, and generation. It exposes scene-query tools for information retrieval, predefined functions for creating and modifying common building elements, and a dynamic code-generation system with in-context learning and retrieval-augmented generation for operations not already captured by the fixed tool library [2511.05533].

## 2. System architecture and execution model

The architecture comprises three main components: an AI client, an MCP server implemented in Python, and a Blender environment extended with Bonsai and IfcOpenShell. The AI client can be any MCP-aware LLM frontend, such as Claude Desktop. It communicates with the MCP server via JSON-RPC, receives tool metadata, and orchestrates tool calls. The MCP server implements the MCP specification, validates tool arguments against JSON Schema, and forwards valid requests to Blender through a socket. Inside Blender, the add-on uses IfcOpenShell for IFC creation, querying, editing, and I/O, while Bonsai maps IFC entities to Blender meshes and synchronizes geometry [2511.05533].

This design makes MCP the integration layer between the LLM-facing interface and the BIM back end. The AI client sees tool names, descriptions, and schemas rather than application-specific APIs. The server side can therefore be swapped or extended without changing the client-side interaction model. The paper explicitly notes that the client only needs to know that a tool such as `create_wall` exists with a given argument schema, while the implementation can remain Blender+IfcOpenShell or be adapted to other systems such as Revit-mcp or openbim-mcp [2511.05533].

The operational workflow is a structured natural-language-to-IFC loop. When the client connects, it requests tool discovery and receives a JSON description of the server’s capabilities. The client injects this catalog into the system prompt so that the LLM can select appropriate tools. For a prompt such as adding a wall with specified endpoints, height, and thickness, the model chooses a tool such as `create_wall`, constructs JSON arguments, and sends a JSON-RPC call. MCP4IFC validates those arguments, forwards the command to Blender, and the Blender add-on invokes IfcOpenShell to create the corresponding `IfcWall`, update spatial placement, and synchronize geometry. The add-on returns status information and GUIDs, which are wrapped into a JSON-RPC response for the client. The model can then continue reasoning, report the result, or chain further operations such as inserting a door into the created wall [2511.05533].

This execution model also clarifies where state resides. Tool definitions persist in the system prompt, the IFC model state lives in Blender and IfcOpenShell, and task context is maintained by the LLM in conversational memory. A plausible implication is that MCP4IFC treats model reasoning, protocol-level tool use, and IFC model mutation as distinct but tightly coupled layers.

## 3. Tool model and interaction with IFC data

MCP4IFC exposes more than 50 BIM tools organized into three broad categories: scene query and context tools, predefined IFC modeling and editing tools, and dynamic tools for code execution and retrieval. The query layer is designed to present compact, LLM-friendly summaries instead of raw IFC STEP text, which the framework treats as too long and noisy for effective direct use by current models [2511.05533].

Representative query tools include `get_scene_info`, `get_ifc_scene_overview`, `get_object_info`, and specialized property tools such as `get_door_properties`. `get_scene_info` returns structured JSON with counts, pagination fields, object names, Blender types, locations, visibility, selection state, GUIDs, and IFC classes. These tools expose both spatial structure entities such as `IfcProject`, `IfcSite`, `IfcBuilding`, and `IfcBuildingStorey`, and ordinary building elements such as walls and slabs. They support geometric queries, semantic queries, property inspection, and spatial relationship reasoning, with more complex logic delegated to generated code when necessary [2511.05533].

The predefined modeling layer provides higher-level wrappers over IfcOpenShell for common elements. The paper lists `create_wall`, `edit_wall`, `delete_wall`, `create_slab`, `create_roof`, `create_window`, `create_door`, and `create_stairs`, together with related variants. Straight walls are created from start and end points plus height and thickness; chained walls can be created from a polyline. Slabs are created from a closed polygon outline, thickness, and elevation. Doors and windows take a `host_wall_guid`, geometric dimensions, and a placement parameter along the host wall, then create an `IfcDoor` or `IfcWindow` with associated opening relationships to varying degrees of semantic completeness. Stair creation is parameterized by step count, riser height, tread depth, total height, and outline [2511.05533].

All of these tools are surfaced through MCP with JSON Schema signatures. A typical tool definition includes a name, description, input schema with typed properties and required fields, and an output schema describing fields such as `guid` and `status`. This standardized schema exposure is central to the framework’s use of in-context learning: the LLM infers invocation patterns from structured tool descriptions rather than task-specific finetuning [2511.05533].

At the data layer, IFC remains the source of truth. Query tools are implemented through IfcOpenShell operations such as `by_type`, `by_guid`, and relationship traversal. Modifications use entity creation, attribute editing, and relationship management through `ifc_file.create_entity(...)` or higher-level `ifcopenshell.api.run(...)` calls. After changes, `save_and_load_ifc()` writes the modified file and reloads it into Bonsai to keep Blender geometry synchronized. The predefined tools are described as carefully coded to create valid IFC entities, place them correctly in the Project-Site-Building-Storey hierarchy, and maintain consistent units and coordinates [2511.05533].

## 4. Dynamic code generation, RAG, and multimodal context

A defining characteristic of MCP4IFC is that it does not restrict the model to a closed tool vocabulary. The main dynamic mechanism is `execute_ifc_code_tool`, which allows the LLM to generate Python code that imports `ifcopenshell`, `ifcopenshell.api`, and Blender add-on helpers such as `get_ifc_file` and `save_and_load_ifc`, executes IFC operations, saves the model, and returns logs to the model. The paper provides a complete generated example in which Claude Sonnet 4.5 changes a building description to `"High-rise residential tower"` by retrieving the building by GUID and invoking `attribute.edit_attributes` through IfcOpenShell’s API [2511.05533].

For geometric tasks beyond the fixed tool library, MCP4IFC also exposes `execute_blender_code`. This path supports more general Blender and geometry workflows, including the use of `trimesh` to generate meshes procedurally, convert them into Blender geometry, and wrap them as IFC entities such as `IfcBuildingElementProxy` or more specific classes when appropriate. The paper associates this mechanism with freeform or less conventional structures, including the “landmark bridge” example [2511.05533].

The framework further augments code generation with retrieval-augmented generation through `search_ifc_knowledge`. A vector store contains IfcOpenShell documentation, IFC schema information, and example scripts. When the LLM lacks API-level certainty, it can first retrieve relevant snippets and then synthesize a new script for execution. The paper explicitly frames this as a RAG pattern analogous to Lewis et al. (2020): parametric model knowledge is supplemented by non-parametric retrieval without additional training [2511.05533].

MCP4IFC also incorporates multimodal scene context. Screenshot tools such as `capture_blender_3dviewport_screenshot` return images or paths that the LLM can use for visual verification, counting, or layout questions. This is not a replacement for IFC querying; rather, it complements structured scene summaries with visual feedback when geometry inspection is useful. This suggests that the framework is not only IFC-native but also designed for mixed symbolic and perceptual interaction with BIM scenes.

## 5. Experimental results and demonstrated workflows

The paper evaluates MCP4IFC across querying, semantic editing, and geometry generation. For scene querying, it uses a 65-question subset of IFC-bench-v1 on the Duplex dwelling IFC, divided into 27 direct, 16 indirect, and 22 insufficient-information questions. Correctness is assessed manually rather than with an LLM judge [2511.05533].

| Category | GPT-5 mini | Sonnet 4.5 |
|---|---:|---:|
| Direct (27) | 25 / 27, 92.6% | 21 / 27, 77.8% |
| Indirect (16) | 7 / 16, 43.8% | 7 / 16, 43.8% |
| Insufficient (22) | 22 / 22, 100% | 21 / 22, 95.5% |
| Total (65) | 54 / 65, 83.1% | 49 / 65, 75.4% |

The paper also reports Sonnet 3.5 results from Hellin et al. on a larger dataset, noting that the comparison is not strictly like-for-like. Within MCP4IFC’s own experiments, direct queries are handled well, insufficient-information questions are handled very well, and indirect queries requiring aggregation or multi-step reasoning are the most difficult. Tool usage statistics for correct Sonnet 4.5 tasks show that `execute_ifc_code_tool` dominates with 91 calls, followed by `get_ifc_scene_overview` with 45, `get_scene_info` with 29, `get_object_info` with 16, `execute_blender_code` with 7, and `search_ifc_knowledge` with 2. The prominence of generated code indicates that the dynamic layer is central rather than peripheral to complex querying [2511.05533].

For semantic editing, the framework is tested on `BasicHouse.ifc` from the bim-whale IFC samples using Claude Sonnet 4.5. The eight tasks include renaming walls to encode height, changing the building description, appending floor levels to door names, adding a `Thermal_Properties` property set to all walls, assigning `Fire_Rating = "2HR"` to slabs, assigning Uniclass 2015 codes, adding window cost information and computing total cost, and updating owner history for selected elements. All eight tasks are reported as completed successfully, with changes verified manually by diffing IFC files before and after execution [2511.05533].

Geometry generation is evaluated in both single-prompt and multi-turn settings. Single-prompt examples include a two-storey structure with slabs, walls, and a gable roof; a curved wall approximated by eight segments; a three-storey apartment block with rooms; a university campus with multiple buildings and covered walkways; a landmark bridge with arches and deck; and a ten-room single-floor house with furniture. A multi-turn workflow incrementally constructs an L-shaped building by creating a slab, adding perimeter walls, inserting a door, creating a second-floor slab at 3.5 m, adding a hip roof with 30° slope, and styling the house through Blender code [2511.05533].

Additional experiments extend beyond direct IFC editing. For floor-plan understanding from Tell2Design images, the framework captures the overall wall layout structure but loses fine spatial detail. For visual question answering over six BIM screenshots and 40 questions, Claude Sonnet 4.5 achieves approximately 73% under a 1.0/0.5/0.0 scoring rubric, while comparative tests with GPT-5, GPT-5 mini, and Gemini 2.5 Flash/Pro show mixed strengths across models [2511.05533].

## 6. Limitations, protocol context, and significance

MCP4IFC’s limitations are explicit and technically important. Predefined tools cover core building elements but not the full IFC schema, particularly detailed assemblies and MEP systems. Geometric complexity remains modest in the fixed tool library, with freeform geometry delegated to generated code. Most significantly, the paper states that semantic completeness of generated IFC is weaker than geometric plausibility: generated models may omit `IfcSpace` definitions, fail to model wall intersections perfectly, mishandle door and window openings, or lack rich property sets, materials, and containment relationships for furniture [2511.05533].

Another constraint is orchestration cost. All tool descriptions together consume approximately 40k tokens, and the experiments indicate that only about 10 tools were actually needed for scene querying. The authors therefore identify tool preselection, more compact prompt formats, and adaptive tool descriptions as future directions. They also propose expanded high-level tool libraries, agentic BIM workflows, BIM-specialized LLMs trained on IFC corpora and tool traces, and extension to other BIM software through the same IfcOpenShell-centered abstraction [2511.05533].

Within the BIM literature, MCP4IFC is positioned as MCP-centric and IFC-native. Its novelty claim is not simply that an LLM can drive BIM software, but that MCP provides a standardized tool interface while IfcOpenShell provides an open IFC engine, yielding a portable and vendor-neutral basis for natural-language BIM interaction. The framework’s broader potential impact includes natural-language access to BIM for engineers, project managers, and clients; rapid textual prototyping for early design; and automated property enrichment, classification, compliance-style checks, and consistency audits via generated scripts [2511.05533].

The protocol context matters as well. MCP4IFC relies on MCP as the mediation layer between LLMs and external tools, and broader MCP research has shown that this ecosystem introduces substantial security considerations when deployments become remote or when server metadata is treated as trusted input. Measurement work on real-world remote MCP servers identifies widespread authentication flaws, including unauthenticated tool exposure and pervasive weaknesses in OAuth-based deployments [2605.22333]. A separate ecosystem study reports vulnerabilities spanning hosts, servers, and registries, including tool poisoning, tool shadowing, and server hijacking risks in public registries [2510.16558]. These results are not claims about MCP4IFC specifically. A plausible implication is that MCP4IFC-like infrastructures benefit from the interoperability and extensibility of MCP while also inheriting the need for careful governance, deployment hardening, and validation around dynamic tool execution and server trust boundaries.

In that sense, MCP4IFC marks a specific research direction rather than a closed product category: it demonstrates that LLMs can already perform meaningful IFC scene querying, semantic editing, and geometry generation over real IFC models, while simultaneously exposing the remaining gaps in semantic fidelity, geometric reasoning, orchestration efficiency, and secure protocol integration [2511.05533].

Source: https://www.emergentmind.com/topics/mcp4ifc