bonsai-mcp

by nhantruong96

Overview Schema Source Related Servers Discussions Admin

Python

Local

ifc_spatial_tree

Retrieve the IFC spatial hierarchy from project to storey, showing element counts at each level.

Instructions

Spatial hierarchy IfcProject -> Site -> Building -> Storey, with the number of elements contained in each node.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ifc_spatial_tree"
  }
}

Input Schema

Name	Required	Description	Default
`max_depth`	No
`class_limit`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 1, 2026

TDQS

C2.7/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose the output shape and that element counts are included, but it stays silent on whether this is read-only, how max_depth or class_limit affect traversal or grouping, and any edge behavior. Some burden therefore remains unmet.

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 a single compact sentence with no filler, and the core idea—spatial hierarchy with counts—is front-loaded. It is concise, though the noun-phrase form and missing usage/parameter context mean the brevity is partially under-specification.

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

Completeness2/5

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

The two optional parameters are semantically undocumented, and no annotations clarify safety or scope. Even with an output schema present, the description does not give enough context for an agent to select and configure the call correctly. A usable definition would at least explain what max_depth and class_limit govern.

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

Parameters1/5

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

Schema description coverage is 0% and the description never mentions max_depth or class_limit. The agent cannot infer what class_limit limits or what max_depth applies to. There is no compensatory parameter documentation anywhere.

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

Purpose4/5

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

The description names a specific deliverable—the IfcProject→Site→Building→Storey hierarchy with per-node element counts—so an agent can identify what the tool produces. It lacks an explicit operational verb like 'returns' or 'builds', and does not contrast with siblings, so it stops just short of full clarity.

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

Usage Guidelines2/5

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

No guidance is given for when to use this tool versus alternatives such as ifc_model_info, ifc_list_entities, or ifc_geometry_info. The intended use is only implied by the name and output shape; there are no exclusions or alternative pointers.

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