Skip to main content
Glama
Sign In
eda-agent

eda-agent

by Nivakaran-S
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sch_place_power_port

Places a power port symbol (VCC, GND, etc.) on the active schematic at specified coordinates, with selectable symbol style and orientation for accurate net labeling.

Instructions

Place a power port symbol (VCC, GND, etc.) on the active schematic.

Args: text: Net name for the power port (e.g., "VCC", "GND", "+3V3") x: X coordinate in mils y: Y coordinate in mils style: Symbol style: "circle", circle symbol (default, typical for VCC) "arrow", arrow symbol "bar", bar/line symbol "wave", wave symbol "gnd_power", power ground symbol "gnd_signal", signal ground symbol "gnd_earth", earth ground symbol orientation: which way the glyph points from the connection point: 0=right, 1=up, 2=left, 3=down. Leave at -1 to let the bridge decide by style, which sends the ground glyphs down and everything else up.

    PASS IT EXPLICITLY FOR A RAIL DRAWN WITH style="bar".
    The style-based default groups "bar" and "wave" with the
    grounds, so a VCC bar comes out pointing DOWN and reads
    as a ground symbol. orientation=1 is what you want there.

Returns: Dictionary confirming placement

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
textYes
styleNocircle
orientationNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does reasonably well: it discloses coordinate units (mils), the sentinel default orientation=-1 and the bridge's style-based decision rule, plus a specific failure mode (a "bar" VCC rendering downward and reading as ground). It omits whether the port is placed on the current sheet, snapping behavior, and whether placement is reversible/undoable.

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?

Purpose is front-loaded in the first sentence, followed by an Args block that is easy to scan. The orientation entry runs long with its all-caps emphasis, but the extra words describe a real rendering trap rather than padding.

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?

For a 5-parameter placement tool with an output schema (so return values need no explanation), the description covers units, defaults, glyph styles, and a known pitfall. Remaining gaps are preconditions and side effects — no mention of requiring an open/active schematic document or of undo behavior.

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 coverage is 0%, so the description must carry all parameter meaning, and it does: text (net name), x/y (mils), style with all seven enumerated glyph values plus the default, and orientation with the full 0/1/2/3 direction mapping and the -1 sentinel. This adds substantial meaning that the bare integer/string properties do not convey.

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 a power port symbol") and scopes the target ("on the active schematic"), with examples (VCC, GND, etc.) that make the object type unambiguous. The term "power port" naturally distinguishes it from the sibling placement tools such as sch_place_port, sch_place_net_label, and sch_place_bus_entry without needing to name them.

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

Usage Guidelines3/5

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

Usage guidance is entirely parameter-level (when to override style/orientation) rather than tool-level; it never says when to choose this over sch_place_port or sch_place_net_label. The one strong piece of situational advice — pass orientation explicitly for a rail drawn with style="bar" — is genuinely useful but is about parameter choice, not tool selection.

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

Deploy Server

Other Tools