eda-agent

Overview Schema Source Related Servers Discussions Admin

sch_place_vault_components

Place multiple managed Workspace components on a schematic sheet in one call using Design Item IDs and coordinates, keeping each part linked to its Workspace item.

Instructions

Place MANY managed (Workspace) components in ONE call.

sch_place_components for parts that live in an Altium Workspace rather than a library file. Such a part has no library path; it is placed by its Design Item ID and stays linked to its Workspace item. The hand-drawing rule of sch_place_components applies here too: four or more parts onto a sheet with two or fewer is refused unless allow_manual_layout=True.

A part number is not looked up here, so bring the Design Item ID. lib_get_vault_component checks one without placing it.

Args: placements: List of dicts, each with "design_item_id" (required), x and y in mils, and optionally designator and rotation (0, 90, 180 or 270). vault: The Workspace name, for the whole batch. Usually left out: it is read off managed parts already on an open sheet of the design, where Altium wrote it. When no open sheet has one, the call is refused and says what to do. Ask the user for the name rather than making one up. document_path: Absolute path of the .SchDoc to place onto. It is focused first; without it the active sheet is used, and a sheet just created is not active yet. lib_identifier_kind: The identifier kind to load by, 4 (VaultName) when left out. lib_get_vault_component reports the kind that loaded. allow_manual_layout: Place onto a near-empty sheet anyway.

Returns: placed, linked, failed, total, vault, lib_identifier_kind, loader_callable, note and one items entry per placement. linked counts the parts that read back a VaultGUID and ItemGUID, the link the file saves; a part placed but not linked is a plain copy of the symbol (reason PLACED_WITHOUT_LINK). NOT_FOUND_IN_VAULT means that ID did not load; LOAD_RAISED means this Altium cannot load managed parts at all.

Input Schema

Name	Required	Description	Default
`vault`	No
`placements`	Yes
`document_path`	No
`allow_manual_layout`	No
`lib_identifier_kind`	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.9/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 explains the manual-layout refusal rule, how `vault` is derived and what happens when it cannot be (call refused with guidance), that `document_path` is focused first and a just-created sheet is not active yet, and the difference between a linked placement and a plain symbol copy. Failure modes PLACED_WITHOUT_LINK, NOT_FOUND_IN_VAULT and LOAD_RAISED give the agent diagnostic semantics it could not infer.

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 the key distinction before any detail, and every section (Args, Returns) is scannable. The Returns paragraph is somewhat long and partly overlaps the output schema, though the error-code interpretation earns its place; a little could be trimmed.

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 5-parameter batch-mutation tool with 0% schema coverage, no annotations and an output schema, this covers everything an agent needs: what to supply, where it lands, the batch-size rule, vault resolution and fallback, and how to interpret partial failure. Nothing material 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 description coverage is 0%, so the description must compensate and does: it documents the required shape of each `placements` dict (design_item_id required; x/y in mils; optional designator and rotation restricted to 0/90/180/270), the default of `lib_identifier_kind` (4/VaultName) and what `lib_get_vault_component` reports, and the meaning and default of `allow_manual_layout`. That is meaningfully more than the bare type declarations in the schema.

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 ("Place MANY managed (Workspace) components in ONE call") and immediately scopes it against `sch_place_components` for library-file parts, plus notes these parts have no library path and are placed by Design Item ID. This is unambiguous against the nearest siblings.

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?

Explicit routing: use `sch_place_components` for parts that live in a library file, `lib_get_vault_component` to check an ID without placing it, and this tool for Workspace parts in bulk. It also names a hard precondition (four-plus parts onto a sheet with two or fewer is refused unless `allow_manual_layout=True`) and tells the agent to ask the user for a vault name rather than inventing one.

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

Deploy Server