Skip to main content
Glama

Navisworks MCP

by io.scanbimlabs
OverviewAdmin

nwd_upload

Upload a Navisworks file (.nwd/.nwf/.nwc) to Autodesk Platform Services (APS) Object Storage and start an SVF2 translation job so the model becomes queryable by the other nwd_* tools.

When to use: at the start of a coordination workflow — e.g. the GC hands off a federated NWD combining MEP + structural + architectural models and the agent needs to stage it for clash review before issuing an RFI, or when a subcontractor publishes a new NWC model revision that must be ingested for weekly BIM coordination. Always the first call in a session for any new model.

When NOT to use: do not call for already-translated models (re-use the returned model_id/URN); do not use for raw Revit .rvt, IFC, or DWG — those go through a different MCP.

APS scopes required: data:read data:write data:create bucket:read bucket:create viewables:read. The worker acquires a 2-legged client-credentials token; the caller does not supply one.

Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation job submission ~60 req/min. NWD bundles can be large (hundreds of MB); the upload PUT and translation can take minutes — translation is asynchronous, poll via nwd_export_report (manifest) with exponential backoff (e.g. 5s, 10s, 30s, 60s) before calling clash/properties tools.

Errors the agent should handle: 401 invalid/expired APS token (surface as auth failure — do not retry with same creds); 403 missing scope (report scope gap, do not retry); 404 source file_url unreachable (ask user for a fresh public URL); 409 bucket already exists (handled internally, safe to ignore); 413/422 unsupported Navisworks version — APS Model Derivative supports NWD/NWC from Navisworks 2015 and later (state the unsupported version to the user); 429 rate limited (exponential backoff, retry); 5xx APS upstream (retry once, then surface).

Side effects: creates a fresh transient OSS bucket (scanbim-nwd-, 24h TTL) and uploads the file as an object, then POSTs a Model Derivative translation job. NOT idempotent — each call creates a new bucket/URN even for the same file_url. Logs usage to the D1 usage_log table.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_urlYesPublicly reachable HTTPS URL from which the worker will GET the Navisworks file bytes. Must return the raw binary (not an HTML landing page). Pre-signed S3 URLs, ACC/BIM360 signed-resource URLs, and Cloudflare R2 public URLs all work. Max practical size ~4 GB (Cloudflare Workers fetch body limit applies).
file_nameYesLogical filename for the OSS object. Must end in .nwd, .nwf, or .nwc (case-insensitive) so APS picks the correct translator. Avoid spaces and non-ASCII — the worker sanitizes to [A-Za-z0-9._-]. Follow ScanBIM convention: <project>_<discipline>_<rev>.nwd (e.g. TowerA_MEPStruct_R07.nwd).
project_idNoOptional free-form project label stored alongside the upload record for caller-side correlation. Not sent to APS. Typical values: ACC project GUID, internal job number, or short slug.

Schema Changelog

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

  1. Changed8 schema fields changed
    • changedInput schema / properties / file_name / description
      Previous value: -"Name for the file (e.g. \"Coordination.nwd\")"New value: +"Logical filename for the OSS object. Must end in .nwd, .nwf, or .nwc (case-insensitive) so APS picks the correct translator. Avoid spaces and non-ASCII — the worker sanitizes to [A-Za-z0-9._-]. Follow ScanBIM convention: <project>_<discipline>_<rev>.nwd (e.g. TowerA_MEPStruct_R07.nwd)."
    • addedInput schema / properties / file_name / examples
      Added value: +[
+  "TowerA_MEPStruct_R07.nwd",
+  "LevelB3_Coordination.nwc",
+  "Federated_Model.nwf"
+]
    • addedInput schema / properties / file_name / pattern
      Added value: +".+\\.(nwd|nwf|nwc)$"
    • changedInput schema / properties / file_url / description
      Previous value: -"Public URL to download the NWD/NWC file from"New value: +"Publicly reachable HTTPS URL from which the worker will GET the Navisworks file bytes. Must return the raw binary (not an HTML landing page). Pre-signed S3 URLs, ACC/BIM360 signed-resource URLs, and Cloudflare R2 public URLs all work. Max practical size ~4 GB (Cloudflare Workers fetch body limit applies)."
    • addedInput schema / properties / file_url / examples
      Added value: +[
+  "https://example-bucket.s3.amazonaws.com/projects/tower-a/Coordination_2026-04-18.nwd?X-Amz-Signature=...",
+  "https://files.scanbimlabs.io/levelA_mep_structural_federated.nwd"
+]
    • addedInput schema / properties / file_url / format
      Added value: +"uri"
    • changedInput schema / properties / project_id / description
      Previous value: -"Optional project label"New value: +"Optional free-form project label stored alongside the upload record for caller-side correlation. Not sent to APS. Typical values: ACC project GUID, internal job number, or short slug."
    • addedInput schema / properties / project_id / examples
      Added value: +[
+  "ACC-PROJ-8b2f",
+  "JOB-2026-0418-TowerA"
+]
  2. First observed

TDQS

A4.9/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 excels. It discloses side effects (creates transient bucket, uploads object, POSTs translation job, NOT idempotent, logs usage), rate limits, required APS scopes, asynchronous polling behavior, and a comprehensive list of errors to handle. This is far beyond what annotations might cover and gives the agent complete 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 tightly structured with bold section headers (When to use, When NOT, Scopes, Rate limits, Errors, Side effects). The first sentence is a crisp summary, and every subsequent sentence provides actionable information. There is no filler or repetition of schema details, making it efficient despite its length.

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 parameters, no output schema, and no annotations, the description is remarkably complete. It covers purpose, workflow timing, authentication requirements, rate limits, error handling, and side effects. It even hints at the return value ('re-use the returned model_id/URN') despite no output schema, ensuring the agent knows what to expect and how to proceed.

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?

All three parameters have detailed schema descriptions (100% coverage), so the baseline is 3. The tool description adds an extra constraint not present in the schema: 'APS Model Derivative supports NWD/NWC from Navisworks 2015 and later,' which is relevant to file selection. It also reinforces the purpose of file_name extension and file_url accessibility, but the schema already handles most 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 opens with a specific verb+resource+outcome: 'Upload a Navisworks file (.nwd/.nwf/.nwc) to Autodesk Platform Services (APS) Object Storage and start an SVF2 translation job so the model becomes queryable by the other nwd_* tools.' This clearly states what the tool does, its scope, and how it relates to sibling tools, making it unmistakable from the other nwd_* tools.

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 provides explicit 'When to use' and 'When NOT to use' sections with concrete examples (e.g., GC handoff of federated NWD, subcontractor revision). It names alternatives for other formats (Revit, IFC, DWG go through a different MCP) and advises reusing existing model_id/URN for already-translated models. This is textbook usage guidance.

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