Skip to main content
Glama
bisingwaj

AutoCAD MCP

by bisingwaj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Mesurer le dessin

measure
Read-onlyIdempotent

Inspect and quantify an existing AutoCAD/DXF drawing: entity counts, layer/type breakdowns, cumulated lengths and areas, nearest entities, and window contents without listing every entity.

Instructions

Mesure et résume le dessin sans l'énumérer. UN SEUL outil, dont le champ mode choisit la question:

  • summary: état des lieux complet — combien d'entités, sur quels calques, de quels types, entre quelles limites.

  • totals: longueur et surface cumulées.

  • by_layer / by_type: les mêmes quantités, réparties par calque ou par type.

  • quantities: la nomenclature, une ligne par couple calque/type.

  • nearest: les entités les plus proches d'un point, avec leur distance. Répond à « qu'y a-t-il ici ».

  • in_window: les entités d'une zone rectangulaire, au choix entièrement contenues ou simplement traversées.

À utiliser AVANT de modifier un dessin que vous n'avez pas produit, pour savoir ce qu'il contient sans rapatrier ses entités une à une, et APRÈS un lot pour vérifier des quantités. Pour voir le dessin plutôt que de le chiffrer, utilisez render_view; pour obtenir les handles d'entités précises, query_entities.

HONNÊTETÉ DES MESURES: longueurs et surfaces ne sont comptées que pour les entités dont le moteur les publie. Chaque mesure porte donc counted, missing et complete, et son total vaut null — et non zéro — quand aucune entité n'a répondu. Un total de zéro signifierait « rien ne mesure », ce qui est faux; null signifie « le moteur ne le dit pas ». Les comptes d'entités, eux, sont toujours exacts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoQuestion posée. "nearest" exige point, "in_window" exige window; les autres modes les ignorent.summary
typeNoRestreint la mesure à ce type DXF. Omis: tous les types. Exemple: "LWPOLYLINE".
layerNoRestreint la mesure à ce calque, par nom exact. Omis: tout le dessin. Exemple: "WALLS".
limitNoNombre maximal d'entités décrites par nearest et in_window. Défaut 200, plafond dur 1000. Sans effet sur les autres modes, dont la réponse est déjà un résumé.
pointNoPoint de référence du mode nearest. Couple [x, y] dans l'unité du document. Exemple: [2.5, 1.5].
windowNoFenêtre [xmin, ymin, xmax, ymax] du mode in_window, dans l'unité du document. Les deux coins peuvent venir dans n'importe quel ordre. Exemple: [0, 0, 10, 8].
window_modeNoMode de sélection par fenêtre, au sens d'AutoCAD. "inside" ne garde que ce qui tient entièrement dans la fenêtre, "crossing" garde aussi ce qui la traverse. Sur un plan, le premier rend les pièces d'une zone, le second rend en plus les murs qui la bordent.inside

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds genuinely new behavioral context: measurements are only counted for entities the engine publishes, each result carries counted/missing/complete, and totals are null rather than zero. That null-vs-zero semantics directly prevents a wrong agent inference.

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?

Front-loaded with the core verb and a per-mode bullet list that maps one-to-one onto the enum, followed by usage and honesty sections. Despite its length, every block carries information for a 7-parameter, 7-mode tool; nothing is restated from the schema verbatim.

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 must carry return-value burden and does: it sketches what each mode returns (entity counts, layers, types, limits; cumulative length and area; one line per layer/type pair; nearest entities with distance). Combined with the usage and null-semantics notes, an agent has enough to select a mode and interpret the result.

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 already documents all seven parameters, giving a baseline of 3. The description goes further by stating what question each mode enum value answers and by interpreting window_mode in drafting terms ("les pièces d'une zone" vs "les murs qui la bordent"), which is meaning the schema does not supply.

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?

Opens with a specific verb+resource ("Mesure et résume le dessin") and immediately states the scope ("sans l'énumérer"), which distinguishes it from query_entities. It explicitly names the two closest siblings (render_view, query_entities) and the conditions separating them.

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?

Gives explicit when-to-use triggers ("AVANT de modifier un dessin que vous n'avez pas produit", "APRÈS un lot pour vérifier des quantités") and routes the agent to alternatives: render_view "pour voir le dessin" and query_entities "pour obtenir les handles". This is textbook when/when-not/alternative guidance.

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