Skip to content

A Modular Reference Architecture for MCP-Servers Enabling Agentic BIM Interaction

🕒 Published (v1): 2025-12-21 23:12 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

This paper proposes a modular microservice reference architecture for MCP servers targeting agentic BIM (Building Information Modelling) workflows, explicitly decoupling the LLM-facing MCP interface from specific BIM authoring APIs via an abstract adapter contract. A prototype using IfcOpenShell demonstrates feasibility across six IFC model generation and modification tasks. The work addresses the fragmented, monolithic state of existing BIM-MCP implementations by providing a reusable, backend-agnostic foundation.

Problem

Existing LLM-based agentic BIM systems repeatedly re-implement the same core capabilities (querying, creating, modifying IFC elements; file management; validation) in monolithic, tool-specific code tightly coupled to a single BIM backend (e.g., Revit, Bonsai, IfcOpenShell). Even when MCP is used as the agent-facing interface, the server-side BIM logic remains monolithic and non-portable, preventing reuse, systematic evaluation, and cross-backend generalization.

Method

The architecture decomposes BIM interaction into seven core capability categories (C1–C7: file/storage management, BIM execution, knowledge provision, user-model interaction, information retrieval, validation, and multimodal I/O) and maps each to a dedicated containerized microservice. The central mechanism is an explicit BaseAdapter abstract contract that defines a minimal API for BIM backends (load, save, diff, create/query/modify). The MCP server exposes three public endpoints (/mcp, /viewer, /bucket) and communicates with an isolated BIM execution container via three JSON-schema-validated HTTP endpoints (/create, /query, /modify). All state is externalized to versioned S3-compatible object storage (MinIO); each operation returns a structured Artifact with a DiffRaw/DiffSummary for transparent multi-step reasoning. The agent follows a ReAct-style loop; the MCP tool catalogue is organized hierarchically into low-level (direct adapter calls) and high-level (task-encapsulating) BIM tools. The prototype is implemented with FastMCP/FastAPI for the MCP server, Flask for the BIM execution container, Weaviate+Ollama for vector-based knowledge retrieval, and IFCOpenShell as the concrete BaseAdapter implementation.

Key Contributions

  • Systematic taxonomy of seven recurring capability categories across 12 agentic BIM workflow papers, demonstrating consistent but monolithically coupled re-implementation.
  • A modular microservice reference architecture with an explicit BaseAdapter adapter contract that decouples MCP tool surface from any specific BIM authoring backend.
  • Containerized BIM execution isolation: all BIM API logic runs in a sandboxed service; the MCP server is backend-free.
  • Structured Artifact/Manifest/DiffRaw/DiffSummary output format enabling reproducible, inspectable multi-step agent reasoning.
  • A working IfcOpenShell-backed prototype implementing four of seven capability categories, evaluated on six IFC generation/modification scenarios (30 total runs).

Results

  • Tool-success rate: 100% across all six test cases and all five repetitions (30 runs).
  • IFC schema validity: 100% across all runs; industry-practice compliance: 100% across all runs.
  • Model success rate (rule-based correctness): ranges from 40% (tc_du_et_al_3, 4-story house) to 100% (tc_du_et_al_6, tc_new_1, tc_new_2).
  • Manual review scores (5-level scale): 2.7 (tc_du_et_al_3) to 5.0 (tc_new_2); complex spatial tasks (L-shaped, multi-story) score lower due to LLM geometric reasoning limitations, not architectural failures.
  • Token usage per run: 203K–686K tokens (gpt-4o-mini); reasoning steps: 13.6–26.8 per run.
  • No comparative baseline against monolithic MCP servers; evaluation is explicitly scoped as feasibility/non-regression only.

Limitations

  • Single BIM backend evaluated (IfcOpenShell); service exchangeability and backend-agnosticism are demonstrated architecturally but not empirically validated with a second backend (e.g., Revit).
  • Single-agent ReAct setup; multi-agent orchestration (as in the original Text2BIM) not evaluated; model-checking loop omitted.
  • Stateless, sequential interaction model precludes parallel tool calls or concurrent model modifications.
  • Only four of seven capability categories are implemented; Model Validation & QA, Multimodal I/O, and semantic Information Retrieval & Exploration remain unimplemented.
  • No benchmarking against monolithic MCP servers; properties like modularity and scalability are argued architecturally, not measured.
  • Commercial BIM tools (Revit, Archicad) require additional remote-bridge adapters beyond simple headless API access.
  • Geometric/spatial reasoning failures (coordinate handling, relative placements) reflect LLM limitations but affect output quality at current capability levels.

Relevance to Harnesses / Meta-Harnesses

This paper directly instantiates a domain-specific meta-harness pattern: the MCP server acts as an orchestration layer that routes abstract tool calls to swappable backend executors via an explicit adapter contract, mirroring the harness-level concern of decoupling workflow logic from execution environment. The BaseAdapter contract, containerized execution isolation, versioned artifact store, and structured diff outputs are all canonical harness design elements—analogous to how general-purpose meta-harnesses separate task specification, executor, and state management. For researchers building harnesses over LLM tool-use, this paper provides a concrete, evaluated template for how to structure backend isolation, tool hierarchy (low-level primitives vs. high-level abstractions), and reproducible multi-step state management when domain APIs are heterogeneous and non-portable.