What can you do with this server?

Bonsai MCP connects an MCP client (e.g., Claude, Cursor, VS Code) to a running Blender + Bonsai (BlenderBIM) session, enabling inspection, querying, and manipulation of 3D scenes and IFC building models. Scene & Object Inspection * Get a summary of the current Blender scene (object counts, collections, IFC availability), filtered by type, name, class, or GlobalId. * Retrieve detailed info (name, type, location, dimensions, IFC class, GlobalId) for currently selected objects. IFC Data Querying * Fetch IFC property sets (psets) and quantity sets (qtos) for one or more objects (up to 100 targets per call). * Get IFC project info: schema version, project name, site/building/storey counts, entity counts, materials, and classifications. Viewport Interaction * Capture screenshots of the Blender 3D viewport with options to set view direction (top, front, isometric, camera, etc.), frame content (all or selected), image format (JPEG/PNG), quality, and resolution. Optionally returns 2D bounding boxes for visible objects. Code Execution * Run IfcOpenShell/Bonsai API Python code to query or modify IFC entities, read/write properties, traverse the model, and call ifcopenshell.api operations (bpy is blocked for safety). * Run arbitrary Python with full bpy access for Blender-specific tasks like viewport manipulation, rendering, object transforms, and modifiers. IFC Model Management * Save the loaded IFC model in-place or to a new path (with overwrite protection), with an option to reload the project so IFC edits are reflected in the Blender viewport. Diagnostics * Use the doctor command to verify the bridge connection and tool availability.

Which integrations are available for this server?

Allows connecting MCP clients to a running Blender session with Bonsai (BlenderBIM), enabling scene inspection, IFC project queries, viewport capture, and Python execution inside Blender.

How do I use Bonsai MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bonsai MCP List every wall in the model with its fire rating." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Bonsai MCP

by Show2Instruct

Overview Schema Related Servers Score Discussions

Python

Local

Bonsai MCP

License: MIT Python 3.10+ Docs

A local Model Context Protocol server that connects any MCP client (Claude Desktop, Claude Code, Cursor, VS Code, OpenAI Codex) to a running Blender + Bonsai (BlenderBIM) session. Inspect the scene, query the loaded IFC project, capture the viewport, and run Python inside Blender.

Documentation site: show2instruct.github.io/bonsai-mcp

MCP client  --stdio-->  bonsai-mcp  --127.0.0.1:9878-->  Blender add-on (bpy + Bonsai + IfcOpenShell)

Bonsai MCP workflow: an MCP client drives the bonsai-mcp server, which talks to the Blender add-on and the IFC model loaded in Bonsai

Part of IFC-CoPilot: A Tool-Based Framework for LLM-Driven IFC Building Design.

News

[2026-08] v1.2 released: three new tools that sync Blender after IFC edits without a full reload (refresh_view, refresh_geometry, reload_project), plus IfcOpenShell selector queries in list_elements. All releases.
[2026-07] Bonsai MCP is public, with a documentation site: a lighter, code-generation-first rewrite of our earlier ifc-bonsai-mcp server.
[2025-11] MCP4IFC paper released on arXiv, the study that motivated this server.

Related MCP server: BlenderMCP

Relation to `ifc-bonsai-mcp`

This repository supersedes ifc-bonsai-mcp, which we used for the experiments in the MCP4IFC paper and which stays online for reproducibility.

The original ships a large set of predefined tools. This one is built around code generation. Modern LLMs write IfcOpenShell code well, so a small set of guarded code tools covers more IFC tasks than any fixed tool list, and adapts to tasks we never anticipated. The code-generation workflow is reworked and simplified here, and the server is lightweight, quick to connect, and easy to use.

Use this repository unless you need the original's fixed tools or the exact paper setup. It is the one we keep updated.

Requirements

Blender 3.6+ (4.x recommended).
Bonsai (BlenderBIM), only for the IFC tools. Install it from bonsaibim.org.
uv, one-time install below. Runs the server and handles Python 3.10+ for you.
git, to clone this repo. The server runs from your local checkout; it is not published to PyPI.

Setup (one-time)

Do these once. uv installs everything into the repo's own .venv the first time you run it; nothing is installed globally, and nothing is fetched from PyPI.

1. Install uv:

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

2. Clone this repo somewhere permanent, and note its full path; you point your MCP client at it below:

git clone https://github.com/Show2Instruct/bonsai-mcp.git

Quick start

1. Install the Blender add-on

In Blender: Edit > Preferences > Add-ons. On Blender 4.2+/5.x, open the ▾ menu (top-right) > Install from Disk...; on older versions use the Install... button.
Pick blender_addon/bonsai_bridge.py from the repo you cloned (that exact file, not scripts/package_addon.py), or install the bonsai_mcp_bridge-X.Y.Z.zip attached to the matching GitHub release the same way. Then tick Bonsai MCP Bridge to enable it.
Open the sidebar (press N) > Bonsai MCP tab > Start Bridge. It now listens on 127.0.0.1:9878.

2. Connect your client

Point your client at the folder you cloned. Everywhere below, replace /path/to/bonsai-mcp with that path. On Windows in JSON, either use forward slashes or double every backslash (C:\\Users\\you\\bonsai-mcp).

Claude Code:

claude mcp add bonsai-mcp -- uv run --directory /path/to/bonsai-mcp bonsai-mcp

Claude Desktop, Cursor, VS Code, and other clients: add this to the client's MCP config, then restart the client:
```
{
  "mcpServers": {
    "bonsai-mcp": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/bonsai-mcp", "bonsai-mcp"]
    }
  }
}
```
On Windows, if the client can't find uv, use its full path as the command (e.g. C:\\Users\\you\\.local\\bin\\uv.exe).

uv run builds the project into the repo's .venv on first launch (editable, so your local edits take effect on the next restart) and caches it after that.

3. Verify

With Blender running and the bridge started, run this from inside the cloned folder:

uv run bonsai-mcp doctor

doctor pings the bridge and reports Blender / IfcOpenShell status and the tools it exposes.

Per-client config paths, the Windows uv.exe path note, and optional BONSAI_MCP_* settings are in docs/clients.md. Example configs live in examples/; set the --directory path to your clone.

Tools

Fourteen tools, each tagged [QUERY] (read-only) or [EDIT] (mutates state).

Category	Tool	Purpose
QUERY	`get_scene_info`	Scene summary plus an optional filtered object list (paged).
QUERY	`get_selected_objects`	Per-object info for the current selection (capped).
QUERY	`list_elements`	IFC-backed elements filtered by class (inheritance-aware), name, storey, or an IfcOpenShell `selector` query (properties, materials, attributes); paged.
QUERY	`get_psets`	IFC property and quantity sets for one or many objects (paged batches).
QUERY	`get_viewport_screenshot`	Capture the viewport: `view` or `azimuth`/`elevation`, direction-aware `fit`, per-storey floor plans, shading incl. color-by-class, plus structured viewport state with depth.
QUERY	`get_ifc_project_info`	Schema, counts, materials, classifications.
QUERY	`get_spatial_structure`	Site -> building -> storey -> space tree with element counts.
QUERY	`get_quantities`	Quantity takeoff (areas, volumes, lengths) by class, optionally per storey.
EDIT	`execute_ifc_code`	Run IfcOpenShell / Bonsai API code. `bpy` blocked.
EDIT	`execute_blender_code`	Run arbitrary Python with full `bpy` access.
EDIT	`refresh_view`	Sync the scene after data-only IFC edits (names, psets); milliseconds, no disk I/O.
EDIT	`refresh_geometry`	Rebuild geometry/placement for specific elements; targeted, no disk I/O.
EDIT	`reload_project`	Full scene rebuild from the in-memory model (slow, explicit escape hatch).
EDIT	`save_ifc_file`	Write the model to disk: in place or save-as (guarded). Durability only.

Every tool returns structured content alongside readable JSON text, and the server also exposes MCP resources (bonsai://project, bonsai://scene, per-element psets) and two workflow prompts (model-audit, visual-verify).

Full reference with inputs, outputs, and examples: docs/tools.md.

Example prompt, with an IFC project open in Bonsai:

"List every wall in the model with its fire rating."

Safety

The bridge binds to 127.0.0.1 only and has no authentication, and execute_blender_code runs arbitrary Python. Treat it like an open Python REPL on your machine and never expose it to a network. See docs/safety.md.

Documentation

Rendered site: show2instruct.github.io/bonsai-mcp

Installation
Client setup (Claude, Cursor, VS Code, OpenAI)
Tools reference
Example prompts
CLI reference
Safety
Troubleshooting

The changelog can be found on the GitHub Releases page.

Contributing

See CONTRIBUTING.md. Short version, with Python 3.10+ and uv:

uv venv
uv pip install -e ".[dev]"
uv run python -m ruff check src tests blender_addon scripts
uv run python -m pytest

Add tests and docs for behavior changes. Report security issues privately through GitHub Security Advisories (see SECURITY.md).

License

MIT. See LICENSE.

Disclaimer

This is not an official Bonsai release. Bonsai MCP is an independent project, not affiliated with or endorsed by the Bonsai (BlenderBIM) project, bonsaibim.org, or the Blender Foundation.

Available Tools

8 tools

execute_blender_codeA

Destructive

[EDIT] Run arbitrary Python code inside Blender with full bpy access. Use ONLY when you need Blender-specific operations (viewport manipulation, rendering, object transforms, modifiers). For IFC/BIM data operations, ALWAYS prefer execute_ifc_code. LOCAL TRUSTED USE ONLY.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python source to execute.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructive hint and non-read-only. Description adds '[EDIT]' prefix and 'LOCAL TRUSTED USE ONLY' to emphasize mutability and security. Could elaborate on potential destructive actions, but overall transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences pack purpose, usage constraints, and security warning. No redundant words. Front-loaded with key verb 'Execute.'

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with annotations, the description fully covers the context: what it does, when to use, alternative, and trust implication. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'code' with 100% schema coverage. Description says 'Python source to execute.' which adds context beyond the schema's 'Python source.' It conveys the execution nature clearly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run arbitrary Python code inside Blender with full bpy access.' It distinguishes from the sibling tool execute_ifc_code by specifying when to use each, ensuring no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage guidance is provided: 'Use ONLY when you need Blender-specific operations' and 'For IFC/BIM data operations, ALWAYS prefer execute_ifc_code.' Also adds security context with 'LOCAL TRUSTED USE ONLY.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

execute_ifc_codeA

Destructive

[EDIT] PREFERRED code execution tool. Runs IfcOpenShell / Bonsai API code with a pre-injected IFC namespace. bpy access is BLOCKED; use execute_blender_code only when you genuinely need Blender operations (viewport, rendering, object transforms). Pre-injected variables: ifc (the loaded IFC file or None), ifcopenshell, ifc_api (ifcopenshell.api), element_util (ifcopenshell.util.element), tool (bonsai.tool). Pre-injected helper functions: get_ifc_file() (loaded IFC file or raises), get_default_container() (active spatial container), save_and_load_ifc(path=None) (save the project and reload it; call this after IFC edits to make them visible in the viewport, since edits do NOT appear until the project is reloaded). Use this for: querying IFC entities, reading/writing properties, traversing the IFC model, calling ifcopenshell.api operations, and any BIM data work.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python source using IfcOpenShell/Bonsai APIs. bpy imports are rejected.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint: true; description adds that edits do not appear until project is reloaded and explains the save_and_load_ifc helper. Also states bpy imports are rejected, providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, front-loaded purpose, and informative bullet points. Slightly lengthy but justified by the complexity of the tool; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a code execution tool with no output schema, the description is remarkably complete. It covers the tool's purpose, restrictions, available APIs, helper functions, and lifecycle considerations (reloading after edits). Leaves no significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the single parameter 'code' with a basic description, but the tool description adds extensive semantics: lists pre-injected variables (ifc, ifcopenshell, etc.) and helper functions (get_ifc_file, get_default_container, save_and_load_ifc), which greatly aids the agent in crafting correct code.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a code execution tool for IfcOpenShell/Bonsai API with pre-injected IFC namespace. It distinguishes from sibling tool 'execute_blender_code' by noting bpy access is blocked and specifies its use for BIM data work.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use this tool (for IFC queries, properties, traversing, API operations) and when not (for Blender operations, which require execute_blender_code). Provides guidance on calling save_and_load_ifc after edits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ifc_project_infoA

Read-only

[QUERY] Return IFC schema, project name, counts of sites/buildings/storeys, counts of common IFC entities, and material and classification summaries. Returns a clear error if no IFC project is loaded.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing exact return values (schema, counts, summaries) and error behavior. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, perfectly concise, front-loaded with '[QUERY]' to indicate read-only nature. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description comprehensively explains all return values and error conditions. With no parameters, it fully describes the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; baseline 4 is appropriate. Description does not need to explain parameters as schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool returns IFC schema, project name, counts, summaries, and an error if no project. It clearly distinguishes from siblings like 'get_scene_info' (Blender scene) and 'get_psets' (specific property sets), as it focuses on overall IFC project info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing a project overview, but does not explicitly state when not to use or mention alternatives. The '[QUERY]' prefix hints at its read-only nature. Lacks explicit when-to-use vs siblings, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_psetsA

Read-only

[QUERY] Return IFC property sets (psets) and quantity sets (qtos) for one or more objects. Accepts any mix of global_ids and names lists (Blender object names). Up to 100 targets per call. The response preserves input order in a results list.

ParametersJSON Schema

Name	Required	Description	Default
`names`	No
`global_ids`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by noting the response preserves input order in a results list and the 100-target limit, providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted words. It is front-loaded with the core purpose and efficiently conveys all key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description covers purpose, parameters, limits, and response order. It might lack details on the exact format of returned data, but it is largely complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage. The description compensates by explaining that names are Blender object names and that global_ids are accepted in any mix, along with the limit. This adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns IFC property sets and quantity sets for objects. It specifies the resource and action, and the sibling tools include other getters, making it distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description starts with [QUERY] indicating a query tool, and specifies acceptable inputs (global_ids and names lists) and a limit of 100 targets. It lacks explicit alternatives or when-not-to-use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_scene_infoA

Read-only

[QUERY] Return a summary of the current Blender scene (scene name, object count, selection, collections, IFC availability). When query is supplied, the response also includes an objects list filtered by the query. Supported queries: 'all', 'selected', 'walls', 'doors', 'windows', 'spaces', 'slabs', 'columns', 'beams', 'roofs', 'stairs', 'by_class', 'by_name', 'by_global_id'.

ParametersJSON Schema

Name	Required	Description
`name`	No
`query`	No	Optional object filter. Omit for scene summary only.
`global_id`	No
`ifc_class`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds context about query-triggered object lists and the summary contents. No contradictions; it appropriately extends the annotation-implicit behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, adequately front-loaded with the core purpose, and then adds query details. No extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the summary and query behavior are described, the other parameters (name, global_id, ifc_class) are mentioned in the schema but not explained. Since there is no output schema, the description should cover these aspects for full clarity. It is partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (25%: only query has a description). The description explains the query parameter and its supported values, but does not explain name, global_id, or ifc_class parameters. With low coverage, the description should compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a summary of the current Blender scene with specific elements (scene name, object count, selection, collections, IFC availability) and further explains query-based filtering. It distinguishes from siblings like get_selected_objects (which focuses on selection) and get_ifc_project_info (IFC-specific).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description guides on when to omit query (scene summary only) and lists supported queries. However, it does not explicitly guide on when to use this tool versus siblings like get_selected_objects or execute_blender_code for object queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_selected_objectsA

Read-only

[QUERY] Return name, type, location, dimensions, and (if available) IFC class and GlobalId for each currently selected object.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns specific fields and conditionally includes IFC data, providing useful context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with '[QUERY]' indicating a read operation. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description fully specifies what is returned (fields listed). Sibling tools are distinct, no missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (empty schema, 100% coverage), so description naturally covers everything. It explains the output without needing to document parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Return' and clearly lists the data fields (name, type, location, dimensions, IFC class, GlobalId) for selected objects. It distinguishes from sibling tools like get_scene_info (scene-level) or get_ifc_project_info (project-level).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies use when objects are selected, but lacks explicit when-to-use/when-not-to-use guidance or mention of alternatives. However, context is clear enough for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_viewport_screenshotA

Read-only

[QUERY] Capture the Blender 3D viewport and return the image inline. Optionally aim the viewport first: view sets the direction (top/bottom/front/back/left/right = orthographic axis views, 'iso' = perspective isometric, 'camera' = scene camera) and fit frames the content ('all' or 'selected'). The render is downscaled so the longest edge fits max_size (default 800 px) and encoded as JPEG by default, keeping the response safely under MCP size limits. Scene render settings are restored afterwards; the viewport orientation persists.

ParametersJSON Schema

Name	Required	Description	Default
`fit`	No	Frame content before capturing: 'all' = everything, 'selected' = current selection. Combines with view.
`view`	No	Aim the viewport before capturing. Axis names give orthographic views; 'iso' a perspective isometric; 'camera' the scene camera. Omit to keep the current orientation.
`format`	No	'jpeg' (default, small) or 'png' (lossless, large).	jpeg
`quality`	No	JPEG quality. Ignored for png.
`max_size`	No	Longest image edge in pixels. The render is only downscaled, never upscaled. Values above ~1200 with format='png' may exceed the response size cap.
`max_objects`	No	Cap for include_objects; largest boxes are kept.
`include_objects`	No	Also return, as text, screen-space 2D bounding boxes keyed by GlobalId for objects in frame (normalized 0-1, origin top-left). Use this for spatial reasoning when the image channel is unavailable or for grounding what the image shows.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint. The description adds context about scene render settings being restored, viewport orientation persisting, and downscaling/encoding to stay under size limits. This goes beyond annotations, but could mention any potential side effects like temporary view changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured paragraph that front-loads the core purpose, then details optional behaviors and rendering specifics. Every sentence is informative without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, optional view/fit, encoding, bounding boxes), the description covers all aspects adequately. It explains input, behavior, and output (image inline + optional bounding boxes) even without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description enriches parameter meaning: e.g., 'view' and 'fit' combine, 'max_size' only downscales, 'quality' ignored for png, 'include_objects' provides spatial reasoning info. This adds value beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it captures the Blender 3D viewport and returns the image inline. It specifies the optional view aiming and fit parameters. Among sibling tools, none offer screenshot functionality, so it is well-distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each optional parameter (view and fit) and their effects. It implies usage for visual context, but does not explicitly state when not to use it or provide direct alternatives. However, siblings are sufficiently different to avoid confusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_ifc_fileA

Destructive

[EDIT] Save the loaded IFC model. With no arguments it saves the project back to its own file (in-place, like File > Save IFC). Pass output_path for a save-as; that refuses to overwrite existing files unless overwrite=true. Pass reload=true to reload the project from the saved file afterwards, which rebuilds the Blender scene so IFC-level edits become visible in the viewport.

ParametersJSON Schema

Name	Required	Description
`reload`	No	Reload the project after saving so the viewport reflects IFC edits.
`overwrite`	No
`output_path`	No	Optional save-as path. Omit to save the project to its own file.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses destructive behavior (save can overwrite), and details the reload behavior that makes IFC edits visible. Annotations reinforce destructive nature, and description adds valuable context without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with clear front-loading. First sentence states core purpose, then details arguments. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 optional parameters, no output schema, and destructive annotations, the description covers all relevant behaviors: save modes, overwrite guard, reload effect. Sibling tools are clearly distinct.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 2 of 3 parameters. The tool description adds meaning for 'overwrite' (refuses unless true) and 'reload' (rebuilds scene), complementing the schema. 'output_path' is described similarly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Save the loaded IFC model' with specific verb and resource, and distinguishes two modes (in-place and save-as). It differentiates from sibling tools which are query or execution tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for each usage scenario: no arguments for in-place save, pass output_path for save-as, with conditions for overwrite and reload. Does not explicitly state when not to use but is sufficient given uniqueness.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Jul 10, 2026
- First observedexecute_blender_code
- First observedexecute_ifc_code
- First observedget_ifc_project_info
- First observedget_psets
- First observedget_scene_info
- First observedget_selected_objects
- First observedget_viewport_screenshot
- First observedsave_ifc_file

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. execute_blender_code and execute_ifc_code are explicitly differentiated for Blender vs. IFC operations. The query tools (get_ifc_project_info, get_psets, get_scene_info, get_selected_objects) and save_ifc_file are non-overlapping.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (execute_, get_, save_). The naming clearly indicates action and target, making the set predictable for an agent.

Tool Count5/5

With 8 tools covering code execution, queries, screenshots, and saving, the count is well-scoped for a BIM integration server. Each tool earns its place without redundancy or unnecessary complexity.

Completeness4/5

The tool surface covers core workflows: executing custom code (both Blender and IFC), querying project info and properties, capturing viewport, and saving. Minor gaps exist (e.g., no dedicated tool for creating/deleting entities), but these can be handled via execute_ifc_code.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SceneplaneOAuth
online.sceneplane
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
Image & Video Processing Multimedia Processing
1
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
runcomfy-mcp AOAuth
io.github.runcomfy-com
Remote MCP server for RunComfy Serverless API (ComfyUI): deployments and async inference.
AI & Machine Learning Cloud Platforms Image & Video Processing
2
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202

Related MCP Servers

dcc-mcp-blender
Design Tools Image & Video Processing
dcc-mcp
A
license
Not graded
quality
A
maintenance
Enables AI clients to control Blender's 3D workflow via an embedded MCP server.
Updated 12 days ago (2026-08-25 17:58 UTC)
28
MIT
BlenderMCP
Design Tools Autonomous Agents
yuri-schmaltz
A
license
Not graded
quality
B
maintenance
Connects Blender to local LLMs through MCP, enabling AI-assisted 3D modeling, scene creation, and manipulation.
Updated a month ago (2026-08-11 17:51 UTC)
1
MIT
blender-ai-mcp
Design Tools Multimedia Processing
alexandervi1
A
license
Not graded
quality
C
maintenance
Connects MCP-compatible clients to a live Blender scene for AI-assisted 3D workflows, enabling inspection and controlled operations on objects, materials, cameras, lights, render settings, animation, UVs, Geometry Nodes, imports, exports, and Python execution.
Updated 2 months ago (2026-06-24 02:15 UTC)
1
MIT
MCP Blender
Multimedia Processing Code Execution Design Tools
joel1251
A
license
Not graded
quality
C
maintenance
Enables LLM clients like Claude to control Blender remotely, including scene inspection, object creation/modification, and Python code execution, via a socket-based MCP server.
Updated 2 months ago (2026-07-20 22:27 UTC)
229
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Show2Instruct/bonsai-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Bonsai MCP

News

Relation to ifc-bonsai-mcp

Requirements

Setup (one-time)

Quick start

1. Install the Blender add-on

2. Connect your client

3. Verify

Tools

Safety

Documentation

Contributing

License

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Relation to `ifc-bonsai-mcp`