Skip to main content
Glama
pzfreo

build123d-mcp

by pzfreo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

render_drawing

Read-only

Convert an SVG file to a PNG image and return it inline, enabling visual inspection of drawings created outside the sandbox without using a separate file viewer.

Instructions

DEPRECATED (#465) — moved to draftwright; off by default in 0.4.0, removed in 0.5.0. Calling it explains the replacement. Rasterise an existing SVG file to PNG via resvg-py.

Complements render_view (which takes build123d shapes from the live
session) by accepting an SVG written outside the sandbox — typically by
a short Python script that does the ExportSVG call directly. The PNG is
returned inline so the LLM can see the drawing without you having to
open the file in another tool.

Args:
    svg_path: path to an SVG file on disk.
    width: output pixel width (default 1200); height set by SVG aspect ratio.
    save_to: optional path to write the PNG. If empty, PNG bytes are
        delivered inline only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthNo
save_toNo
svg_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.27

TDQS

A4.8/5.0
Behavior4/5

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

The readOnlyHint annotation declares the operation is safe, and the description adds useful behavioral context beyond that: the PNG is returned inline so the LLM can inspect it, save_to allows optional file output, and calling a deprecated tool explains the replacement rather than silently doing something else.

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?

The description is compact and well-organized: a clear deprecation warning up front, then the core purpose and comparison, then a terse Args block. Every sentence adds information, and the formatting makes the key decisions easy to parse.

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?

Despite having no output schema, the description conveys the return behavior (inline PNG vs saved file) and the fail-soft deprecated behavior. It also provides enough context about the alternative tools and parameter semantics for an agent to invoke it correctly.

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%, so the description carries the full burden—and it succeeds. It explains svg_path as a path on disk, width as output pixel width with a default and aspect-ratio behavior, and save_to as an optional write path with inline-only behavior when empty. Every parameter is meaningfully documented.

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?

The description clearly identifies the action ('Rasterise an existing SVG file to PNG') and the precise resource (an SVG file on disk). It also differentiates itself from render_view by stating that render_view handles build123d shapes from the live session while this tool accepts externally written SVG files.

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?

It explicitly names the replacement (draftwright), states the deprecation timeline, and says calling it explains the replacement. It also names the complementary sibling (render_view) and the exact condition for choosing between them: use this for an external SVG file, render_view for live session shapes.

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