Skip to main content
Glama
bisingwaj

AutoCAD MCP

by bisingwaj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Vérifier le plan

check_plan
Read-onlyIdempotent

Check plans for hidden defects like unclosed contours, overlapping entities, and misaligned walls. Get severity, coordinates, and one-sentence remedies to correct drawings before delivery.

Instructions

Cherche les défauts qu'un dessin ne signale jamais de lui-même: contours qui ne se referment pas et refusent la hachure, murs qui se croisent en croix au lieu de se rejoindre, entités superposées en double, résidus de taille négligeable, extrémités qui se ratent d'un cheveu.

À appeler APRÈS un lot de construction et AVANT de livrer un plan: c'est ce qui vous permet de vous corriger seul. Chaque défaut est rendu avec sa gravité, sa localisation en coordonnées, les objets concernés et un remède en une phrase, directement exécutable.

CE QUI EST EXAMINÉ. Les entités du document, telles que le moteur les publie, donnent les doublons et les résidus. Les contours et les axes de murs, eux, doivent être FOURNIS dans contours et segments: le moteur ne publie que des boîtes englobantes, pas les sommets, et deviner une géométrie serait pire que l'avouer. Donnez-y les mêmes points que ceux passés à build_structure, c'est la vérification la plus utile.

Les seuils suivent l'unité du document: à l'échelle du mètre un écart d'un dixième de millimètre est une jonction, à l'échelle du millimètre c'est un trou. La réponse est bornée: le compte des défauts est exact, la liste est tronquée au-delà de 100 entrées.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
layerNoRestreint l'examen des entités du document à ce calque, par nom exact. Omis: tout le dessin. Exemple: "WALLS".
contoursNoContours censés délimiter une surface, à confronter à leur fermeture. Exemple: [{"points": [[0,0],[4,0],[4,3],[0,3]], "ref": "sejour"}].
segmentsNoAxes de murs, ou tout segment droit à confronter aux autres: croisements et trous entre extrémités. Exemple: [{"start": [0,0], "end": [4,0], "ref": "mur sud"}].
toleranceNoÉcart en deçà duquel deux points sont tenus pour confondus, et rayon de recherche des trous entre extrémités. Omise: la tolérance de l'unité du document, qui est le bon choix dans presque tous les cas. Longueur exprimée dans l'unité du document, donnée par get_drawing_info.unit (m par défaut). Exemple: 0.001.
minimum_sizeNoTaille en deçà de laquelle une entité est tenue pour un résidu, mesurée sur la diagonale de sa boîte englobante. Omise: la tolérance. À augmenter pour débusquer les traits parasites d'un plan repris. Longueur exprimée dans l'unité du document, donnée par get_drawing_info.unit (m par défaut). Exemple: 0.01.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds substantial context: defect taxonomy, returned severity/location/objects/remedy, exact count with list truncation beyond 100, and the need to supply geometry because the engine only publishes bounding boxes.

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?

The description is front-loaded with purpose and timing, then organized into focused sections on what is examined and how thresholds behave. It is longer than strictly necessary, but nearly every sentence carries decision-relevant information.

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 five-parameter validation tool with no output schema, the description covers inputs, expected output shape, truncation behavior, unit scaling, and workflow placement. Nothing an agent needs in order to call it correctly appears to be missing.

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 schema documents each parameter in detail and the baseline is 3. The description still adds meaning by explaining why contours and segments must be supplied, tying them to build_structure, and noting that thresholds follow the document unit.

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, 'cherche les défauts', and a specific resource, the plan/drawing, then enumerates the defect classes it detects. This distinguishes it clearly from siblings such as build_structure and query_entities without requiring the schema to be opened.

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?

Explicitly says to call it AFTER a construction batch and BEFORE delivering a plan, making the workflow position unambiguous. It also directs the agent to supply the same points used by build_structure for the most useful check.

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