eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_render_svg

Render the active PCB to a per-layer SVG for visual placement, silkscreen, and spacing review or for sharing a board image; use board data for electrical checks.

Instructions

Render the active PcbDoc to an SVG file (in-house renderer).

SCOPE: a VISUAL artifact for when an image is genuinely needed (placement / silkscreen / spacing review, sharing a picture). It is NOT an input to a design review's electrical findings. NEVER judge connectivity, net assignment, or clearance from this render -- read those from the board data (pcb_get_nets, pcb_get_unrouted_nets, pcb_get_clearance_violations, pcb_run_drc, proj_compare_sch_pcb). The render shows geometry; the netlist shows connection.

Pulls the board outline, every track, arc, pad, via, and text primitive from the active PCB via the bridge, then emits a per-layer SVG. Layers are grouped in render order (KeepOut at bottom, then bottom copper, top copper, overlays, outline on top, drills last) and every track / arc / pad / via group carries data-net, data-layer, data-shape so a downstream dashboard or LLM tool can cross-probe or net- highlight without re-parsing.

v1 surface: board outline + tracks + arcs + pads (round / rect / octagonal / rounded-rect) + vias + texts on overlays. Regions (polygon fills / copper pours) and component-body silkscreen outlines are deferred to v1.1.

Args: output_path: Where to write the SVG. Defaults to the transient <workspace>/renders/ dir (kept out of the workspace root so renders don't pile up in your folder). layers: Restrict to these Altium layer names (e.g. ["TopLayer", "TopOverlay", "KeepOutLayer"]). When None (default) every known layer is rendered. MultiLayer (vias) and the outline are always drawn. margin_mils: Padding around the board bbox in mils. flip_y: When True (default) flip Y so the SVG reads in Altium's bottom-left-origin space. show_drills: Punch hole circles through pads / vias. show_texts: Render text primitives on overlay layers. show_designators: Draw component designators on the overlay. interactive_legend: Emit a clickable per-layer legend group in the SVG (for the dashboard / cross-probe consumers). background: Board-background fill (defaults to a slate review colour; pass "none" for transparent).

Returns: Dict with ok, svg_path, counts (per primitive kind), bbox (in mils), bytes.

Input Schema

Name	Required	Default
`flip_y`	No
`layers`	No
`background`	No	#1f2937
`show_texts`	No
`margin_mils`	No
`output_path`	No
`show_drills`	No
`show_designators`	No
`interactive_legend`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the in-house renderer, layer grouping and render order, per-primitive data attributes, v1 scope limitations, and the critical constraint that connectivity and clearance must not be judged from the render.

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 long but justified by the tool's complexity and nine parameters. It is front-loaded with purpose and scope, then structured into clear sections for behavior, limitations, args, and returns, with no filler.

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?

Although output schema exists, the description still clarifies return fields briefly and gives enough context for correct invocation. It covers scope, limitations, parameter effects, renderer behavior, and v1 omissions, leaving no significant ambiguity for the agent.

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 must compensate for all nine parameters. It does so thoroughly, explaining output_path defaults, layers filtering behavior, margin_mils units, flip_y semantics, drill/text/designator toggles, interactive legend purpose, and background color including transparent behavior.

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 and resource: 'Render the active PcbDoc to an SVG file.' It also immediately distinguishes the output as a visual artifact, making clear what the tool is and is not for.

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 defines when to use it: placement, silkscreen, spacing review, or sharing a picture. It also names when NOT to use it and points to concrete alternatives such as pcb_get_nets, pcb_get_unrouted_nets, pcb_get_clearance_violations, pcb_run_drc, and proj_compare_sch_pcb for electrical findings.

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

Deploy Server