eda-agent

Overview Schema Source Related Servers Discussions Admin

lib_create_standard_footprint

Creates a complete standard PCB footprint in one call from datasheet land-pattern dimensions, generating all pads, silkscreen outline, and courtyard for common package families.

Instructions

Create a COMPLETE standard footprint in ONE call.

Composes parametric geometry with the bulk authoring tools: makes the footprint, then emits every pad + the silkscreen outline + the courtyard rectangle in two batched round-trips. Supply the package's recommended land-pattern dimensions from the datasheet (this carries no part library -- the numbers you pass ARE the footprint).

Args: name: Footprint name (e.g. "SOIC-8_3.9x4.9"). family: "chip" (2-pin passive) | "sip" (single-row header) | "dual" (SOIC/SOP/SON/SOT/DIP) | "header" (2-row pin/box header, IDC, SWD/JTAG -- column-major odd/even numbering) | "tab" (power/tab package: SOT-223, DPAK/D2PAK, TO-220 -- signal pins one side + a large tab pad opposite, pass tab_w & tab_h) | "quad" (QFP/QFN) | "bga" (ball grid -- pass rows & cols). SOT-23 is "dual" with pin_count=3. Through-hole (DIP/header/TO-220) = any family with hole > 0. pin_count: total pads (2 for chip; even for header; n signal pins for tab; divisible by 4 for quad; ignored for bga). rows, cols: BGA ball grid dimensions (bga family only). exposed_pad: centre thermal/exposed pad size (mils) for QFN/QFP (quad family); 0 = none. Gets designator pin_count+1. tab_w, tab_h: tab pad size (mils) for the "tab" family; the tab gets designator pin_count+1 (tie it to a signal pin in the schematic). skip: BGA ball designators to omit (depopulation), e.g. ["A1","E5"] (bga family only). pitch: pad centre-to-centre within a row (mils). pad_w, pad_h: pad size (mils). TWO MEANINGS, kept for the callers that rely on them: pad_w is the pad's X size in every family but quad, so in dual (rows left and right) and chip it runs ACROSS the row, along the span, while in sip, header and tab it runs along the row; in quad each side turns the pad and pad_w runs ALONG the row. For a footprint from a package drawing use lib_create_footprint_from_package, which sizes the lands by IPC-7351B from the terminal's lead_length (along the span) and lead_width (across it). row_span: centre-to-centre between the two rows / opposite sides (mils). Required for dual and quad. shape: pad shape (default "roundrect"); corner_radius is its %. silk: draw a silkscreen body outline (TopOverlay). courtyard: clearance (mils) past the extent for the courtyard rectangle (Mechanical1); 0 disables it. body_w, body_h: package body for the silk outline; default to the pad extent. hole: drill size (mils). >0 makes through-hole pads (DIP / header / axial): pin 1 rectangular, the rest round.

Returns: Dict with the footprint name, pad/track counts, extent, and the per-step bridge results.

Input Schema

Name	Required	Default
`cols`	No
`hole`	No
`name`	Yes
`rows`	No
`silk`	No
`skip`	No
`pad_h`	No
`pad_w`	No
`pitch`	No
`shape`	No	roundrect
`tab_h`	No
`tab_w`	No
`body_h`	No
`body_w`	No
`family`	Yes
`row_span`	No
`courtyard`	No
`pin_count`	Yes
`description`	No
`exposed_pad`	No
`corner_radius`	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.3/5.0

Behavior4/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 well: it discloses that it makes the footprint then emits every pad, silkscreen outline, and courtyard in two batched round-trips, and that no part library is involved. It also explains family-dependent behavior such as through-hole creation and pad orientation. It does not mention whether an existing footprint with the same name is overwritten or what errors occur.

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?

The description is front-loaded with the core purpose and then uses a well-structured Args/Returns format. It is long but justified by the 21 parameters and the need to explain family-dependent semantics. A few sentences could be tightened, but no content is wasted.

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 21 parameters, no annotations, and an output schema, the description is complete enough: it explains the family system, through-hole creation, pad dimension nuances, and return shape. It omits error behavior and overwrite semantics, which would be useful for a creation tool. The output schema reduces the need to detail return values further.

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 description coverage is 0%, so the description must compensate—and it does extensively, explaining family-specific meanings for pad_w, row_span requirements, tab/exposed-pad designators, BGA skip lists, and hole behavior. The only parameter not covered is `description`, and default values are left to the schema. This adds substantial meaning beyond the raw schema.

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 states a specific verb and resource: "Create a COMPLETE standard footprint in ONE call." It immediately distinguishes the tool from the manual alternative by naming lib_create_footprint_from_package and explaining when to use that instead. An agent can easily tell this apart from sibling footprint-creation tools.

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?

It gives clear usage context: supply the datasheet's recommended land-pattern dimensions because "the numbers you pass ARE the footprint." It explicitly routes package-drawing-based creation to lib_create_footprint_from_package. However, it does not contrast with the sibling lib_create_footprint (manual footprint creation) or state any exclusion beyond the package-drawing case.

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

Deploy Server