Skip to main content
Glama
ossenna-hq

ltspice-mcp

by ossenna-hq

apply_schematic_ops

Destructive

Apply multiple LTspice schematic edits in one transaction: load once, run each operation, and save once. Reduces API round-trips for building or modifying circuits.

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. This is also the home for the ack-only schematic mutations that have no standalone tool — they return no geometry to act on, so they live here rather than each costing a separate tool slot.

Supported ops (each tagged via the op field): add_component, set_component_value, set_component_attribute, remove_component, move_component, add_net_label, remove_net_label, remove_wire, connect, add_directive, remove_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
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.
pathYesPath to .asc schematic
formatNoResponse format: 'json' for structured data, 'text' for human-readable
dry_runNoWhen true, validate the whole batch against an in-memory copy and report per-op results WITHOUT writing the file — nothing is saved and the on-disk schematic is untouched. Every op is attempted (errors don't stop the run) so a single bad op surfaces all problems at once instead of rolling back a good batch. Use it to check a plan, then resubmit the corrected ops with dry_run=false.
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
savedYes
dry_runNo
resultsYes
failed_countYes
applied_countYes
validation_warningsNo
Behavior5/5

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

Beyond the destructiveHint annotation, the description fully discloses transactional semantics: by default all-or-nothing, with stop_on_error=false for partial saves. It also warns about non-restorable side effects (cleanup_wires) and pattern matching for remove_directive, providing critical behavioral context for safe usage.

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

Conciseness5/5

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

The description is well-structured and front-loaded: it starts with the core purpose, then lists supported ops, then explains transaction and error handling. Although it's a bit long, every sentence carries necessary information for a complex tool, with no redundancy or fluff.

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?

Given the complexity of the input schema (union types with per-op fields), the description is complete. It covers batching, transactional behavior, dry_run usage, error handling, and points to the schema for per-op details. It leaves no major gaps for understanding how to correctly invoke the tool.

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?

The schema already provides 100% coverage with detailed per-field descriptions. The description adds value by explaining the overall batch behavior and how errors/results are structured (per-op error fields, wire_count), but it does not significantly extend individual parameter explanations beyond what's already in the schema. Slightly above baseline due to the batch-context clarification.

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: applying many .asc edits in one transaction. It explicitly lists the supported ops (add_component, connect, set_component_value, etc.) and distinguishes itself from the individual sibling tools by batching multiple edits into a single round-trip, making it unmistakable what the tool does.

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?

The description provides explicit guidance on when to use this tool: it 'cuts the typical 25+ tool calls... down to a single round-trip' for building circuits. It also explains the transaction behavior (stop_on_error, dry_run) and notes that some ops (ack-only mutations) have no standalone tool, giving clear when-to-use vs. alternatives context.

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/ossenna-hq/MCP_LTSpice'

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