MCP4IFC: IFC & LLM Integration Platform

• MCP4IFC is an open-source framework that integrates LLMs with IFC-based BIM by standardizing tool discovery and invocation via the Model Context Protocol.
• It leverages IFC-native operations through IfcOpenShell and dynamic code generation to enable natural-language querying, editing, and generation of building models.
• The framework promotes vendor neutrality and interoperability by exposing standardized BIM tools while addressing orchestration and security challenges.

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 LLMs, 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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Nithyanantham et al., 29 Oct 2025).

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 (Zhou et al., 21 May 2026). A separate ecosystem study reports vulnerabilities spanning hosts, servers, and registries, including tool poisoning, tool shadowing, and server hijacking risks in public registries (Li et al., 18 Oct 2025). 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 (Nithyanantham et al., 29 Oct 2025).