set_title_block

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: the block is composed by AnkusDrive rather than the bare default template, it only renders on SVG/PDF export, and calling the tool is what enables rendering. It omits whether the call is idempotent or what happens to previously set fields.

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

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

Front-loaded with the core action and the export/rendering constraint immediately after; the machinist rationale is a mild flourish but it justifies the field set, and the return-shape note is placed last. Only slight trimming would help.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with no annotations and no output schema, the description covers the important gaps: export-time behavior, auto-derivation vs override semantics, and the return shape {handle, name, fields}. It stops short of explaining required-ness of page or the drawing-workflow prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for 8 parameters, so the description must compensate. It adds real meaning by explaining that scale/sheet size/units/part name are auto-derived and that the provided fields override or supplement them, and it names material/units/part explicitly, but rev, date, project, drawn_by and the required page parameter are never characterized.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (populate) and resource (the drawing's title block in the bottom-right corner on SVG/PDF export), and the AnkusDrive/FreeCAD framing distinguishes it from the generic drawing siblings like add_annotation or add_dimension.

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

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

Clearly states the context of use (a machinist needs material + scale + units to cut from the sheet) and the key condition that calling it opts the page into rendering the block, but never says when NOT to call it or how it relates to export_drawing/fit_page sequencing.

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