multiCAD-mcp-server

Overview Schema Source Related Servers Discussions Admin

prompt_user

Pauses CAD execution to request human mouse clicks, coordinate picks, entity selection, or command-line input for human-in-the-loop workflows. Returns picked coordinates, handles, typed text, or cancellation status.

Instructions

Prompt the human user for interactive mouse clicks, coordinate picking, or command line input in CAD.

Behavior:

Mutation: Strictly read-only for drawing geometry; does not alter drawing database.
Persistence: No persistent side effects or disk modifications.
Side Effects: Pauses execution to display prompt message in CAD command line and crosshair cursor, awaiting user mouse click or keyboard input. Captures ESC / cancellation gracefully.

Usage Guidelines:

When to Use: Call for Human-in-the-Loop workflows whenever the AI needs the user to click a coordinate on screen, pick an entity visually with the crosshairs, measure a distance interactively, or confirm a string prompt.
Sibling Routing / Alternatives:
- For automated programmatic coordinate queries without user intervention, use inspect_drawing.
- For selecting entities programmatically by layer/color/type, use manage_entities(operations="select|...").
- For launching an interactive web-based canvas viewer in the browser, use show_drawing_viewer.

Shorthand Grammar:

point|message|[base_x,base_y]: Prompts user to click a point in CAD viewport (e.g. point|Click door hinge point).
entity|message: Prompts user to click an entity on screen (returns entity handle, type, and layer).
distance|message|[base_point]: Prompts user to pick two points or measure distance in CAD.
string|message: Prompts user to type text in CAD command bar.

Parameters:

input: Shorthand string (action|message|optional_args), dictionary, or list.

Returns: JSON string containing user response, picked coordinates (x, y, z), picked entity handles, or cancellation status.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

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 carries the full burden and meets it: it declares the operation read-only with respect to drawing geometry, states there are no persistent side effects, and crucially discloses the blocking behavior ('Pauses execution ... awaiting user mouse click or keyboard input') plus graceful ESC/cancellation handling. For a tool that halts the agent loop on human input, this is exactly the behavioral context needed.

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 purpose, then cleanly sectioned into Behavior, Usage Guidelines, Grammar, Parameters and Returns, so an agent can skim to what it needs. Slightly heavier than necessary: the Returns section restates information that an output schema already supplies, and the shorthand grammar, while useful, is dense.

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?

An output schema exists, so the description does not need to own return-value documentation, and it covers everything else a caller needs: the blocking/human-in-the-loop nature, the cancellation path, exact input grammar, and routing away from non-interactive siblings. Nothing required to invoke it correctly is missing.

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?

Schema description coverage is 0% on a single, loosely-typed anyOf parameter, so the description must compensate and does: it explains that input is a shorthand string/dictionary/list and gives the full 'action|message|optional_args' grammar with four concrete action variants and expected return payloads per action.

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 (Prompt) with a specific resource (the human user) and enumerates the exact interaction types: mouse clicks, coordinate picking, command line input in CAD. This is clearly distinguishable from siblings like inspect_drawing and show_drawing_viewer.

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?

Explicit 'When to Use' block names human-in-the-loop workflows, and the 'Sibling Routing / Alternatives' section routes three named siblings (inspect_drawing for programmatic queries, manage_entities for programmatic selection, show_drawing_viewer for browser canvas) with the 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