Skip to main content
Glama

design_review_snapshot

Fetch a complete design-review snapshot in one call to review connectivity, part values, and rules instead of running multiple separate queries.

Instructions

Fetch a comprehensive design-review snapshot in ONE tool call.

THIS -- the compiled netlist + part data it returns -- is the BASIS of a design review, not a render. Judge connectivity, part values, ratings, and pin functions from these sections (and the cited datasheets), never from sch_render_svg / pcb_render_svg / design_visual_review, which are geometry-only and exist for when an image is genuinely needed (layout/placement). A picture can show a wire that shares no net, or hide a net that is electrically correct -- so the review reads the data here.

PREFER THIS over running 8-12 individual review queries. A normal review (components, nets, rules, diff, messages, stats, unrouted, BOM) is one round-trip instead of one LLM turn per section. That's the single biggest time cost on a full review.

CRITICAL, datasheet discipline (enforced via _review_guidance): Before drawing ANY conclusion about a component's pin function, voltage rating, or electrical spec, fetch the actual manufacturer datasheet and verify. The schematic symbol, footprint, and parameter fields are NOT ground truth - they are often wrong or outdated. Every proposed fix must cite the datasheet section or page you relied on.

The response's _unique_parts field is the checklist of components whose datasheets you must have read before reviewing. Do not skip this step.

CRITICAL, review-quality discipline (enforced via _review_guidance): A finding must ADD analysis the raw sections do not. Run ERC and DRC, but do NOT relay their raw output as findings - investigate each violation after the datasheet review, drop the false positives, and surface the real ones as specific, traced findings (a genuine ERC/DRC violation can be a top finding - never dropped). Do NOT emit "verify X" / "confirm X" as a finding - that hands the analysis back to the user. Every finding names the exact parts/pins/nets, is backed by a netlist fact or a cited datasheet, states a concrete consequence and fix, and is something you would raise in a real design review. The full rules are in _review_guidance["review_quality_rules"].

Args: sections: Which snapshot sections to include. Defaults to the standard review set (project_info, design_stats, components, nets, design_rules, unrouted, diff, messages, board_stats, fab_stats). Available extras: "bom", "drc", "erc", "unconnected_pins", "project_options". include_bom: Convenience - adds "bom" to sections if True (default). BOM is the best source of manufacturer part numbers for datasheet lookup. run_drc: If True, runs DRC (slow, 30-90 s) and includes results. Off by default - assume the user already ran it, or run it separately when asked. run_erc: If True, runs ERC and includes results. Off by default. force_recompile: SaveAll + invalidate SmartCompile cache + recompile before gathering any sections. Use this when the user has been editing schematics in the Altium UI and you need a guaranteed-fresh netlist. Costs one extra ~5-10 s compile up-front.

Returns: Dict with one key per requested section, plus: - _review_guidance: datasheet + review-quality rules Claude must follow when turning sections into findings - _unique_parts: list of {manufacturer, part_number, designators} to fetch datasheets for - _sections_failed: sections that errored (partial results are still usable)

Input Schema

NameRequiredDescriptionDefault
run_drcNo
run_ercNo
sectionsNo
include_bomNo
force_recompileNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses time costs (DRC 30-90 s, extra compile 5-10 s), defaults (run_drc/run_erc off because the user likely already ran them), partial-failure behavior via _sections_failed, and the enforced review discipline. This is strong behavioral context for a mutation-adjacent, slow tool.

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?

Core purpose and usage are front-loaded, but the two long 'CRITICAL' discipline blocks are verbose and partly restate content the description says is in _review_guidance. They earn their place behaviorally, but the definition could be tightened without losing invocation-relevant information.

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 complex snapshot tool with an output schema, the definition covers selection, defaults, costs, failure modes, and review expectations. Nothing an agent needs to call it correctly or interpret partial results 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 0%, so the description must compensate, and it does for all five parameters: it explains the default section set and available extras for sections, the convenience behavior of include_bom, the cost/default of run_drc and run_erc, and when force_recompile is warranted. This adds meaningful semantics the schema lacks.

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 ('Fetch a comprehensive design-review snapshot') and explicitly contrasts it with render/visual siblings and with running many individual queries. An agent can immediately tell what this returns and why it exists.

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 ('PREFER THIS over running 8-12 individual review queries') and when-not-to-use ('never from sch_render_svg / pcb_render_svg / design_visual_review, which are geometry-only'). It also names the conditions for the alternatives (image genuinely needed for layout/placement).

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