Skip to main content
Glama

Navisworks MCP

by io.scanbimlabs
OverviewAdmin

nwd_export_report

Build a coordination report for a translated Navisworks model: translation status/progress, derivative outputs, available views (2D sheets / 3D viewables), total element count, and a per-category element breakdown. Doubles as the canonical way to poll translation status after nwd_upload.

When to use: after nwd_upload to check whether translation has completed before calling clash/object tools; at the end of a coordination session to generate a status snapshot for the weekly BIM report; when auditing a model revision to confirm expected element counts per discipline.

When NOT to use: do not use for a per-element property dump — use nwd_list_objects; do not use for clash results — use nwd_get_clashes.

APS scopes required: viewables:read data:read bucket:read (read-only).

Rate limits: APS default ~50 req/min per endpoint; this tool issues up to 4 sequential APS calls (manifest, metadata, properties — two with retry). When polling for translation completion, backoff: 5s, 10s, 30s, 60s, 120s — Model Derivative NWD translation typically completes in 1-10 min but large federated models can take 20+ min.

Errors: 401 APS token expired (retry); 403 missing scope (report); 404 URN not found (model was never uploaded or bucket TTL expired); 409 N/A; 422 translation failed permanently — inspect report.translation_status == "failed" and report.derivatives[].status; 429 rate limit (backoff); 5xx APS upstream (retry once). Property extraction may legitimately 202 "isProcessing" — the tool handles retry and then silently swallows to still return manifest/metadata (element_count will be 0 until properties index is built).

Side effects: none. Pure read. Idempotent — report reflects current APS state. Logs usage to D1 usage_log.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoOutput shape. "json" (default) returns the full structured report object including derivatives[], views[], category_breakdown. "summary" still returns the same keys — the parameter is preserved for forward-compatibility and currently echoes back in the response for caller templating.
model_idYesBase64url-encoded URN of the translated Navisworks model as returned by nwd_upload. Same value used by the other nwd_* tools.

Schema Changelog

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

  1. Changed4 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"Report format"New value: +"Output shape. \"json\" (default) returns the full structured report object including derivatives[], views[], category_breakdown. \"summary\" still returns the same keys — the parameter is preserved for forward-compatibility and currently echoes back in the response for caller templating."
    • addedInput schema / properties / format / examples
      Added value: +[
+  "json",
+  "summary"
+]
    • changedInput schema / properties / model_id / description
      Previous value: -"Base64-encoded URN"New value: +"Base64url-encoded URN of the translated Navisworks model as returned by nwd_upload. Same value used by the other nwd_* tools."
    • addedInput schema / properties / model_id / examples
      Added value: +[
+  "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6c2NhbmJpbS1ud2QtMTcxMjM0NTY3OC9Ub3dlckFfTUVQU3RydWN0X1IwNy5ud2Q"
+]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description fully carries the transparency burden. It discloses side effects ('Pure read', 'Idempotent'), rate limits and backoff schedule, error code mappings (401, 403, 404, 422, 429), and the subtle 202 'isProcessing' swallowing behavior. This is exceptional detail for an MCP tool description.

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 well-structured with clear labeled sections (When to use, When NOT, APS scopes, Rate limits, Errors, Side effects). Every sentence contributes unique value; there is no fluff or repetition. Though long, the organization makes it highly scannable and every detail is purposeful.

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?

With no output schema, the description compensates by enumerating report fields (translation_status, derivatives[], views[], category_breakdown, element_count), explaining the format parameter's impact, and detailing error and retry behavior. It covers the full translation-polling lifecycle and edge cases, making it complete for a complex tool.

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%, so the baseline is 3, but the description adds meaningful context beyond the schema: the format parameter's forward-compatibility role and echo behavior, and model_id's linkage to nwd_upload and sibling tools. It does not fully rewrite the schema but enriches it with usage-oriented semantics, earning a 4.

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 ('Build a coordination report') and lists exact report contents. It explicitly differentiates from siblings in the 'When NOT to use' section, naming nwd_list_objects and nwd_get_clashes as alternatives. It also introduces a secondary purpose (poll translation status), making the tool's role unmistakable.

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?

Provides a dedicated 'When to use' section with concrete scenarios (post-upload polling, end-of-session snapshot, revision audit) and a 'When NOT to use' section naming specific alternative tools. This is explicit, actionable guidance that goes far beyond typical descriptions.

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