Skip to main content
Glama

design_visual_review

Render the active schematic or PCB to a viewable image and return a layout critique rubric for a visual self-check loop on placement, spacing, and readability.

Instructions

Render the active design and return it as a viewable image plus a critique rubric -- the first step of a visual self-check loop.

SCOPE: layout and placement ONLY -- schematic readability / spread / flow, PCB part placement, silkscreen, spacing, overlaps. This is NOT a connectivity or part-correctness review. Do NOT use it to decide what connects to what, whether a value/rating is right, or whether a pin is wired -- those come from the netlist + part data (design_review_snapshot, proj_get_nets, proj_get_connectivity_many, proj_get_erc_violations), never from the image. The rubric below is deliberately about geometry; treat every electrical question as out of scope here.

Renderers are exports; this turns them into feedback. It draws the active SchDoc or PcbDoc, rasterizes it to PNG (headless Edge) so you can actually look at it with the Read tool, and returns a document-specific rubric (what to look for) and loop_protocol (render -> look -> critique -> cross-check -> fix -> re-render). Each rubric item names the existing audit tool(s) that measure it exactly, so vision finds candidates and the audits confirm and locate them.

Use it as a loop: call this, Read the returned png_path, critique against rubric, run the named audits for anything suspicious, fix with the normal tools (for PCB placement, pcb_plan_placement), then call this again to confirm. A couple of iterations is usually enough.

Args: target: "auto" (detect the active document), "schematic", or "pcb". output_path: Where to write the SVG (.png sits beside it). Defaults to the transient <workspace>/renders/ dir; the scratch .raster.svg used for the screenshot is deleted automatically (kept out of your folder). rasterize: Also produce a PNG so the image is directly viewable (default True). If no browser is found the SVG is still returned with a rasterize_note. width: Raster width in pixels (height follows the aspect). margin_mils: Override the render margin. layers: PCB only -- restrict to these layer names.

Returns: Dict with ok, target, doc, svg_path, png_path (None if rasterization was skipped/failed), counts, bbox, rubric, loop_protocol, next_step.

Input Schema

NameRequiredDescriptionDefault
widthNo
layersNo
targetNoauto
rasterizeNo
margin_milsNo
output_pathNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so well: it discloses that rasterization uses headless Edge, that the scratch .raster.svg is auto-deleted, that the SVG is still returned with a rasterize_note if no browser is found, and that defaults write to a transient <workspace>/renders/ dir. This is exactly the behavioral context an agent needs for a tool with zero annotation coverage.

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

Conciseness4/5

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

Front-loaded with purpose and scope, then a loop protocol, then Args and Returns in clean sections. It is longer than strictly necessary -- the multi-clause SCOPE and rubric-preamble sentences could be trimmed -- but almost every line adds callable guidance, so waste is low given the tool's complexity.

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 no annotations and 0% schema coverage, the description covers the full picture: what is rendered, how it rasterizes, what the rubric and loop_protocol contain, what fixes to use (pcb_plan_placement), and expected iteration count. An output schema exists, yet the Returns summary adds useful orientation without redundant field-by-field detail.

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% across 6 params, so the description must compensate, and it documents every one: target's three accepted values (auto/schematic/pcb), output_path semantics (.png beside SVG, transient default), rasterize default and fallback, width in pixels, margin_mils override, and layers (PCB only). No parameter is left to inference.

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+resource ('Renders the active design... returns it as a viewable image plus a critique rubric') and then tightly bounds the purpose with a SCOPE paragraph. It clearly distinguishes itself from siblings like design_review_snapshot, sch_render_svg, and pcb_render_svg by framing itself as the vision-feedback step, not a connectivity review.

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 (visual self-check loop), when-NOT-to-use ('NOT a connectivity or part-correctness review... Do NOT use it to decide what connects to what'), and names the correct alternatives (design_review_snapshot, proj_get_nets, proj_get_connectivity_many, proj_get_erc_violations). The loop protocol (render -> look -> critique -> cross-check -> fix -> re-render) removes all ambiguity about sequencing.

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