Bonsai MCP

by Show2Instruct

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.5/5 across 8 of 8 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bonsai-mcp MCP server](https://glama.ai/mcp/servers/Show2Instruct/bonsai-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Show2Instruct/bonsai-mcp)

Score Badge

Copy to your README.md:

[![bonsai-mcp MCP server](https://glama.ai/mcp/servers/Show2Instruct/bonsai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Show2Instruct/bonsai-mcp)

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