Copper

Overview Schema Source Related Servers Discussions Admin

KiCad libraries

library

Idempotent

Search and inspect installed KiCad symbol and footprint tables to find valid lib_id/footprint IDs, read exact pin names, and repair missing or stale table entries before schematic placement.

Instructions

Search and inspect the KiCad symbol and footprint libraries this machine has (global + project tables): find a valid lib_id / footprint before sch_apply place, and read exact pin names. action: search_symbols (query = part number, name or keywords) | search_footprints (query; filters = footprint globs) | symbol_info (lib_id -> pins with number, name, type, unit; default footprint) | footprint_info (fp_id -> pads, courtyard, 3D model) | list (libraries in the active tables) | repair (fix "library not found": rebuilds missing or stale global tables; dry_run defaults to TRUE). Examples: library(action='search_symbols', query='USB C receptacle') · library(action='symbol_info', lib_id='Device:R')

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "library"
  }
}

Input Schema

Name	Required	Description
`lib`	No	Restrict a search to one library nickname.
`kind`	No	list: which tables (default sym).
`pins`	No	symbol_info: include pins (default true).
`fp_id`	No	Footprint 'Library:Name' for footprint_info.
`limit`	No	Max results (default 15).
`query`	No
`action`	Yes
`lib_id`	No	Symbol 'Library:Name' for symbol_info.
`dry_run`	No	repair: report only (default true).
`filters`	No	search_footprints: space-separated globs, e.g. a symbol's fp_filters.
`project`	No	project path (default: active)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Goes meaningfully beyond the annotations by disclosing that repair rebuilds missing or stale global tables and that dry_run defaults to TRUE — important for a mutating action under an otherwise read-oriented tool. However it does not describe result shape, truncation behavior with limit, or what happens when a lib_id lookup misses, which matters given 11 params and no output schema.

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?

Front-loads the capability and the motivating use case in the first sentence, then presents actions in a scannable pipe-delimited list with per-action parameter hints, followed by two concrete examples. There is no filler sentence; every element carries information.

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?

Covers all six actions and their typical inputs plus the repair safety default, which is substantial for an 11-parameter tool with no output schema. Gaps remain around project-path scoping, limit/truncation semantics for searches, and the shape of search results (names only vs. handle+description).

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?

Adds real meaning beyond the 82%-covered schema: query is specified as 'part number, name or keywords', filters as 'footprint globs, e.g. a symbol's fp_filters', and lib_id/fp_id map to concrete return content (pins with number/name/type/unit, pads, courtyard, 3D model). The worktree-scoping params (project, lib, limit) are left to the schema alone, which keeps it below a 5.

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+resource pair ('search and inspect the KiCad symbol and footprint libraries') and then enumerates every action with its own verb and object (search_symbols, symbol_info, footprint_info, list, repair). An agent can tell exactly what this tool does and how each action differs from the others without opening the schema.

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?

Explicitly names the workflow trigger: 'find a valid lib_id / footprint before sch_apply place', and gives a concrete error-recovery entry point ('repair (fix "library not found")'). It does not state when this tool should NOT be used (e.g., vs. parts_search for part sourcing), so it stops short of full alternative routing.

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