🤖 Authored 100% by AI Agent (Antigravity powered by Gemini 3.8 Flash):
This iconic architectural masterpiece was not coded by hand line-by-line! Instead, an autonomous AI Coding Agent (Google Antigravity powered by Gemini 3.8 Flash) researched historical blueprints, structural grids, and architectural dimensions of the Farnsworth House, synthesized the declarative YAML specification (project.yaml), computed material quantities (QTO), and compiled standard IFC4 building models in seconds — proving that humans don't need to manually code YAML when assisted by AI agents!
"debim originated from a simple desire: to make AI calculate accurate Bills of Quantities (BOQ). Asking an LLM to guess building dimensions directly in text leads to fatal hallucinations. An exact mathematical model (BIM) is essential, yet traditional IFC files are bloated and overwhelm AI context windows. The solution is Declarative YAML — but the resulting Building-as-Code engine proved far more transformative than our initial goal."
Traditional BIM tools (like Revit or Archicad) were conceived over 25 years ago for humans clicking with computer mice. They lock architectural data inside heavy, proprietary gigabyte files (.rvt), charge thousands of dollars in annual licenses, and remain completely opaque to modern automation and AI agents.
debim is built on 5 Core Architectural Tenets:
Building-as-Code & Git-Native: Buildings are software. Expressed as compact YAML (Kilobytes, not Gigabytes) for transparent Version Control, line-by-line Git diffs, and branching.
Deterministic Code Compliance: Building codes and engineering regulations are treated as automated Unit Tests (pytest), catching setback violations and structural errors in 0.01 seconds before ground is broken.
Zero-License & Zero-Friction Visualization: Instant geometric verification through lightweight 3D HTML viewers that load in any browser or mobile device in 2 seconds without expensive licenses.
Universal Bridge & Dual Representation: Seamlessly connects 2D drafts, 3D DCC tools (Blender/SketchUp), and open IFC standards using a dual approach: 90% geometric primitives for engineering/BOQ + 10% baked GLB assets for architectural refinement.
Human & AI Super-Collaboration: Designed with explicit uncertainty flags (review_status: needs_review), enabling humans and autonomous AI agents to co-author and verify building models without friction.
Related MCP server: ifc-mcp
If you use an AI coding assistant (like Antigravity, Cursor, Claude Code, Jules, or ChatGPT/Copilot), you don't even need to install it manually!
Just copy and send this prompt to your AI:
"Please read https://github.com/PRIDA-TAKON/debim and
AGENTS.md, install debim in my environment, and rundebim --helpto verify."
Your agent will inspect the repository, install the dependencies, and verify everything automatically.
debim natively implements the official Model Context Protocol (MCP) via FastMCP (Python SDK). It provides LLMs and AI Agents (such as Claude Desktop, Cursor, Cline, Windsurf, Devin, and Antigravity) with deterministic tools to model, inspect, calculate, compile, and visualize buildings directly via function calling.
Add debim to your MCP configuration (claude_desktop_config.json or .cursor/mcp.json):
{
"mcpServers": {
"debim": {
"command": "debim",
"args": ["mcp"]
}
}
}Or run via Docker:
{
"mcpServers": {
"debim": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/prida-takon/debim:latest"]
}
}
}MCP Tool | Description | Input Parameters |
| Validates YAML manifest syntax, structural grid alignments, storey heights, and material references. |
|
| Computes deterministic Quantitative Take-Off (concrete vol, formwork area, rebar kg, structural steel, timber, masonry). |
|
| Extracts materials used by the building model and generates a minimal project-scoped price catalog template. |
|
| Maps QTO quantities against unit prices, calculates total project cost, and optionally exports BOQ to CSV. |
|
| Compiles declarative YAML into an open, standardized buildingSMART IFC4 model ( |
|
| Generates a standalone, zero-dependency interactive 3D WebGL HTML viewer with section cut and layer tree. |
|
# Start MCP server over stdio
debim mcpInstall directly from PyPI:
# Standard installation
pip install debim
# Or with full IFC compiler support
pip install "debim[ifc]"Or install in editable mode from source:
git clone https://github.com/PRIDA-TAKON/debim.git
cd debim
pip install -e ".[ifc,dev]"# Initialize a new project
debim init my-project
# Validate schema syntax & grid references
debim validate -m examples/farnsworth_house/project.yaml
# Run automated building code compliance checks (pytest)
debim test
# Calculate Quantitative Take-Off (Steel weight, stone volume, glass area)
debim qto -m examples/farnsworth_house/project.yaml
# Generate project-scoped price template with international classifications
debim cost template -m examples/farnsworth_house/project.yaml -o prices.template.yaml
# Estimate project budget & export BOQ to CSV
debim cost -m examples/farnsworth_house/project.yaml -p examples/farnsworth_house/prices.yaml -o dist/boq.csv
# Scaffold a new BIM element class boilerplate
debim scaffold element IfcRailing
# Preview 3D model in your browser (Three.js with Hierarchical Layer Explorer)
debim view -m examples/farnsworth_house/project.yaml
# Compile declarative YAML to standard IFC4 building model
debim compile -m examples/farnsworth_house/project.yaml -o dist/farnsworth_house.ifc
# Launch Model Context Protocol (MCP) server over stdio
debim mcpproject.yamlschema: IFC4-Minimal
project:
id: PRJ-2026-001
name: "Townhouse-Feasibility"
units: { length: METER, area: SQUARE_METER, volume: CUBIC_METER }
# 1. Spatial Structure
spatial_structure:
storeys:
- id: L1
name: "Level 1"
elevation: 0.00
height: 3.50
- id: L2
name: "Level 2"
elevation: 3.50
height: 3.20
# 2. Reference Grid Axes
grids:
axes_x: { A: 0.00, B: 4.00, C: 8.00 }
axes_y: { 1: 0.00, 2: 5.00, 3: 10.00 }
# 3. Materials
materials:
- id: CONC_240
name: "Concrete 240 ksc"
category: concrete
unit_cost_ref: "MAT-CONC-01"
- id: AAC_75
name: "AAC Block 7.5cm"
category: masonry
unit_cost_ref: "MAT-AAC-01"
# 4. Elements
elements:
# Column placed at grid intersection [A, 1]
- class: IfcColumn
tag: C-A1
material: CONC_240
profile: { shape: BOX, width: 0.20, depth: 0.20 }
placement:
grid: [A, 1]
base_storey: L1
top_storey: L2
reinforcement:
main: "4-DB16"
stirrups: "RB6 @ 0.15m"
# Beam spanning between [A, 1] and [B, 1]
- class: IfcBeam
tag: B-A1_B1
material: CONC_240
profile: { shape: BOX, width: 0.20, depth: 0.40 }
placement:
from_grid: [A, 1]
to_grid: [B, 1]
storey: L2
reinforcement:
main_top: "2-DB16"
main_bottom: "3-DB20"
stirrups: "RB9 @ 0.15m"
# Wall with door host-child relationship
- class: IfcWall
tag: W-A1_A2
material: AAC_75
thickness: 0.075
height: 3.10
placement:
from_grid: [A, 1]
to_grid: [A, 2]
storey: L1
children:
- class: IfcDoor
tag: D1
dimensions: { width: 0.90, height: 2.00 }
offset_distance: 1.20debim prioritizes engineering precision and reproducible open science on our Kaggle Cloud Multi-Core Benchmark Suite:
Evaluating blind 3D geometric fidelity against ground-truth IFC models using Geometry Variant Deduplication + Balanced Macro-Averaging across 4,695 representative building elements:
🎯 85.50% Median Visual Fidelity: Surpassing the international standard benchmark ($\ge 85%$) across the majority of test suites.
🏗️ 89.07% Structural Match: Primary load-bearing elements (columns, beams, slabs, foundations) maintain Grade-A+ geometric alignment.
⚡ 82.64% MEP System Match: Ductwork, drainage, piping, and electrical fixtures align accurately in 3D coordinate planes.
Global Metric | V1 (Baseline) | V2 (Wave 1-2) | V3 (Latest Wave 4) | Cumulative Improvement |
🎯 Median Visual Match | 80.90% | 84.90% | 85.50% | 🏆 +4.60% (Exceeded 85%) |
⚖️ Macro Average Visual Match | 70.57% | 77.60% | 77.71% | 🟢 +7.13% |
📊 Micro Average Visual Match | 72.24% | 80.35% | 80.46% | 🟢 +8.23% |
Passing Elements ($\ge 85%$) | 2,865 | 3,140 | 3,135 | 🟢 +270 elements |
Top Performing Disciplines | ||||
• Ceilings ( | 11.4% | 89.0% | 89.0% | 🟢 +77.6% (Passing) |
• Valves & Piping ( | 0.0% | 82.2% | 82.4% | 🟢 +82.4% (Zero-shot lift) |
• Structural Plates ( | 10.2% | 88.9% | 87.1% | 🟢 +76.9% (Passing) |
• Bracing Members ( | 91.8% | 91.6% | 92.4% | 🟢 +0.8% (3D Vector Pitch) |
👉 Want to inspect raw visual data or reproduce tests yourself? Explore the full dataset and code on the Kaggle Benchmark Notebook.
Rigorously benchmarked against 407 real-world projects across architectural, structural, and complex hospital MEP domains:
100.0% Median Retention Rate: Extract and re-compile back to standard IFC4 without element loss.
91.6% Average Storage Reduction: Compresses raw IFC files by an average of 91%.
558M+ LLM Tokens Saved: Prevented 558,629,804 tokens from cluttering agent context windows.
100.0% Modern Schema Crash-Resilience: Zero fatal crashes or unhandled exceptions across standard IFC2X3 and IFC4 datasets.
📖 Read Full Research Paper: debim: An Empirical Study of Declarative Building-as-Code on 407 Heterogeneous Real-World OpenBIM Models
📦 Kaggle Public Benchmark Dataset: debim-5000-ifc-benchmark
⚡ Kaggle Automated Stress Test: debim-ifc-stress-test
Software Code: Licensed under the MIT License — Copyright (c) 2026 Prida Takon.
Research & Technical Reports: Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
Benchmark Datasets & Sample Models: Test fixtures in tests/fixtures/ originate from buildingSMART International and the Open IFC Model Repository under CC BY 4.0 / CC-BY-3.0.
Compile a declarative BIM YAML manifest into a standard IFC4 building model.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_yaml | Yes | ||
| output_ifc_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about whether the file at output_ifc_path is created, overwritten, or requires an existing directory, nor anything about error handling or permissions. It also gives no indication of how a malformed manifest is reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler that states input and output crisply. It is efficient, though the terseness is part of why behavioral and parameter detail is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but for a tool that writes an artifact with zero annotation coverage and zero parameter documentation, the description leaves critical gaps: manifest format expectations, overwrite behavior, and where this fits relative to debim_validate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies what the parameters are. It never explains the expected YAML manifest structure, required manifest keys, path format, or whether the output path must exist — the two most consequential inputs for getting a call right.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ("Compile") and both the input resource ("declarative BIM YAML manifest") and the output artifact ("standard IFC4 building model"), so the transformation is unambiguous. It does not, however, differentiate itself from siblings like debim_validate or debim_generate_viewer, which also operate on the same BIM artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this versus debim_validate (validate a manifest) or the cost/QTO tools, and no stated prerequisites such as validating the manifest first. The agent must infer the workflow ordering entirely from the tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate full Bill of Quantities (BOQ) and cost estimation.
Matches QTO quantities against unit material and labor prices.
If prices_yaml is omitted, auto-generates a benchmark template.
Optionally exports the complete BOQ to a CSV file.
| Name | Required | Description | Default |
|---|---|---|---|
| prices_yaml | No | ||
| manifest_yaml | Yes | ||
| export_csv_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the fallback behavior when prices_yaml is omitted and the optional CSV export, but says nothing about file overwrite semantics for export_csv_path, permissions, or other side effects of a tool that can write output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, front-loaded lines with the core purpose stated first and no filler. Efficient, though the trailing export sentence is a minor detail that could be folded in.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers the main fallback and export behaviors. However, for a tool that can write files with zero annotations and 0% schema coverage, the absence of manifest_yaml explanation and export side-effect details leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the prices_yaml omission case and the purpose of export_csv_path, but leaves manifest_yaml (the only required parameter) entirely unexplained, so coverage is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Calculate full Bill of Quantities (BOQ) and cost estimation') and clarifies the mechanism ('Matches QTO quantities against unit material and labor prices'), which implicitly distinguishes it from debim_qto. It does not, however, explicitly differentiate itself from the closely named sibling debim_cost_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are named. The only conditional advice is 'If prices_yaml is omitted, auto-generates a benchmark template,' which is a behavior rather than a usage rule, and the related debim_cost_template sibling is never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a minimal project-scoped price catalog YAML template based only on the materials and items actively used by the building model.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_yaml | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose meaningful behavioral traits about the output — that it is "minimal" and filtered to actively-used materials — but says nothing about permissions, file-writing behavior, or determinism. It adds some value beyond structured fields but leaves the operational profile thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A tight two-line statement with the verb and deliverable front-loaded and no filler. Only the awkward line break interrupts otherwise clean structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. However, with no annotations, an undocumented required parameter, and no guidance on how this template relates to the downstream debim_cost workflow, the description leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter manifest_yaml, and the description never mentions or explains it. The agent must guess that the manifest represents the building model input. With coverage this low, the description should have compensated and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Generate") and resource ("project-scoped price catalog YAML template"), and scopes it precisely to materials/items actively used by the building model. This differentiates it reasonably from siblings like debim_cost, though it never explicitly names which sibling it complements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no named alternative. The scoping clause ("based only on materials actively used") implies it should be run against a live model, but the agent must infer when this template is the right call versus debim_cost or debim_qto.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a standalone, zero-dependency interactive 3D HTML web viewer with OrbitControls, X-Ray, Section Cut, and Layer Explorer.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_yaml | Yes | ||
| output_html_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the output artifact's nature (standalone, zero-dependency, interactive), but says nothing about writing/overwriting the file at output_html_path, failure modes, or auth needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the capability front-loaded and feature list following. No waste, though it is arguably too terse given the gaps elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the feature list covers what the generated viewer contains. However, with 0% parameter coverage and no annotations, the description leaves the manifest input contract and file-writing behavior unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and does not: neither manifest_yaml's expected format/source nor output_html_path's path semantics (absolute? overwrite?) are explained. Only the bare parameter names in the schema give any clue.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate) and resource (standalone interactive 3D HTML viewer) and enumerates the delivered features (OrbitControls, X-Ray, Section Cut, Layer Explorer). It is clearly distinct from validate/qto/cost/compile siblings, though it never explicitly says so.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the sibling tools, nor prerequisites such as whether the manifest must first pass debim_validate. The agent must infer that a validated manifest is the expected input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate Quantitative Take-Off (QTO) material quantities deterministically. Returns exact concrete volume (m3), formwork area (m2), rebar weight (kg), structural steel (kg), timber volume (m3), masonry area (m2), and excavation (m3).
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_yaml | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It claims deterministic output and lists result units, which is useful, but says nothing about required input validity, failure modes, permissions, or whether output depends on a prior validation step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action in the first clause, followed by a compact enumeration of outputs. No filler sentences, though the output listing is partially redundant given an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be restated (they are, harmlessly). However, for a single-param tool whose only input is an undocumented manifest, the description leaves the agent without enough context on input requirements or workflow position.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter manifest_yaml is undocumented in both schema and description. The description never explains what the manifest is, what format/structure it expects, or where it comes from, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Calculate Quantitative Take-Off (QTO) material quantities deterministically', and enumerates the exact quantities produced. It is clearly distinct in substance from siblings like debim_cost, debim_validate, and debim_compile_ifc, though it never names them explicitly to route the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of prerequisites (e.g., whether the manifest must first pass debim_validate), and no mention of alternatives such as debim_cost. The agent is left to infer the position of this tool in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a declarative BIM manifest YAML string. Checks schema syntax, grid consistency, storey heights, and material references.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_yaml | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully enumerates what is checked, which is genuine behavioral content, but it omits whether the operation is purely read-only, whether a failing manifest throws or returns structured errors, and whether validation has side effects. Partial coverage only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the check list immediately after. No filler, though the check enumeration could be slightly condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the tool is low-complexity with one parameter. However, for a validation gate in a six-tool pipeline, the absence of any guidance on ordering relative to debim_compile_ifc leaves an agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the schema alone contributes nothing. The description compensates by establishing that the input is a YAML manifest string, but adds no syntax expectations, size limits, or format constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Validate) and resource (declarative BIM manifest YAML string), and enumerates the checks performed (schema syntax, grid consistency, storey heights, material references). It is clearly distinguishable from write-oriented siblings like debim_compile_ifc, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says nothing about when to call this versus debim_compile_ifc or debim_qto, nor whether validation is a prerequisite before compiling. No conditions, prerequisites, or exclusions are given; usage must be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0debim_compile_ifcdebim_costdebim_cost_templatedebim_generate_viewerdebim_qtodebim_validateScored across 6 tools
Each tool targets a distinct stage of the BIM pipeline (validate, QTO, cost template, cost, IFC compile, viewer), so most selections are unambiguous. The only mild overlap is between debim_cost_template (generates a price catalog YAML) and debim_cost (which can auto-generate a benchmark template when prices are omitted), but descriptions clarify the distinction.
All six tools use a consistent snake_case pattern with the same debim_ prefix and clear action-oriented verbs (validate, qto, cost_template, cost, compile_ifc, generate_viewer). There are no mixed conventions or vague verbs.
Six tools is well-scoped for a declarative BIM manifest pipeline: validate, quantify, cost, compile, and visualize. Each tool earns its place, and there are no redundant or filler operations.
The surface covers a full workflow from validation through QTO, cost estimation, IFC compilation, and viewer generation, with no dead ends for the stated purpose. Minor gaps exist, such as no explicit manifest editing/update helper or reverse import from IFC, but these are workable given the declarative input model.
bim.house — words become buildings. Generate BIM, check code & structure, quote materials.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
AI Hub for AEC — 50+ 3D formats, clash detection, ACC integration via Autodesk Platform Services.
