Skip to main content
Glama
ossenna-hq

ltspice-mcp

by ossenna-hq

connect

Connect two component pins in an LTspice schematic by specifying source and target pins, with optional waypoints to define wire routing paths.

Instructions

Connect two component pins with wire(s). Resolves pin positions automatically. Waypoints define the wire route through intermediate points. For a straight horizontal or vertical connection, waypoints can be omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to .asc schematic
to_pinYesTarget pin as 'Reference.Pin' (e.g., 'M4a.D', 'VDD.+') or 'net:name' for a net label
from_pinYesSource pin as 'Reference.Pin' (e.g., 'M1.D', 'VDD.+') or 'net:name' for a net label
waypointsNoIntermediate points for wire routing. For L-shaped routes, provide the corner point. For straight connections (same x or same y), omit.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
fromNo
pointsNo
warningsNo
wire_countNo
validation_warningsNo
Behavior2/5

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

Annotations indicate modifying nature (readOnlyHint=false), but description doesn't mention potential side effects such as overwriting existing connections or changing netlist. Lacks explicit warning about consequences.

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?

Two concise sentences, no redundant information. Every word serves a purpose.

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 output schema exists (not shown), the description adequately covers the function, parameters, and behavior. It explains the conditions for waypoints sufficiently.

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 descriptions are detailed with examples for pin references and waypoints. The description reinforces the meaning of waypoints and when they are needed, adding clarity beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action 'Connect two component pins with wire(s)' and notes automatic position resolution. It distinguishes from other tools by focusing on wiring, though no explicit comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides details on when to use waypoints and when they can be omitted, guiding the user on the proper invocation. No explicit alternative guidance, but sufficient context for a schematic editing tool.

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