Skip to main content
Glama

apply_schematic_ops

Batch multiple LTspice schematic edits (add components, connect pins, set values, add directives, and more) into one atomic transaction that loads the file once and saves once, minimizing API round trips.

Instructions

Apply many .asc edits in one transaction. Loads the schematic once, runs each op against the in-memory editor in order, and saves once at the end. Cuts the typical 25+ tool calls to build a real circuit (add_component × N + connect × N + add_net_label × N + edit_directive × N) down to a single round-trip.

Supported ops (each tagged via the op field): add_component, set_component_value, set_component_attribute, remove_component, move_component, add_net_label, connect, add_directive.

By default, the first op that raises aborts the whole transaction and nothing is written to disk. Set stop_on_error=false to run every op and persist whatever subset succeeded — useful when each op is independent and partial progress is acceptable. Errors are recorded under each op's error field; successes carry the per-op result keys (e.g. wire_count).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to .asc schematic
opsYesList of edit operations applied in order against a single in-memory AscEditor. The file is saved once at the end iff every op succeeded (or stop_on_error=false). Each op is tagged by its ``op`` field; see the schema for per-op fields.
stop_on_errorNoWhen true (default), the first op that raises aborts the transaction and nothing is saved. When false, every op runs and per-op errors are recorded in ``results``; the file IS saved with whatever ops did succeed — set false only when failures are recoverable.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
applied_countYes
failed_countYes
savedYes
resultsYes
validation_warningsNo
Behavior4/5

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

Discloses transactional behavior: loads once, applies ops in memory, saves once. Explains error handling (abort on first error vs. continue) and that results include per-op errors. Annotations already indicate mutation, so description adds context without contradiction.

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?

Description is well-structured with an opening statement, a list of supported ops, and error handling details. Every sentence contributes useful information, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of batching many ops, the description covers the key behavioral aspects. Output schema likely handles return values, so the omission is acceptable. Could mention prerequisites like file existence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by summarizing the ops array structure and the stop_on_error behavior. It contextualizes the parameter semantics beyond the schema's per-op descriptions, such as explaining the transaction concept.

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?

The description clearly states the tool's purpose: 'Apply many .asc edits in one transaction.' It explicitly lists all supported ops and contrasts with the alternative of multiple individual calls, effectively distinguishing it from siblings like add_component and connect.

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?

Provides explicit when-to-use guidance: 'Cuts the typical 25+ tool calls to build a real circuit... down to a single round-trip.' Also explains the stop_on_error flag and when to use false for partial progress, offering clear decision criteria.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cognitohazard/ltspice-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server