Skip to main content
Glama
U-C4N
by U-C4N

Drawing Properties (write)

drawing_properties_set

Write SummaryInfo fields and custom properties into a drawing. Only the arguments you pass are touched, and a null value deletes that custom key.

Instructions

Write DWGPROPS fields. Only the arguments given are touched; returns summary_written, custom_written and custom_deleted (a key that was never there is not reported deleted).

Refusals, before anything is written: a summary field on the headless engine (capability: dwgprops — SummaryInfo lives in the DWG, a DXF has no slot for it; custom properties still work headlessly), a non-string value (TypeError naming the field or key — nothing is coerced with str()), an empty custom key, a custom key to write that AutoCAD's AddCustomInfo would reject mid-write (measured on AutoCAD 2026: leading or trailing whitespace, or any of the thirteen characters " * , / : ; < = > ? \ |anywhere in the key; internal spaces, tabs and unicode are fine —ValueErrornaming the key, on both engines; a delete is exempt because RemoveCustomByKey never validates syntax, so a key that reached the drawing another way stays removable), two keys in one request that AutoCAD would call the same key (its key compare is a simple per-character case compare:Project/PROJECTandGrün/GRÜNare one key,Straße/STRASSE are two), a line break in a custom key or value (it corrupts the DXF on save), and headlessly a document older than R2004 (ValueError` — ezdxf only writes the custom-property header pairs for AC1018+, so they would vanish at save; save as R2004 or newer first). A key is matched to the drawing by that same rule on both engines and keeps its stored spelling when updated. On the live engine an exact spelling is changed with SetCustomByKey; otherwise AutoCAD decides — AddCustomInfo, and on its 'Duplicate key' SetCustomByKey; a delete is RemoveCustomByKey, and its 'Key not found' is reported as not deleted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoSummaryInfo Title
authorNoSummaryInfo Author
customNoCustom properties to write: {key: text}; a null value deletes the key. Keys not mentioned are left alone.
subjectNoSummaryInfo Subject
commentsNoSummaryInfo Comments
keywordsNoSummaryInfo Keywords

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=false; the description carries the rest and does so richly: partial-update semantics, the returned keys (summary_written/custom_written/custom_deleted), the not-deleted-on-missing-key nuance, engine-specific key-matching behavior (SetCustomByKey vs AddCustomInfo), and the case-compare and character-rejection rules. This is far beyond what structured fields provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and return values are front-loaded, but the refusals material is a single dense paragraph with deep nested parentheticals that is hard to scan. Much of it is genuinely useful, yet the structure works against quick consumption.

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 mutation tool with no destructive annotation, the description covers write scope, refusal preconditions, cross-engine divergence, and return semantics. An output schema exists, yet the extra explanation of the returned keys is accurate and harmless; nothing needed to call 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: custom keys are matched by AutoCAD's case-compare rule, updates keep the stored spelling, and null deletes a key. The key-validation and case-collision details cannot be inferred from the schema's {key: text} description.

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 ('Write DWGPROPS fields') and immediately scopes the mutation ('Only the arguments given are touched'), which lets an agent separate it from the read-side sibling drawing_properties_get without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear about the write context and enumerates the exact conditions under which it refuses (headless SummaryInfo, non-string values, bad custom keys, line breaks, pre-R2004 documents) plus the delete-exemption. It never explicitly names drawing_properties_get as the read alternative, so the routing guidance is implied rather than stated.

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