ifc-mcp

by WolfzTech

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
Disambiguation4/5
Most tools have clearly distinct purposes (loading, spatial structure, element queries, properties, geometry). The only potential confusion is between get_element_by_id and get_element_by_label (both return element details) and get_property_sets vs get_property_sets_detail, but the descriptions explicitly differentiate them by input and level of detail.
Naming Consistency5/5
All 20 tool names follow a consistent snake_case verb_noun pattern (load_ifc_file, list_loaded_models, get_element_placement, search_elements). The verbs are uniform: load/list/unload for lifecycle, get for queries, search for search, with no mixed conventions or vague action words.
Tool Count4/5
With 20 tools, the server is slightly over the ideal 3-15 range but still well-scoped for the complex domain of IFC model analysis. Each tool addresses a specific aspect of querying building data, and the count is justified by the breadth of information exposed.
Completeness4/5
The toolset covers the full read-only lifecycle: loading/unloading models, querying spatial hierarchy, elements, properties, quantities, materials, geometry context, and batch operations. Minor gaps exist, such as no direct query of elements by spatial level or retrieval of raw geometry tessellation, but the core analytical workflows are well supported.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions freeing resources, but does not disclose whether unloading is destructive, whether it requires a previously loaded model, or what happens to dependent data or queries.
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, concise sentence with no filler. It is front-loaded with the action and purpose, making it easy to scan, though it lacks depth.
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?
Given the tool is a mutation with no annotations and no output schema, the description is too sparse. It omits context about prerequisites, side effects, error handling, and the meaning of the model_id parameter, making it insufficient for reliable use.
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?
The parameter model_id is not described in the tool description, and the schema only provides the type and title. With 0% schema description coverage, the description should compensate but fails to explain what model_id is or how to obtain it.
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 clearly states the verb 'unload' and the resource 'IFC model', and indicates the purpose of freeing resources. It is distinguishable from sibling tools like load_ifc_file and the getter functions, though it doesn't explicitly contrast with them.
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 explicit guidance is given on when to use this tool versus alternatives like load_ifc_file. The intended usage is only implied (unload when done with a model), with no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the output shape ({pset_name: {prop_name: value}}), which is useful, but it does not mention behavior for missing elements, empty results, or potential errors. As a read-only get operation, the risk is low, but the description lacks depth.
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, concise sentence that front-loads the verb and resource, then specifies the return format. No filler or redundant information is present.
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?
The tool is simple with two parameters and no output schema. The description provides the return structure, which is a key piece of context. However, it lacks details on edge cases, the distinction from the sibling detail tool, and any prerequisites, making it minimally adequate.
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?
The schema has 0% description coverage, so the description must explain the parameters. It only says 'for an element' without clarifying that model_id specifies the model and global_id identifies the element. This leaves ambiguity about the exact roles of the two required parameters.
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 clearly states the tool retrieves all property sets for an element and specifies the return format as a dict. However, it does not explicitly distinguish this from the sibling get_property_sets_detail, so the purpose is clear but not differentiated beyond the name.
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 provided on when to use this tool versus alternatives like get_property_sets_detail or other element-related queries. The description implies usage for retrieving property sets but offers no exclusions or comparison, leaving the choice to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get full details' but does not explain what those details include, whether the tool is read-only, what happens if the element is not found, or any rate/limit considerations. For a read operation this is minimal, but it adds no context beyond the verb itself.
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, front-loaded sentence with no fluff. It states the core purpose efficiently. However, it is slightly under-specified for a two-parameter tool, leaving the model_id undefined. It earns a 4 because it is concise and clear, but not a 5 because it lacks a second clarifying sentence.
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?
With no annotations and no output schema, the description is too thin to fully orient an agent. It doesn't describe the response format or scope of 'full details', nor does it clarify the distinction between GlobalId and other identifiers (as in 'get_element_by_label'). The agent may need to infer important details from the name or schema alone.
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 description coverage is 0% and the description must compensate. It mentions 'GlobalId' but completely omits 'model_id', which is a required parameter. The agent receives no help understanding what model_id refers to or how it relates to the GlobalId. The description adds minimal value for one of two 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 a specific verb ('Get') and clearly identifies the resource ('a single element') and scope ('by its GlobalId'). It distinguishes itself from siblings like 'get_elements_by_type' (plural) and 'get_element_by_label' (different identifier), so an agent can correctly select this tool when a GlobalId is available.
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?
The description implies when to use the tool (when you have a GlobalId for a single element) but does not explicitly state when not to use it or mention alternatives like 'get_element_by_label' or 'search_elements'. The usage context is clear but not fully articulated with exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It adds useful constraints: pset_name requires ownership, and property_name/property_value apply within that pset or any pset. However, it does not mention return format, case sensitivity, or behavior when filters are omitted, leaving gaps.
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?
Two sentences with a front-loaded purpose and a tidy list of filters. No wasted words; all content contributes to understanding the tool's capabilities.
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?
Given 8 parameters, no schema descriptions, and no output schema, the description is too thin. It omits the required model_id, does not clarify property filter dependencies, and gives no indication of what the response contains. A search tool with this complexity needs more detail.
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 0%, so the description carries the full burden. It explains filter semantics but uses different wording than parameter names (e.g., 'name substring' vs 'name_contains') and completely omits the required model_id. The relationship between property_name and property_value is ambiguous, and limit/offset are only mentioned as 'pagination' without detail.
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 clearly states the tool's purpose: 'Search elements with optional filters' and lists the filter types. It is distinct from sibling tools like get_elements_by_type by supporting multiple filter combinations, though it does not explicitly name alternatives.
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?
Usage is implied through the filter list and pagination support, but there is no explicit guidance on when to prefer this tool over get_elements_by_type, get_element_by_id, or other sibling tools. No exclusions or edge-case advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the return format and does not mention error conditions, permissions, side effects, or any other behavioral traits. This is minimal transparency for a tool with zero annotation support.
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, direct sentence that front-loads the primary action and includes the return format. There is no wasted text.
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?
This is a simple getter with two parameters and no output schema. The description provides the return structure, which is helpful, but it lacks context on when to use this vs. sibling tools, what constitutes a valid element, or error handling. It is minimally sufficient but has gaps given the absence of annotations and schema descriptions.
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?
The input schema has no descriptions for model_id or global_id, and the description does not compensate. It mentions 'an element' but does not explain that global_id identifies the element or what model_id refers to. The parameter names are somewhat self-explanatory, but the lack of any semantic elaboration keeps this score low.
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 function: 'Get all quantity sets for an element' with a specific return format. This distinguishes it from sibling tools like get_property_sets or get_material by focusing on quantities as the resource.
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?
No explicit when-to-use or alternative guidance is provided. However, the tool name and description imply usage when an agent needs quantity data for an element, which is a reasonable contextual signal. The lack of exclusions or alternatives keeps it at an implied level rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what the tool returns (counts by several categories), which is useful, but it does not describe the output format, whether empty categories are included, or any permission/state requirements. It does not contradict annotations (none provided).
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, front-loaded sentence with no filler. Every word adds value, listing exactly what statistics are provided.
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?
For a simple one-parameter tool with no output schema, the description is mostly complete. It lists all the statistical dimensions returned. However, it would be improved by noting that the model must already be loaded (as sibling tools imply) and by briefly describing the response structure. Given the simplicity, a score of 4 is appropriate.
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?
The schema has 0% description coverage, and the description does not explain the 'model_id' parameter at all. The parameter name is somewhat self-explanatory, but no context is added about the type of ID, whether it must refer to a currently loaded model, or how to obtain it.
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 states a specific verb ('Get') and a specific resource ('element counts') with clear grouping dimensions (IFC type, storey names, schema version, total count). This clearly distinguishes it from sibling tools like get_elements_by_type or get_element_count (which likely return element data rather than statistics).
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 about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or when a different tool would be more appropriate. The usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. The verb 'Get' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it mention error conditions (e.g., what happens if the model has no spatial structure) or performance implications for large models. The 'full spatial hierarchy' hints at the return structure but does not disclose whether it is a flat list or a tree.
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 sentence that is immediately informative and front-loaded with the key action ('Get the full spatial hierarchy'). There is zero fluff or redundant phrasing, making it highly efficient for an AI agent to parse.
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?
For a simple getter with one required parameter and no output schema, the description provides the essential purpose and the expected hierarchy levels, which is useful. However, it lacks details about the return format (IDs vs. names, ordering, nesting), whether the operation requires a loaded model, and any limitations or prerequisites. Given the minimal sibling context, it is adequate but not comprehensive.
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?
The schema has 0% parameter description coverage, and the tool description does not explain the model_id parameter beyond saying the tool gets a hierarchy. The parameter's name and title ('Model Id') are self-explanatory, but the description fails to state that the model_id should reference a currently loaded model or how to obtain it. This is a gap that the description should compensate for given the low schema coverage.
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 a specific action (Get) and resource (full spatial hierarchy) with an explicit hierarchy chain (Project > Site > Building > Storey > Space). This distinguishes it from sibling tools like get_element_containment or get_model_statistics, which could be confused with spatial queries.
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?
The description implies when to use this tool (when you need the complete spatial hierarchy), but it does not provide explicit alternatives or exclusions. For example, it doesn't mention that get_element_containment might be more appropriate for querying specific containment relationships, nor does it state any prerequisites like having the model loaded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output (min/max XYZ and dimensions) but does not mention error behavior, units, or side effects. For a read-only getter this is acceptable but not rich.
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 concise sentence, front-loaded with the verb and resource, and contains no filler or redundant 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?
For a simple getter tool, the description is fairly complete: it states the resource and output. Lacking an output schema, it describes the return content. It does omit details like units and error handling, but these are not critical for a basic read operation.
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 description coverage is 0%, so the description must compensate. It does not explain model_id or global_id beyond their names. While the names are self-explanatory in an IFC context, the description adds no parameter semantics.
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 action ('Get') and resource ('bounding box'), with specific scope ('of an element in project coordinates'). This distinguishes it from sibling 'get_element_local_bbox' by specifying project coordinate space.
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?
The description implies usage (when needing a bounding box in project coordinates) but does not explicitly mention when not to use it or point to alternatives like 'get_element_local_bbox'. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates a read-only 'get' operation and specifies the output chain, but does not disclose error behavior, whether the element itself is included, or the exact return format. It adds some transparency by naming the hierarchical levels, but leaves room for interpretation.
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 sentence that front-loads the core purpose and includes a helpful parenthetical hierarchy. There is zero wasted wording; it earns its place.
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?
Given no output schema and no annotations, the description is too brief to be complete. It does not describe the return format (e.g., list vs. nested object), the order of the chain, error handling, or behavior when the element is missing. For a tool with only two parameters and no other documentation, this is a significant gap.
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 description coverage is 0%, and the description does not explain the parameters 'model_id' and 'global_id'. While their names are somewhat self-explanatory, the description only mentions 'an element' without linking it to 'global_id' or specifying the model context. The description adds minimal value beyond the schema parameter names.
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 function: 'Get the spatial containment chain for an element' and even outlines the hierarchy (Space > Storey > Building > Site). This is specific and distinguishes it from sibling tools like 'get_spatial_structure' or 'get_element_by_id' by detailing the exact output scope.
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 provides clear context for when to use the tool—whenever you need an element's containment hierarchy. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident and unambiguous, so the usage 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?
With no annotations, the description takes on the burden of explaining behavior. It explicitly describes the return format and the special case for layered assemblies (layers being None). It doesn't discuss error behavior, but given it's a getter, side effects are unlikely and the read-only nature is implied.
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 two sentences, front-loaded with the core purpose, and provides essential return details efficiently. No filler words or redundancy.
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?
The return value details are disclosed, which is critical since no output schema exists. However, the lack of parameter guidance and usage context among many sibling tools leaves some ambiguity for correct invocation, but it is adequate for a simple getter.
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 0% and the description adds no explanation for model_id or global_id. While 'for an element' hints that global_id identifies an element, model_id is undefined. The description fails to compensate for the lack of schema descriptions.
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 'Get material information for an element' with a specific verb and resource. It also details the return structure (name, layers, category), distinguishing it from sibling tools like get_element_by_id or get_property_sets.
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?
There is no guidance on when to use this tool versus alternatives. It only states what it does, without indicating situations where it should be preferred or excluded. No sibling tool is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pagination support ('Supports pagination via limit/offset'), which is a behavioral detail not present in annotations (as there are none). It does not mention error handling, return format, or read-only nature, but the core behavior is clear. With no annotations, the description carries the burden but only partially covers behavioral context.
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?
Two concise sentences, front-loaded with the primary purpose. Every word earns its place; the pagination note adds value without fluff. Exceptionally tight and clear.
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?
For a simple list tool with 4 parameters and no output schema, the description covers the main purpose and pagination. It misses model_id context, but that is a common parameter across sibling tools. Overall, it provides sufficient context for an AI agent to select and use the tool effectively, though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning to parameters. It explains ifc_type via examples (IfcWall, IfcDoor) and limit/offset via pagination mention. However, model_id (a required parameter) is not described. This partial compensation warrants a middle score.
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 function: 'Get elements of a given IFC type' with concrete examples (IfcWall, IfcDoor). The verb 'Get' and resource 'elements by type' are specific, and the examples remove ambiguity. It distinguishes itself from siblings like get_element_by_id (single element) and search_elements (search-based).
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?
The description implies the use case: when you need elements filtered by IFC type. However, it does not explicitly state when to use this tool over alternatives like search_elements or get_elements_batch. No when-not or exclusions are provided, so it remains at an implied-usage level rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful context: it's a query, lists include options and a default, and highlights efficiency. However, the stated default (['entity_label', 'placement']) conflicts with the input schema's default (null), which is misleading. It also does not mention return format or side effects.
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 concise: two sentences, no fluff, and the option list is compactly integrated. Every phrase contributes meaning.
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?
The description covers the core purpose and include options, but omits return value structure, potential limits, and error behavior. The schema-default contradiction further undermines completeness, leaving gaps for an agent to interpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has zero descriptions, the description adds value by enumerating valid include options and a default, but that default contradicts the schema. It only vaguely references global_ids via 'by GlobalId' and does not explain model_id, leaving those parameters under-specified.
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 this is a batch query for elements by GlobalId, distinguishing it from singleton queries like get_element_by_id. The mention of include options further specifies the tool's functionality.
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 explicitly notes the tool avoids multiple round-trips for files with 200+ fixtures, giving a clear use case. However, it does not explicitly contrast with alternatives or state when not to use it.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool does not tessellate geometry, and it specifies the return fields (representation type, identifier, items with IfcMappedItem details including mapping_target_is_identity and mapping_target_matrix). This adds meaningful behavioral context beyond what a minimal description would provide.
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, front-loaded with the core action and returns, then a specific use case. Every sentence earns its place with no redundancy or wasted words.
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?
Despite lacking an output schema and annotations, the description gives a solid overview of what the tool returns and its purpose. It is reasonably complete for a two-parameter read-like operation, though it does not explicitly cover potential limitations or edge cases.
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?
The input schema has 0% description coverage and the description does not mention the parameters model_id or global_id at all. It only refers to 'an element' without clarifying the parameter meanings. The agent must infer from the schema alone, which is insufficient.
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 verb 'Get' and the resource 'representation structure of an element without tessellating geometry'. It distinguishes from siblings by explicitly mentioning the non-tessellating aspect and the specific return details (IfcMappedItem details).
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 provides a clear use case: 'Use to detect baked rotations before geometry extraction.' This gives context for when to use the tool. It does not explicitly state exclusions or alternatives, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the core action (loading an IFC file) and the return value, but does not disclose potential side effects (e.g., memory usage, time to load), error behavior, or what 'load' entails beyond returning an ID. This is minimal but adequate for a simple loader.
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, front-loaded sentence that efficiently conveys the action and return value. Every word earns its place, with no redundancy or unnecessary detail.
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?
For a tool with one simple parameter and no output schema, the description is reasonably complete. It explains the return value and that it is intended for subsequent queries, which covers essential usage context. However, it lacks any detail about error handling or the nature of the file path, so it is not a perfect 5.
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?
The schema has only one parameter 'path' with no description, and the description merely says 'from the given path,' adding no additional meaning. It does not specify path format, valid file extensions, or whether it is a local path, URL, etc. Since schema coverage is 0%, the description must compensate but largely restates the parameter name.
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 a specific verb+resource pattern: 'Load an IFC file from the given path.' This directly states the tool's function and clearly distinguishes it from sibling query tools and the unload tool. The return value is also specified, making the purpose unambiguous.
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 phrase 'Returns model_id for subsequent queries' implies that this tool is a prerequisite for using the query tools, providing clear usage context. However, it does not explicitly state when not to use this tool or directly name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds context about the label format and states that the response matches get_element_by_id, but it does not describe error behavior (e.g., label not found) or explicitly confirm the operation is read-only.
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 two sentences, front-loaded with the action and key, and the second sentence provides a practical use case. No filler or redundant repetition of schema details.
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?
The description covers purpose, label format, and use case, and references get_element_by_id for return semantics. Given the tool's simplicity and absence of output schema, this is mostly complete, though error behavior and response structure rely on sibling tool awareness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 entity_label as an integer IFC label (#NNN from STEP file), but model_id is not described beyond its name. The description adds value for one parameter but leaves the other to inference.
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 looks up an element by its IFC entity label (#NNN from the STEP file). It distinguishes from get_element_by_id by noting it returns the same response via a different key, making the purpose specific and unambiguous.
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 provides a concrete use case (cross-referencing import log output) and implies that get_element_by_id is the alternative when you have an ID. However, it does not explicitly mention when not to use this tool or list other alternative lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool lists models currently in memory, but it does not disclose return format (e.g., IDs, names), whether the list is ordered, or how empty states are handled. This is a minimum viable description with clear gaps.
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, front-loaded sentence with no redundant words. Every word earns its place, making it highly concise and well-structured.
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 (no parameters, no output schema), the description is nearly complete for an agent to understand its purpose. However, it could briefly mention what the returned list contains (e.g., model IDs or names) to fully round out the 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?
The tool has zero parameters, so a baseline of 4 is appropriate per the rubric. The description adds no parameter-specific details because none exist, but it does provide context that the list covers all loaded models, which contributes to overall semantics.
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 a specific verb+resource combination ('List all IFC models currently loaded in memory') that clearly identifies the tool's function. It distinguishes itself from sibling tools like load_ifc_file and unload_ifc_file by focusing on querying the current state.
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?
The description implies usage by indicating it lists loaded models, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. It does not mention related tools like load_ifc_file or unload_ifc_file, so guidance is only implicit.
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?
With no annotations, the description carries the full burden, and it discloses the return content (min/max XYZ and dimensions) and the key behavior that no world transform is applied. This goes beyond a simple 'get bounding box' and clarifies the coordinate system, though it doesn't address error behavior or edge cases.
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 concise at three sentences, front-loaded with the primary action and followed by return details and use cases. No redundant or filler content is present.
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?
The description covers the key aspects needed for a simple query tool: what it returns, the coordinate system, and use cases. It doesn't explain error handling or parameter specifics, but given the simplicity, it is reasonably 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?
The schema provides no descriptions for model_id or global_id, and the description does not elaborate on their meaning or format. The parameter names are somewhat self-explanatory, but the description adds no value beyond the 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 gets the local-space bounding box of an element, specifying it returns min/max XYZ and dimensions in the element's own coordinate system. It distinguishes this from the sibling get_bounding_box by highlighting 'no world transform applied'.
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 provides two explicit use cases: mounting axis prediction and recessed fixture detection. It does not explicitly mention when to avoid this tool or name alternatives for world-space bounding boxes, but the local vs. world contrast is implied.
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?
No annotations are provided, so the description carries the full burden. It discloses what is returned (insertion point and orientation axes as unit vectors) and that the placement is world-space. It does not mention side effects or errors, but as a getter this is acceptable and the description adds meaningful behavioral context beyond the schema.
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 two sentences and front-loaded with the core functionality, followed by a concise use-case rationale. Every sentence earns its place without redundancy or unnecessary detail.
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?
For a simple getter with no output schema and no annotations, the description adequately covers the purpose, output (insertion point and orientation), and intended use cases. It lacks explicit mention of prerequisites or error behavior, but for this level of complexity the description is mostly 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 description coverage is 0%, so the description must compensate for parameter explanations. It does not explain model_id or global_id beyond the schema's property names, and instead refers only to 'an element'. The parameter names are somewhat self-explanatory but the description adds no additional meaning or context on how to obtain these identifiers.
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 function: 'Get the world-space placement of an element' and explicitly lists the returned data ('insertion point (XYZ) and orientation axes (X/Y/Z unit vectors)'). This distinguishes it from siblings like get_element_local_bbox or get_representation by specifying world-space and orientation outputs.
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 provides a clear use-case context: 'Useful for position, rotation, and aim direction of elements like luminaires.' It implies when to use the tool but does not explicitly mention alternatives or when not to use it, giving it a clear context without exclusions.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It goes beyond a generic 'get property sets' by revealing that results are split into instance-level and type-level categories, and explains the interpretive purpose. This adds meaningful behavioral context beyond the bare function.
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 two concise sentences, front-loaded with the core function and followed by a practical use case. Every word contributes meaning with no redundancy or filler.
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?
For a low-complexity read tool with no annotations and no output schema, the description provides the essential purpose, behavior, and use case. It does not detail the exact return structure, but the conceptual split into instance-level and type-level is sufficient for an agent to understand what to expect.
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?
The input schema has 0% description coverage, and the description does not explain the meaning or usage of model_id and global_id. While the parameter names are somewhat self-explanatory, the description does not explicitly link global_id to an element identifier or provide any constraints, leaving a gap for an agent that lacks context.
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 a specific verb ('Get') and resource ('property sets'), and explicitly differentiates this tool from its sibling get_property_sets by highlighting the split-by-source behavior. It clearly states what the tool does and is distinguishable from alternatives.
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 provides a clear use case: 'Use to determine whether a property was overridden at instance level or inherited from the type.' This indicates when to use the tool, though it does not explicitly mention alternatives or when-not-to-use scenarios.
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?
With no annotations, the description carries full responsibility for behavior. It details the exact return values (has_mapped_item, body_mapping_matrix, world_transform, determinant, is_mirrored) and even explains the determinant sign meaning. This gives the agent a clear model of what to expect.
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 compact yet rich, using two clear sentences to communicate purpose, return values, and a key use case. Every word adds value, with no redundancy or filler.
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?
Despite no output schema, the description fully enumerates the return values and their semantic meaning (e.g., is_mirrored derived from determinant sign). It also provides practical context (baked rotations) and sufficient detail for a getter tool with only two identifier parameters.
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 description coverage is 0%, and the description does not elaborate on model_id or global_id. While the schema property names and titles are self-explanatory, the description adds no parameter-level meaning, failing to compensate for the low coverage as required.
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 retrieves a body mapping matrix for elements with IfcMappedItem geometry, using specific verbs ('Get') and resource nouns. It differentiates from siblings by focusing on mapped item transformations, with an explicit use case for detecting baked rotations in luminaire imports.
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 when to use the tool via 'Essential for detecting baked rotations in luminaire imports,' but does not explicitly contrast with alternatives like get_element_placement or get_representation. It provides situational context but lacks explicit exclusionary guidance.
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:

[![Ifc-Mcp MCP server](https://glama.ai/mcp/servers/WolfzTech/Ifc-Mcp/badges/card.svg)](https://glama.ai/mcp/servers/WolfzTech/Ifc-Mcp)

Score Badge

Copy to your README.md:

[![Ifc-Mcp MCP server](https://glama.ai/mcp/servers/WolfzTech/Ifc-Mcp/badges/score.svg)](https://glama.ai/mcp/servers/WolfzTech/Ifc-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/WolfzTech/Ifc-Mcp'

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