Skip to main content
Glama
Sign In
multiCAD-mcp-server

multiCAD-mcp-server

by jmcaamanog
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

show_drawing_viewer

Generate and launch an interactive HTML5 CAD drawing viewer in the browser for panning, zooming, and clicking rooms or layers, saved as a standalone HTML file.

Instructions

Generate and launch an interactive HTML5 CAD Canvas viewer in the web browser.

Behavior:

  • Mutation: Strictly read-only for CAD geometry; does not alter drawing database or active viewport.

  • Persistence: Saves a standalone HTML viewer file to the configured output directory.

  • Side Effects: Writes a self-contained HTML file to local disk. If open_browser is True, spawns an external process to open the system default web browser.

Usage Guidelines:

  • When to Use: Call when a human user requests interactive visual exploration, panning/zooming, or clicking on rooms/layers in a graphical UI.

  • Sibling Routing / Alternatives:

    • For programmatic spatial queries (bounding box, point raycasting, snap points, ASCII map), use inspect_drawing.

    • For exporting static documents or publication files (vector PDF, BC3, Excel), use export_data.

    • For controlling viewport zoom/camera inside the active CAD software window, use manage_view.

Parameters:

  • filename: Output HTML file name or relative path (default: 'visor_cad.html').

  • open_browser: Whether to automatically launch default web browser (default: True).

Returns: JSON string with status, absolute HTML file path, entity count, and browser launch result.

Tool call template

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

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

Input Schema

NameRequiredDescriptionDefault
filenameNovisor_cad.html
open_browserNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it declares read-only semantics for CAD geometry, discloses that a standalone HTML file is written to disk, and warns that open_browser=True spawns an external browser process. These are exactly the side-effect details an agent needs before calling.

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?

Front-loaded with the core action, then organized into Behavior, Usage, Parameters and Returns sections that are easy to scan. Minor redundancy between 'Saves a standalone HTML viewer file' and 'Writes a self-contained HTML file to local disk.'

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 two-parameter, zero-annotation tool, the description covers purpose, side effects, routing, parameter meaning and a brief return summary (status, path, entity count, launch result). An agent has everything needed to call it correctly.

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 0%, so the description must explain both parameters, and it does: filename is an output file name or relative path, open_browser controls automatic browser launch. It adds path semantics beyond the bare schema types, though the defaults it restates are already visible in 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?

States a specific verb and resource: 'Generate and launch an interactive HTML5 CAD Canvas viewer in the web browser.' This is clearly distinguishable from siblings like inspect_drawing or manage_view, which are named explicitly later.

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 an explicit 'When to Use' condition (human requests interactive panning/zooming or clicking) and a routing block that names three alternatives with the exact condition that selects each. Nothing is left to inference.

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

Deploy Server

Other Tools