eda-agent

Overview Schema Source Related Servers Discussions Admin

lib_get_pin_list

Read a library component's pins by name, returning designators, electrical types, and coordinates, with large pin arrays written to JSON for datasheet verification.

Instructions

Get all pins of a library component.

NAME THE COMPONENT. Without component_name this reads whatever the SchLib editor currently has selected, so the answer depends on editor state a caller cannot see, and any tool that moves the selection between calls changes what this returns. Passing the name also avoids disturbing the selection, which is what made exporting one symbol affect the next call.

DATASHEET DISCIPLINE: Pin name + electrical_type from the symbol can be wrong, especially on libraries that have been edited by hand or imported from third-party sources. Before relying on a pin's function for any decision, fetch the manufacturer datasheet and verify against its pin-description table. The response carries _datasheet_guidance + _datasheet_parts.

BIG SYMBOLS SPILL TO A FILE ON PURPOSE. A 699-pin module returns more than a conversation can hold, and which half survives is then decided by whichever client happens to be reading. Above inline_limit pins the full array is written as JSON and the reply carries pins_path and a summary instead. That is the better artefact anyway: the file can be diffed against the datasheet's pin table by script, field by field, without any of it passing through the conversation.

Args: component_name: library reference of the symbol to read. Empty falls back to the editor's current component. output_path: write the full pin array here as JSON and return the summary. Forces the file path regardless of size. inline_limit: pin count above which the array is written to a file instead of returned inline. 0 always returns inline, which is what you want only for a small symbol.

Returns: Dictionary with "count", "component" name, and "pins" array. Each pin has: designator, name, electrical_type, x, y, orientation, hidden. Plus _datasheet_guidance + _datasheet_parts.

When spilled: "pins_path" plus "summary" giving pins per
part and the electrical-type distribution, and no "pins".

Input Schema

Name	Required	Description	Default
`output_path`	No
`inline_limit`	No
`component_name`	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.5/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 discloses the hidden dependency on editor selection state, the side effect that reading without a name disturbs selection, and the size-dependent spill-to-file behavior with its exact trigger and reply shape. These are non-obvious traits an agent could not get from the schema.

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 most actionable instruction ("NAME THE COMPONENT") and sectioned with caps headers, so it scans well. It is somewhat long and the spill behavior is explained three times (prose section, Args, Returns), with chatty editorializing ("That is the better artefact anyway") that costs space without adding selection-relevant information.

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 3-param read tool with no annotations, the description covers the selection-state hazard, the spill threshold mechanics, the datasheet caveat, and the field list of each pin — more than enough for correct invocation. An output schema exists, so the included return-value detail is bonus rather than a requirement.

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 compensate, and it documents all three parameters with meaning the schema lacks: the empty-string fallback for component_name and its selection-preservation benefit, output_path forcing a file regardless of size, and inline_limit=0 meaning always-inline. This is exactly the gap-filling the dimension rewards.

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?

Opens with a specific verb+resource: "Get all pins of a library component," which is unambiguous about what is returned (pin array for a symbol). It does not name or route against the nearest siblings (lib_get_component_details, obj_explain_pin, lib_add_pins), so an agent must infer the boundary itself.

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?

Gives clear conditional guidance: pass component_name to avoid depending on invisible editor selection, use output_path to force a file, and use inline_limit=0 "only for a small symbol." It also prescribes a downstream verification step (fetch the datasheet before trusting a pin's function). It stops short of explicit when-not-to-use-this-tool vs a sibling alternative.

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

Deploy Server