eda-agent

Overview Schema Source Related Servers Discussions Admin

sch_place_components

Bulk-place schematic components from libraries onto a chosen .SchDoc in one call, focusing the target sheet to prevent misplaced parts and returning placement counts.

Instructions

Place MANY schematic components from libraries in ONE call.

NOT THE WAY TO DRAW A SCHEMATIC, AND IT IS ENFORCED. Placing four or more components onto a sheet that has two or fewer is refused: that is a schematic being drawn by hand, and positions chosen that way read like nothing a person would draw however correct the netlist is. Build a DesignPlan and call design_execute_plan instead, which places AND routes the whole sheet through a layout engine measured against hand-drawn boards; design_layout_schematic and design_preview_plan show you the result first without touching the EDA. Use THIS tool to add parts to a sheet that already exists, or when the positions came from that engine. To place coordinates yourself anyway, pass allow_manual_layout=True.

This is the only path for library placement (there is no singular variant). Laying out a 50-part BOM is inherently a bulk operation; done one-by-one it would cost 50 LLM turns.

TARGET DOCUMENT: placement lands on the ACTIVE schematic. Right after app_create_document the new sheet is NOT auto-focused, so without document_path parts can silently land on a different open sheet. Pass document_path (absolute .SchDoc path) and this tool focuses that sheet first (app_set_active_document) before placing, always set it when you have just created the target sheet.

Args: allow_manual_layout: Set True to bypass the refusal described above and place your own coordinates onto an empty sheet. The default exists because this is almost never what the caller actually wants; say why in the surrounding turn. document_path: Absolute path of the .SchDoc to place onto. When given, it is focused before placement so parts can't land on the wrong sheet. When omitted, the current active document is used. placements: List of placement dicts, each with: - library_path (str, optional, empty uses an already-open library) - lib_reference (str, required), component name - x, y (int, mils), placement location - designator (str, optional), override designator - rotation (int, optional), 0 / 90 / 180 / 270 - footprint (str, optional), override current footprint

Example, place a 5-part BOM row: sch_place_components(placements=[ {"library_path": "C:\Lib\ST.SchLib", "lib_reference": "STM32F411RE", "x": 1000, "y": 2000, "designator": "U1"}, {"library_path": "C:\Lib\Res.SchLib", "lib_reference": "Res1", "x": 1500, "y": 2000, "designator": "R1"}, ... # 3 more ])

Returns: Dict with placed, failed, total counts.

Input Schema

Name	Required	Description	Default
`placements`	Yes
`document_path`	No
`allow_manual_layout`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and mostly does: it discloses the refusal policy, the silent-misplacement hazard on the ACTIVE document, the side effect that document_path triggers app_set_active_document, and that results can be partial (placed/failed/total). It does not state whether a batch is transactional or what happens when a library_path is invalid, which is the remaining behavioral gap for a bulk mutation.

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?

Long but appropriately structured: headline, hard constraint, alternative path, parent-document warning, then Args/Example/Returns. A few lines are redundant editorializing ("the default exists because this is almost never what the caller actually wants") and the JSON example contains unescaped Windows backslashes, but nothing material is wasted.

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 bulk mutation with zero annotation coverage, the description covers the safety policy, the document-targeting pitfall, parameter semantics, a usage example and the return shape. An agent has everything needed to call it correctly and to know when it will be refused.

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% and the nested placements array is an untyped object with additionalProperties, so the description is the only source of parameter meaning. It documents all three top-level params plus all six placement-dict fields (library_path, lib_reference, x/y in mils, designator, rotation with its four allowed values, footprint) and supplies a worked example.

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?

Front-loads a specific verb+resource+cardinality ("Place MANY schematic components from libraries in ONE call") and explicitly states it is the only library-placement path, with no singular variant. It also names the sibling it must not be confused with (design_execute_plan) so an agent can route without opening a schema.

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 an explicit when-not-to-use rule with the enforcement threshold (4+ components onto a sheet with 2 or fewer is refused), names the preferred alternatives (design_execute_plan, design_layout_schematic, design_preview_plan) and the escape hatch (allow_manual_layout=True). It also names the legitimate case: adding parts to an existing sheet or using engine-derived positions.

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

Deploy Server