Skip to main content
Glama

Navisworks MCP

by io.scanbimlabs
OverviewAdmin

nwd_get_clashes

Detect geometric/logical clashes between two element sets in an already-translated Navisworks model. Uses APS Model Derivative property extraction + same-level proximity heuristics, optionally augmented by VDC rules stored in D1 (table vdc_rules).

When to use: when coordinating federated MEP + structural + architectural models for clash review before issuing an RFI; e.g. "find duct vs. beam clashes on Level 3 before the Wed coordination meeting" or "sanity-check the latest MEP revision against structure before releasing for fabrication." Pair with nwd_export_report to produce a deliverable.

When NOT to use: do not call on a model whose translation is still "inprogress" — call nwd_export_report first and confirm translation_status == "success"; not a substitute for Navisworks Manage Clash Detective for final sign-off (this is a coordination-stage screen, not a regulatory clash report).

APS scopes required: viewables:read data:read (read-only — does not create anything in APS).

Rate limits: APS default ~50 req/min per endpoint; Model Derivative metadata/properties endpoints are the bottleneck. Properties response may return 202 "isProcessing" on first call — the worker retries once after 3s. For very large models (>50k elements) the worker caps analysis at 50x50 element cross-compare and 100 reported clashes; re-run with tighter category_a/category_b filters for exhaustive coverage.

Errors: 401 APS token expired (transient, retry); 403 missing viewables:read/data:read scope (report, do not retry); 404 URN not found or not translated (prompt user to re-run nwd_upload); 409 not applicable; 422 model translated but property index unavailable — typically means source NW version unsupported or translation partially failed (supported: Navisworks 2015+); 429 rate limit (backoff); 5xx APS upstream (retry once). If properties.data.collection is empty the tool returns clash_count: 0 with a note rather than erroring — the agent should treat that as "model not ready" and retry later.

Side effects: none in APS. Reads vdc_rules from D1 when both categories are supplied. Logs usage to D1 usage_log. Idempotent — same inputs on a stable model yield the same clash list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_idYesBase64url-encoded URN of the translated Navisworks model, exactly as returned by nwd_upload.model_id (or the urn field). Do NOT re-encode. Starts with "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6" for OSS-derived URNs.
category_aNoFirst element-set filter, case-insensitive substring match against each element's Revit/Navisworks Category. Common values: "Mechanical", "Ducts", "Pipes", "Plumbing", "Electrical", "Structural Framing", "Structural Columns", "Walls", "Floors", "Ceilings". Omit (with category_b) to auto-split MEP vs. structural.
category_bNoSecond element-set filter, same semantics as category_a. Must be supplied together with category_a to take effect — supplying only one is ignored in favor of auto-split. Provide both to also look up matching VDC rules from D1.
clash_typeNoClash severity class. "hard" = solid-solid interference (e.g. duct through beam) — returns severity:critical. "soft" = clearance/tolerance violations (e.g. MEP within 50mm of structure) — returns severity:warning. "all" = both. Defaults to "all" when omitted.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changed
    • changedInput schema / properties / category_a / description
      Previous value: -"Optional first category filter (e.g. \"Mechanical\")"New value: +"First element-set filter, case-insensitive substring match against each element's Revit/Navisworks Category. Common values: \"Mechanical\", \"Ducts\", \"Pipes\", \"Plumbing\", \"Electrical\", \"Structural Framing\", \"Structural Columns\", \"Walls\", \"Floors\", \"Ceilings\". Omit (with category_b) to auto-split MEP vs. structural."
    • addedInput schema / properties / category_a / examples
      Added value: +[
+  "Mechanical",
+  "Ducts",
+  "Structural Framing"
+]
    • changedInput schema / properties / category_b / description
      Previous value: -"Optional second category filter (e.g. \"Structural\")"New value: +"Second element-set filter, same semantics as category_a. Must be supplied together with category_a to take effect — supplying only one is ignored in favor of auto-split. Provide both to also look up matching VDC rules from D1."
    • addedInput schema / properties / category_b / examples
      Added value: +[
+  "Structural",
+  "Structural Columns",
+  "Walls"
+]
    • changedInput schema / properties / clash_type / description
      Previous value: -"Type of clashes to detect"New value: +"Clash severity class. \"hard\" = solid-solid interference (e.g. duct through beam) — returns severity:critical. \"soft\" = clearance/tolerance violations (e.g. MEP within 50mm of structure) — returns severity:warning. \"all\" = both. Defaults to \"all\" when omitted."
    • addedInput schema / properties / clash_type / examples
      Added value: +[
+  "hard",
+  "all"
+]
    • changedInput schema / properties / model_id / description
      Previous value: -"Base64-encoded URN of translated model"New value: +"Base64url-encoded URN of the translated Navisworks model, exactly as returned by nwd_upload.model_id (or the urn field). Do NOT re-encode. Starts with \"dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6\" for OSS-derived URNs."
    • addedInput schema / properties / model_id / examples
      Added value: +[
+  "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6c2NhbmJpbS1ud2QtMTcxMjM0NTY3OC9Ub3dlckFfTUVQU3RydWN0X1IwNy5ud2Q"
+]
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: read-only APS scopes, rate limits, retry behavior, detailed error codes (401/403/404/422/429/5xx), idempotency, and side effects (D1 logging). It also discloses how empty collections are handled, providing complete operational transparency.

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 long but well-structured with clear headings (When to use, When NOT to use, APS scopes, Rate limits, Errors, Side effects). Every sentence carries actionable information, and the purpose is front-loaded. 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 lacking an output schema, the description explains expected result semantics (severity levels, clash_count zero behavior) and provides comprehensive error handling guidance. It covers all relevant operational contexts, making it fully actionable for an AI agent.

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?

Although schema description coverage is 100%, the description adds critical interaction semantics beyond the schema: category_a/b must be supplied together or are ignored, auto-split behavior when omitted, and model_id must not be re-encoded. These details are not in the schema and are essential for correct invocation.

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 it 'Detect geometric/logical clashes between two element sets in an already-translated Navisworks model,' which is a specific verb+resource. It clearly distinguishes from siblings like nwd_export_report and nwd_get_viewpoints by focusing on clash detection.

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?

The description explicitly includes 'When to use' and 'When NOT to use' sections with concrete coordination scenarios (e.g., 'find duct vs. beam clashes on Level 3 before the Wed coordination meeting'). It also tells when to call nwd_export_report first and warns against using the tool when translation is still in progress.

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

All Navisworks MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources