Which integrations are available for this server?

Provides tools for analyzing KiCad schematics, including querying components, tracing nets, exploring connections, and analyzing multi-board systems through circuit analysis and signal path tracing.

How do I use KiCad MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KiCad MCP Server what components are connected to the 3.3V power rail on the main board?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

KiCad MCP Server

by bleugreen

Overview Schema Related Servers Score Discussions

Python

Local

KiCad MCP Server

Model Context Protocol (MCP) server for analyzing KiCad printed circuit boards. It provides a toolkit for PCB analysis, with multi-board schematic signal tracing and component datasheet lookup, exposed through a simple tool interface.

Single-board schematic text queries (component listings, per-net dumps, single-board connection tracing) have moved to the companion kicad-schema project, which renders a schematic as structured YAML. This server focuses on the analysis that is still hard to do in text form: signals that cross board boundaries, datasheet discovery, and the PCB layout surface that PCB-analysis tooling builds on.

Features

Multi-Board Analysis: Trace signals across multiple connected boards
Datasheet Lookup: Resolve a manufacturer and part number to a datasheet URL
Board & System Configuration: Register boards and systems; add or remove them without restarting
PCB Sources: Associate a .kicad_pcb layout with each board for PCB-analysis tooling
PCB Tools (kicad-cli): Headless design-rule checking, 3D board renders, and per-layer SVG export from .kicad_pcb layouts
Live KiCad Session: Connect to a running KiCad 9 PCB editor through the official IPC API for selection sync and reversible GUI cross-probing
Smart Caching: Optional file caching of parsed schematics for faster repeated queries

Related MCP server: kicad-mcp

Installation

# Install with uv (recommended)
uv sync

# Or with pip
pip install -e .

Requirements: Python 3.10+, and KiCad (for kicad-cli). The server discovers kicad-cli automatically at the macOS app-bundle path, /usr/bin, and on PATH; set the KICAD_CLI environment variable to point at a specific executable.

Quick Start

1. Configure MCP Client

Add to your MCP client configuration (e.g., Claude Desktop's claude_desktop_config.json):

{
  "mcpServers": {
    "kicad": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/kicad-mcp",
        "run",
        "kicad-mcp"
      ]
    }
  }
}

2. Create Configuration File

Create .kicad_mcp.yaml in your project directory:

boards:
  main:
    path: /path/to/main.kicad_sch
    pcb: /path/to/main.kicad_pcb        # optional: PCB layout for PCB-analysis tools
    description: Main controller board

  sensor:
    path: /path/to/sensor.kicad_sch
    description: Sensor board

systems:
  complete:
    boards: [main, sensor]
    description: Full system with all boards

cache:
  enabled: true
  directory: ~/.cache/kicad_mcp
  check_mtime: true

Configuration

Configuration files are searched in priority order:

Environment variable: $KICAD_MCP_CONFIG
Local project: .kicad_mcp.yaml (current directory or parent directories)
Global config: ~/.config/kicad_mcp/config.yaml
Default: Empty configuration (no boards pre-loaded)

Configuration Options

boards: Named board configurations. Each board has:
- path: path to the .kicad_sch schematic file
- pcb (optional): path to the .kicad_pcb layout file, used by PCB-analysis tools
- description (optional): human-readable description
systems: Multi-board system definitions referencing board names
cache.enabled: Enable/disable pickle caching of parsed schematics
cache.directory: Where to store cache files
cache.check_mtime: Invalidate cache when source files change

Available Tools

Board Management

Tool	Description
`list_configured_boards`	List all boards from configuration
`list_configured_systems`	List all multi-board systems
`load_board`	Load a board by name (with caching)
`load_system`	Load a multi-board system
`reload_config`	Reload configuration without restarting

Configuration Management

Tool	Description
`add_board`	Add a new board to configuration (schematic `path`, optional `pcb`)
`remove_board`	Remove a board from configuration
`add_system`	Add a new multi-board system
`remove_system`	Remove a system from configuration

Multi-Board Analysis

Tool	Description
`get_system_overview`	Overview of a multi-board system
`trace_cross_board_signal`	Trace a signal across multiple boards

Datasheets

Tool	Description
`search_datasheet`	Resolve a manufacturer and part number to a datasheet URL

PCB Layout (kicad-cli)

These tools operate on the .kicad_pcb layout via KiCad's headless kicad-cli. The source argument accepts a configured board name (using its pcb path), a direct path to a .kicad_pcb, or a path to a .kicad_sch (resolved to its sibling .kicad_pcb).

Tool	Description
`pcb_drc`	Run Design Rule Check; returns violations grouped by rule with severities, mm coordinates, totals, and the JSON report path. Fails closed — a failed run returns an explicit error, never a false clean pass. Accepts `severity` and `max_violations` filters.
`pcb_render`	Render the board in 3D to a PNG, returned as an inline image plus the saved file path. Camera controls: `side`, `zoom`, `rotate`, `pan`, `pivot`, `perspective`, `floor`, `width`, `height`, `quality`, `background`.
`pcb_export_layers`	Export one SVG per layer (e.g. `F.Cu,B.Cu,Edge.Cuts`) and return the file paths. `fit` defaults to `board` (board-area only) for downstream cropping.

The underlying wrappers live in kicad_mcp.kicad_cli and are importable as plain functions, so non-MCP consumers (such as a crop/highlight tool that needs board-area-fitted per-layer SVGs) can call them directly.

PCB Layout (parsed model)

These tools read a typed, in-memory model of the .kicad_pcb (placement, copper, stackup, pads, tracks, vias, zones) parsed with the pure-Python kiutils library and cached per (path, mtime) — no kicad-cli process. Their source resolves through KiCadMCPConfig.resolve_pcb_source (a configured board's pcb path, a direct .kicad_pcb path, or a .kicad_sch sibling). The queryable model lives in kicad_mcp.pcb_model; direct 2D PNG rendering lives in kicad_mcp.pcb_rendering.

Tool	Description
`pcb_overview`	Board dimensions, layer/stackup summary, footprint/track/via/zone counts, net count, and top nets by copper element count
`pcb_component`	A component's placement (position, side, rotation), footprint id, and pads with their nets
`pcb_components_near`	Footprints placed within a radius (mm) of a component, with distances
`pcb_net_route`	Routed copper length, layer usage, widths, vias, endpoints, and copper-island connectivity for one net
`pcb_diff_pair`	Length and via-count comparison for a differential pair, with pair-name inference for common `_P`/`_N` and `+`/`-` conventions
`pcb_net_lengths`	Sorted routed lengths for nets matching a glob or regular expression
`pcb_current_capacity`	Pattern-first current-capacity estimates for matched nets, sorted by weakest neck, using IPC-2221 trace current formulas
`pcb_impedance_estimate`	Pattern-first or hypothetical trace IPC-2141 impedance estimates, including coupled differential estimates when a matched pair is resolved
`pcb_crop`	Inline PNG crop of a component, a net's copper bounds, or an explicit board-coordinate window; returns MCP ImageContent plus the saved path
`pcb_highlight_net`	Inline PNG with one net drawn bright over dimmed board copper, including lower-alpha zones; returns MCP ImageContent plus the saved path

Electrical estimates — IPC-2221 ampacity and IPC-2141 impedance

pcb_current_capacity and pcb_impedance_estimate are estimate tools, not thermal simulation or a field solver. They use the same pattern-first behavior as pcb_net_lengths: a glob or regular expression matches nets and returns a table across all matches. When exactly one net matches, pcb_current_capacity appends per-segment detail for each (layer, width) geometry.

pcb_current_capacity estimates each routed track geometry from copper width, stackup copper thickness, layer type, and requested temperature rise using the IPC-2221 internal or external trace current formula as appropriate for the layer. Rows sort ascending by estimated current so the weakest necks are first; min_current_a turns the table into a pass/flag check. Via barrels are estimated with IPC-2221 using a stated plating assumption.

pcb_impedance_estimate reports IPC-2141 closed-form microstrip or stripline estimates for each matched (layer, width) geometry, or for a hypothetical width_mm plus layer when iterating toward a target width. If a pattern resolves to a differential pair by the existing _P/_N or +/- conventions, it derives the same-layer spacing from route geometry and appends a coupled differential estimate.

Both tools always print assumptions. Missing stackup copper thickness defaults to 0.035 mm (1 oz), via plating defaults to 25 µm, and missing dielectric constant defaults to εr 4.4 only when the height can still be derived or is provided explicitly. For two-layer boards without stackup, impedance uses board thickness minus two 35 µm copper foils; multilayer boards without dielectric thickness refuse the affected layer with an explicit message. Nets carried by zones are flagged because the pour cross-section is not modeled, so the track neck may not be the true current limit.

Live KiCad session (IPC API)

These tools talk to a running KiCad 9 PCB editor through KiCad's official kicad-python (kipy) IPC client. They are different from the file-based PCB model tools above: they operate on the user's visible KiCad GUI session and fail closed when no IPC server is reachable. To use them, enable KiCad's API server in KiCad Preferences → Plugins, then keep the target PCB open in the PCB editor. The server attempts KiCad's default IPC socket, or KICAD_API_SOCKET when that environment variable is set, and every IPC call uses a short timeout so the MCP server does not hang.

The KiCad 9 Python IPC surface exposes open-document discovery, board item queries, selection read/write, net queries, and item-by-net queries. It does not expose a typed zoom or pan command in kicad-python 0.7.1, so live focus selects the target footprint or item and reports that view centering is unavailable rather than fabricating a GUI state.

Tool	Description
`kicad_session`	Report whether KiCad IPC is reachable, the KiCad version, the attempted API socket, and open PCB document paths
`kicad_focus`	Select a footprint `reference` or a board `position` (`x_mm`, `y_mm`) in the running PCB editor; view centering is reported as unsupported when the IPC client cannot do it
`kicad_highlight_net`	Select all selectable copper items on a live board net so KiCad visibly highlights the routed net in the GUI
`kicad_get_selection`	Read the user's current GUI selection as references, nets, item types, and item summaries that compose with parsed-model tools such as `pcb_component` and `pcb_net_route`
`kicad_open_board`	Resolves a configured board or PCB path through `KiCadMCPConfig.resolve_pcb_source`, then fails closed because KiCad 9's Python IPC client does not expose an open-board command

Usage Examples

Multi-Board Systems

# Load and overview a system
load_system(system_name="complete")
get_system_overview(system_name="complete")

# Trace SPI signal across boards
trace_cross_board_signal(
    system_name="complete",
    signal_net="/MISO",
    start_component="main:U1",
    end_component="sensor:U2"
)

Datasheet Lookup

search_datasheet(
    manufacturer="Texas Instruments",
    part_number="ADS1299IPAGR"
)

Dynamic Configuration

# Add a new board, including its PCB layout
add_board(
    name="power",
    path="/path/to/power.kicad_sch",
    pcb="/path/to/power.kicad_pcb",
    description="Power supply board"
)

# Create a system with it
add_system(
    name="full_system",
    boards=["main", "sensor", "power"],
    description="Complete system with power"
)

# Reload after manual config edits
reload_config()

Development

# Install with dev dependencies
uv sync --extra dev

# Run tests
uv run pytest

# Lint
uv run ruff check src/

License

MIT

Available Tools

30 tools

add_boardB

Add a new board to the configuration

ParametersJSON Schema

Name	Required	Description
`pcb`	No	Path to the .kicad_pcb layout file (optional)
`name`	Yes	Board identifier (e.g., 'my_board')
`path`	Yes	Path to the .kicad_sch file
`description`	No	Board description (optional)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Add' without revealing if the action is persistent, requires authentication, or has side effects on existing boards.

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?

Single efficient sentence with no unnecessary words. Could slightly improve by adding optional parameters context without lengthening.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with 4 parameters and no output schema, the description lacks context on what happens after adding, persistence, and relationship to other tools like load_board.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, so baseline is 3. The description adds no extra meaning beyond the schema's property descriptions.

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 clearly states the action (add) and the resource (board) with context (to the configuration). It distinguishes from siblings like add_system and load_board.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like load_board or add_system. No prerequisites or context provided.

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

add_systemB

Add a new multi-board system to the configuration

ParametersJSON Schema

Name	Required	Description
`name`	Yes	System identifier (e.g., 'my_system')
`boards`	Yes	List of board names to include in the system
`description`	No	System description (optional)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden for behavioral disclosure. It only states that the tool adds a system, but does not disclose side effects like overwriting existing systems, validation behavior, or error conditions.

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?

The description is a single concise sentence that is front-loaded with the verb and resource. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters and no output schema. The description does not mention the return value, error behavior, or any contextual information beyond the basic action. This is insufficient for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for each parameter. The tool description adds no additional meaning beyond the schema, so it meets the baseline of 3.

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 clearly states the tool's purpose: adding a new multi-board system to the configuration. It distinguishes from sibling 'add_board' which adds a single board, and 'remove_system' which removes one.

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

Usage Guidelines2/5

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

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites such as whether boards must exist or system names must be unique.

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

get_system_overviewC

Get an overview of a multi-board system

ParametersJSON Schema

Name	Required	Description	Default
`system_name`	Yes	System name from config

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations, the description must convey behavior. It implies a read operation but does not disclose side effects, permissions, or return format. The term 'overview' is ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (5 words), which is concise but lacks structure and depth. It is not overly verbose, but could be more informative without being wordy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and many sibling tools exist. The description does not specify what the overview contains, making it insufficient for an agent to understand the tool's full utility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%—the parameter 'system_name' has a clear description ('System name from config'). The tool description adds no additional parameter meaning beyond the schema.

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

Purpose3/5

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

The description indicates a verb ('Get') and a resource ('overview of a multi-board system'), but it's vague about what the overview includes. It does not differentiate from siblings like 'list_configured_systems' or 'pcb_overview'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. No exclusions, context, or prerequisites are mentioned.

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

kicad_focusB

Select a footprint reference or board position in the running KiCad PCB editor. View zoom/pan is reported when unsupported by the IPC client.

ParametersJSON Schema

Name	Required	Description	Default
`position`	No	Board position in millimetres
`reference`	No	Footprint reference designator, e.g. U3

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. It mentions reporting zoom/pan when unsupported by IPC client, but lacks details about destructive actions, prerequisites (e.g., board must be loaded), or side effects on the view.

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 sentences with no wasted words. The first sentence states the main purpose, the second adds a behavioral note. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is somewhat incomplete. It explains what the tool does but does not specify return values, prerequisites, or behavior beyond selection and zoom/pan reporting. Adequate for a simple tool but could be more detailed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions (position and reference). The tool description adds no extra semantic value beyond what is already in the schema, so baseline score of 3 applies.

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?

Description clearly states the tool selects a footprint reference or board position in KiCad PCB editor, with a specific verb and resource. It distinguishes from sibling tools like kicad_get_selection (which gets current selection) by indicating it performs a selection action.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as kicad_get_selection or kicad_highlight_net. The only usage hint is about zoom/pan reporting, which is more behavioral than usage context.

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

kicad_get_selectionA

Read the user's current live KiCad PCB selection as references, nets, item types, and item summaries.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

Description implies read-only behavior ('Read') but no annotations provided to confirm. Doesn't disclose permissions, failure modes, or if operation is real-time. Adequate but minimal for a read operation.

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?

Single sentence of 16 words, front-loaded with core action and resource. No fluff, every word adds value.

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 no output schema or parameters, description covers purpose and output summary. Lacks details on return format or error conditions, but sufficient for a simple read tool.

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?

No parameters, so schema coverage is 100%. Description adds no parameter info, but baseline for 0 params is 4.

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?

Description uses specific verb 'Read' and specifies resource 'current live KiCad PCB selection' and return values. Clearly distinguishes from siblings like add_board, load_board, etc. which modify or load boards.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives like pcb_component or pcb_components_near. Does not mention prerequisites (e.g., must have an open board) or when not to use.

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

kicad_highlight_netA

Select all selectable copper items on a net in the running KiCad PCB editor so the GUI highlights them live.

ParametersJSON Schema

Name	Required	Description	Default
`net`	Yes	Net name

TDQS

A3.5/5.0

Behavior3/5

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

Discloses the main effect (select and highlight), but without annotations, it lacks details on side effects (e.g., changing current selection), requirements (KiCad must be running), or failure modes (invalid net name).

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?

Single concise sentence with no extra words. The action and context are front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description provides the core functionality. However, it omits contextual details like prerequisite state (KiCad open, board loaded) and error handling, leaving gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the single 'net' parameter fully (type and description). The description adds no additional meaning beyond 'Net name', so it meets the baseline but does not enhance understanding.

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 clearly states the action (select and highlight a net), the resource (copper items in KiCad), and the live result. It distinguishes from sibling 'pcb_highlight_net' by specifying 'in the running KiCad PCB editor'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like pcb_highlight_net, or prerequisites such as KiCad being open. The description does not indicate when not to use it.

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

kicad_open_boardB

Resolve a PCB source and fail closed if the installed KiCad IPC client cannot open documents.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Configured board name or .kicad_pcb/.kicad_sch path

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses fail-closed behavior, but does not explain what happens on success (e.g., whether the board becomes active in the session), side effects, or whether it returns a result. Partial transparency.

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?

Single sentence, no wasted words. The description is front-loaded with the core action and includes the key behavioral constraint (fail closed). Appropriate length given the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description covers the input and error mode but lacks information about the return value, state changes, or relationship to sibling tools like load_board. Reasonably complete but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for the single parameter 'source'. The description adds clarity by specifying 'Configured board name or .kicad_pcb/.kicad_sch path', which aligns with the schema. No additional semantic value beyond schema, so baseline 3 applies.

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?

The description states the tool resolves a PCB source and fails closed if the KiCad client cannot open documents. It identifies the specific action (resolving a source) and resource (PCB source), and the fail-closed behavior distinguishes it from sibling tools like load_board which may have different error handling.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like load_board or kicad_session. The description does not mention prerequisites, context, or when not to use it. The implicit usage is for opening a board/schematic file, but the agent receives no decision support.

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

kicad_sessionA

Report live KiCad IPC reachability, version, attempted socket, and open PCB documents.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only lists what is reported but does not state whether the tool is read-only, requires authentication, or has any side effects. The agent is left guessing about safety and operational impact.

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?

The description is a single sentence, concise and front-loaded. Every word contributes meaning without redundancy. It is efficiently structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description lists the reported items but lacks details on the format or structure of the report. While it covers the core purpose, an agent might benefit from knowing if the output is a JSON object or has specific fields. The description is adequate but not fully complete.

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?

The tool has zero parameters, so the baseline score is 4. The description correctly avoids adding param information since none exist. No additional meaning is needed beyond the 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 uses a specific verb 'Report' and explicitly lists the resources: 'live KiCad IPC reachability, version, attempted socket, and open PCB documents'. This clearly distinguishes it from sibling tools like kicad_focus or kicad_get_selection which have different purposes.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It merely states what the tool does, leaving the agent to infer usage context.

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

list_configured_boardsA

List all boards configured in .kicad_mcp.yaml

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, and the description only states a read-like action without disclosing potential side effects, error conditions, or return behavior.

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?

A single sentence with 8 words, efficiently conveying the tool's purpose with zero redundancy.

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 tool has no parameters and no output schema, the description adequately covers what the tool does and its data source, though it could mention return format.

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?

There are no parameters, and schema coverage is 100%. The description adds value by specifying the source file, exceeding the baseline expectation.

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 clearly states the verb 'list' and the resource 'boards configured in .kicad_mcp.yaml', distinguishing it from siblings like add_board or remove_board.

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?

No explicit guidance on when to use this tool versus alternatives like get_system_overview or kicad_session; usage is implied but not clarified.

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

list_configured_systemsA

List all multi-board systems configured in .kicad_mcp.yaml

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. It specifies it lists from a YAML file, which implies a read-only operation, but does not mention error handling (e.g., missing file) or return format.

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?

Extremely concise: one sentence front-loading the core purpose. No wasted words.

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 simple list tool with no parameters and no output schema, the description is mostly sufficient. Could mention what information is returned (e.g., names), but not critical.

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?

No parameters exist (schema coverage 100%), so the description adds no additional parameter info. Baseline 4 for zero parameters is appropriate.

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 clearly states the action (list) and the specific resource (multi-board systems configured in .kicad_mcp.yaml), distinguishing it from sibling tools like add_system or get_system_overview.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., get_system_overview for details). The description only states what it does, not context or prerequisites.

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

load_boardB

Load a board by name from configuration

ParametersJSON Schema

Name	Required	Description	Default
`board_name`	Yes	Board name from config (e.g., 'main', 'sense')

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose whether loading a board modifies state, requires specific permissions, or what the side effects are. Minimal behavioral information.

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?

Single sentence is concise and front-loaded with the key action. No wasted words, but lacks structure (e.g., no bullet points or separate sections).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has only one parameter and no output schema. Description provides basic functionality but does not explain the effect of loading (e.g., sets active board, reads into memory). Adequate for a simple tool but could be more informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description repeats the parameter name without adding extra meaning. Baseline score of 3 is appropriate since the schema already documents the parameter.

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?

Description uses specific verb 'load' and resource 'board', and adds context 'from configuration', which distinguishes it from siblings like 'kicad_open_board' and 'add_board'. Clearly states the tool's function.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'kicad_open_board' or 'list_configured_boards'. Does not mention prerequisites or context.

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

load_systemB

Load a multi-board system by name from configuration

ParametersJSON Schema

Name	Required	Description	Default
`system_name`	Yes	System name from config (e.g., 'full', 'main-sense')

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the action without disclosing side effects, return value, or failure behavior. For a load operation, it is unclear if it sets the system as active or returns data.

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?

Single sentence with no waste, but it is too brief and omits important behavioral context. Conciseness is good but at the expense of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, no output schema), the description is minimal and fails to explain the effect on the session, error handling, or what constitutes a successful load. It leaves significant information gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline 3 is correct. The tool description does not add further semantics beyond what the schema already provides for the 'system_name' parameter.

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?

Description clearly states 'Load a multi-board system by name from configuration', using a specific verb and resource. It distinguishes from sibling tools like 'load_board' (which loads a single board) and 'add_system' (which creates a new system).

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?

Implies usage for loading an existing system but does not explicitly state when to use versus alternatives like 'get_system_overview' or prerequisites such as the system must already be configured. No exclusions or when-not-to-use guidance.

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

pcb_componentA

Get a component's PCB placement (position, side, rotation), footprint id, and pads with their nets.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Board name from config OR path to a .kicad_pcb file
`reference`	Yes	Component reference designator (e.g., 'R1', 'U3')

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, description carries full burden. It accurately describes the tool as read-only (get), which is consistent with its name. However, it does not mention error cases (e.g., component not found), authentication needs, or rate limits. Adequate but lacks detail.

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?

Single sentence, no filler, front-loads the key information: action (get), resource (component's PCB data), and specifics (placement, footprint, pads).

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 no output schema, the description competently outlines the return data (placement, footprint, pads). It is sufficient for a simple retrieval tool and fits within the sibling context. Could mention that the result is per component.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover both parameters fully (100% coverage). The tool description lists the returned data but adds no further parameter-level detail beyond the schema. Baseline 3 is appropriate.

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?

Description clearly states the tool gets PCB placement, footprint id, and pads with nets, using the verb 'Get' and specifying the resource as component's PCB data. It distinguishes itself from siblings like pcb_components_near (which finds components near a point) and pcb_overview (board-level overview).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For instance, when one should use this over pcb_components_near or pcb_overview is not clarified. No mention of prerequisites or best practices.

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

pcb_components_nearB

Find footprints placed within a radius (mm) of a given component, with distances.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Board name from config OR path to a .kicad_pcb file
`radius_mm`	No	Search radius in millimetres
`reference`	Yes	Component reference designator to search around

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It does not mention permissions, rate limits, what happens if no components are found, or how distances are returned (e.g., sorted list). Insufficient for a spatial search tool.

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?

Single sentence with no filler. It efficiently conveys the core function, though could be slightly expanded without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and minimal description. Does not explain return format (e.g., list of components with distances), edge cases like overlapping footprints, or unit for radius. Incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all three parameters have descriptions). The tool description adds no additional meaning beyond schema; baseline of 3 is appropriate.

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?

Description uses specific verb 'Find' and resource 'footprints placed within a radius of a given component'. It clearly distinguishes from related tools like pcb_component (which likely fetches single component info) by focusing on spatial proximity search.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., pcb_net_route for routing, pcb_component for individual component data). The description only states the function without context or exclusion criteria.

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

pcb_cropA

Render a 2D PNG crop of a PCB region as ImageContent. Select exactly one target: reference plus margin_mm, net plus margin_mm, or explicit x_mm/y_mm/width_mm/height_mm. Layers default to the target side copper plus silkscreen and Edge.Cuts for reference crops, or all copper plus Edge.Cuts otherwise.

ParametersJSON Schema

Name	Required	Description
`net`	No	Net name or number to crop around
`x_mm`	No	Explicit crop origin X in board millimetres
`y_mm`	No	Explicit crop origin Y in board millimetres
`layers`	No	Layer names, e.g. ['F.Cu','Edge.Cuts']
`source`	Yes	Board name, .kicad_pcb path, or sibling .kicad_sch
`width_mm`	No	Explicit crop width in millimetres
`width_px`	No	Long-edge pixel target capped at 1600
`height_mm`	No	Explicit crop height in millimetres
`margin_mm`	No	Margin around reference/net crop
`reference`	No	Component reference designator to crop around
`output_dir`	No	PNG output directory; defaults to a temp dir

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden. It explains default layers based on the targeting mode and that output is ImageContent. However, it does not mention error handling, performance, or the exact nature of ImageContent (e.g., base64 encoding). The schema covers the pixel size cap.

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?

The description is a single paragraph of three sentences, efficiently front-loading the main action and then listing the targeting options. Every sentence serves a purpose with no wasted words.

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 an 11-parameter tool with 100% schema coverage, the description provides necessary context on targeting modes and default layers. It lacks clarification on whether the output is always saved to disk or returned as content, but the schema hints at output_dir. Overall fairly complete.

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 coverage is 100%, so baseline is 3. The description adds value by explaining the grouping of parameters into three targeting methods and how layers default differently per method. This clarifies parameter interdependencies beyond the 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 clearly states the tool renders a 2D PNG crop of a PCB region and specifies three distinct targeting methods (reference, net, explicit coordinates). The purpose is specific and distinguishable from sibling tools like pcb_render, which likely renders the full board.

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?

The description explicitly says 'Select exactly one target' and explains the three targeting options with their respective parameters. While it does not mention exclusions or alternatives, the context is clear enough for an AI agent to choose the correct mode.

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

pcb_current_capacityA

Estimate current capacity for nets matching a glob or regex, sorted weakest first, using IPC-2221 trace current formulas.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of matching nets to report
`source`	Yes	Board name from config OR path to a .kicad_pcb file
`pattern`	Yes	Glob or regular expression matching net names
`plating_um`	No	Assumed via barrel plating thickness in µm
`temp_rise_c`	No	Allowed copper temperature rise in °C
`min_current_a`	No	Optional pass/flag threshold in amps

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description alone must convey behavior. It transparently discloses the method (IPC-2221), sorting order, and pattern matching. It does not mention potential side effects, but as a read-only estimation tool, this is acceptable.

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?

The description is a single sentence with no wasted words, front-loading the core purpose and key details like sorting and standard used.

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?

While there is no output schema, the description covers the main behavior and sorting. It lacks details on the return format (e.g., units, fields), but overall it is sufficiently complete for a simple estimation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds context about IPC-2221 and sorting order but does not provide additional meaning for individual parameters beyond what the schema already offers.

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 clearly states the tool estimates current capacity for nets using IPC-2221 formulas, with a glob/regex pattern and sorted weakest first. It distinctly sets the tool apart from siblings like pcb_net_lengths or pcb_impedance_estimate.

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?

The description implies the usage context (estimating current capacity for PCB nets) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.

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

pcb_diff_pairA

Compare routed lengths for a differential pair. Pass explicit net_p/net_n or pass net_p as the base name using _P/_N or +/- conventions.

ParametersJSON Schema

Name	Required	Description
`net_n`	No	Negative net name (optional when net_p is a base name)
`net_p`	Yes	Positive net name, or pair base name when net_n is omitted
`source`	Yes	Board name from config OR path to a .kicad_pcb file

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description carries the burden. It does not disclose output format or side effects. The agent cannot infer what the comparison returns (e.g., lengths, difference).

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 sentences, front-loaded with purpose, efficient and no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for specifying nets but omits output details. Without output schema or additional behavioral info, the description leaves the agent guessing about the return value.

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?

The description adds value beyond the schema by explaining the net naming conventions (_P/_N, +/-), which helps correct parameter construction.

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 clearly states the tool compares routed lengths for a differential pair. The addition of net naming conventions distinguishes it from tools like pcb_net_lengths.

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 is implied by the differential pair context, but no explicit when-to-use or alternatives are mentioned, leaving room for ambiguity with similar tools.

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

pcb_drcA

Run headless Design Rule Check on a PCB and return violations grouped by rule with severities, mm coordinates, totals, and the JSON report path. Fails closed (explicit error) if the run fails rather than reporting a false clean pass.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Board name from config OR path to .kicad_pcb (or sibling .kicad_sch)
`severity`	No	Filter: all, error, warning, or exclusion	all
`max_violations`	No	Cap the number of individual violations listed (totals stay exact)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses headless operation, the return structure, and importantly the error behavior ('Fails closed'), which adds critical transparency about failure modes.

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 sentences efficiently cover purpose, output, and error handling with zero waste. Every word earns its place.

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?

While the description covers the core action and return format well, it does not mention prerequisites (e.g., that the board must be loaded or configured) or clarify what 'headless' implies. Given the tool's moderate complexity, a bit more context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions, so baseline is 3. The description does not add extra meaning beyond the schema for parameters; it focuses on output instead.

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 specifies the action ('Run headless Design Rule Check'), the resource ('PCB'), and details the output format (violations grouped by rule with severities, mm coordinates, totals, and JSON report path), clearly distinguishing it from sibling tools like pcb_overview or pcb_net_lengths.

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?

The description implies this tool is for running DRC when you need violation data, but it does not explicitly state when to use it versus alternatives like pcb_render for visuals or pcb_net_lengths for specific checks. Still, the context is clear enough for an agent to infer usage.

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

pcb_export_layersB

Export one SVG per PCB layer (e.g. F.Cu,B.Cu,Edge.Cuts) and return the generated file paths. Defaults to board-area fit for downstream cropping.

ParametersJSON Schema

Name	Required	Description	Default
`fit`	No	Page sizing: board (board area only), page (framed page), or current	board
`layers`	Yes	Untranslated layer names, e.g. ['F.Cu','B.Cu','Edge.Cuts']
`source`	Yes	Board name from config OR path to .kicad_pcb (or sibling .kicad_sch)
`output_dir`	No	Directory to write SVGs into (default: a per-run temp dir)
`black_and_white`	No	Plot black and white only

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description must convey all behavioral traits. It only states the basic operation (export SVGs, return paths) and default fit. It does not disclose error handling, prerequisites, side effects (e.g., file creation/deletion), or performance considerations, leaving significant gaps for an agent.

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 concise (one sentence) and front-loaded with the key action and return. It efficiently communicates the core functionality, but lacks structural elements like bullet points or sections that could improve readability for complex parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should comprehensively cover return values and behavioral details. It states file paths are returned but does not specify format, persistence, or what happens with the temp directory. Given the tool's moderate complexity (5 params), the description is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters are fully described in the schema (100% coverage), so the description adds minimal value beyond the schema. It does clarify the default for 'fit' and the cropping context, which is useful but not extensive. Baseline of 3 is appropriate.

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 clearly states the tool exports one SVG per PCB layer and returns file paths. It provides an example of layers (F.Cu, B.Cu, Edge.Cuts) and notes the default board-area fit, making the specific verb+resource purpose distinct from sibling tools like pcb_render or pcb_crop.

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?

The description mentions a default fit option for downstream cropping, implying a common use case, but does not give explicit guidance on when to use this tool versus alternatives like pcb_render or pcb_crop. No when-not or exclusion criteria are provided.

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

pcb_highlight_netB

Render a 2D PNG with one net's tracks, vias, pads, and zones drawn bright over a dimmed board. Defaults to the whole board and all copper layers.

ParametersJSON Schema

Name	Required	Description
`net`	Yes	Net name or number to highlight
`x_mm`	No	Optional bbox origin X in board millimetres
`y_mm`	No	Optional bbox origin Y in board millimetres
`layers`	No	Layer names, e.g. ['F.Cu','B.Cu','Edge.Cuts']
`source`	Yes	Board name, .kicad_pcb path, or sibling .kicad_sch
`width_mm`	No	Optional bbox width in millimetres
`width_px`	No	Long-edge pixel target capped at 1600
`height_mm`	No	Optional bbox height in millimetres
`output_dir`	No	PNG output directory; defaults to a temp dir

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses the output type (2D PNG) and the rendering behavior (highlighted net over dimmed board). However, it omits side effects like file writing, potential large output, or required preconditions (e.g., board must be loaded). Since no annotations exist, the description carries the full burden but falls short on comprehensive disclosure.

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?

The description is concise with two sentences, front-loading the core functionality and then stating defaults. Every word is purposeful, with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the clear rendering purpose, the description fails to mention prerequisites (e.g., loading a board via 'load_board') and the tool's return value or output format. With no output schema, this lack leaves the agent uncertain how to handle the result. The sibling list includes essential setup tools, but the description itself does not guide the agent on sequencing.

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 cover 100% of parameters. The tool description adds value by explaining defaults ('Defaults to the whole board and all copper layers') and the conceptual effect (bright over dimmed), which aids understanding beyond the schema's individual parameter descriptions.

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?

The description clearly states that the tool renders a 2D PNG highlighting one net's tracks, vias, pads, and zones over a dimmed board. It specifies the visual result and default scope, but does not explicitly distinguish from similar sibling tools like 'kicad_highlight_net' or 'pcb_render'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'kicad_highlight_net' (GUI context) or 'pcb_render' (whole board). The description lacks prerequisites or conditions, leaving the agent to infer usage context.

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

pcb_impedance_estimateA

Estimate single-ended and differential impedance with IPC-2141 closed-form formulas for matching nets, or a hypothetical width/layer.

ParametersJSON Schema

Name	Required	Description
`er`	No	Override dielectric constant
`layer`	No	Hypothetical trace layer, e.g. F.Cu
`limit`	No	Maximum number of matching nets to report
`source`	Yes	Board name from config OR path to a .kicad_pcb file
`pattern`	No	Glob or regular expression matching net names
`width_mm`	No	Hypothetical trace width in millimetres
`dielectric_h_mm`	No	Override dielectric height to reference plane in millimetres

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the use of closed-form formulas (approximate) and the two modes (matching nets vs hypothetical). It does not explicitly state it's read-only, but 'estimate' implies no side effects. Lacks details on required input state (board loaded).

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?

The description is a single concise sentence that front-loads the core purpose and method. No redundant or extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of PCB impedance estimation and no output schema, the description covers the main functionality but leaves out details like return format, requirement for board state, and assumption of existing stackup data. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter is described in the schema. The description adds context about the two modes (matching nets vs hypothetical) but does not explain individual parameters beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states the tool's purpose: estimating single-ended and differential impedance using IPC-2141 formulas, for both existing nets and hypothetical traces. It distinguishes from sibling tools like pcb_current_capacity by focusing on impedance estimation.

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?

The description implies usage for impedance estimation but lacks explicit guidance on when not to use it or alternatives. Since there are no sibling tools for impedance, the need for exclusions is lower, but it could mention prerequisites (e.g., board file loaded) or limitations.

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

pcb_net_lengthsA

List routed lengths for nets whose names match a glob or regular expression, sorted by length for bus matching review.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of matching nets to report
`source`	Yes	Board name from config OR path to a .kicad_pcb file
`pattern`	Yes	Glob or regular expression, e.g. DDR_*

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so the description must convey behavior. It states the tool lists routed lengths and sorts them, which implies a read-only operation. However, it does not disclose potential side effects, performance implications, or that it is non-destructive. A score of 3 reflects adequate but incomplete disclosure.

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?

The description is a single sentence that fully conveys the tool's purpose and context without unnecessary words. It is efficiently front-loaded and earns its place.

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 absence of an output schema, the description could hint more about the return format (e.g., net name and length). However, it adequately covers the tool's functionality for most agents, and the schema provides parameter details. Slightly incomplete but sufficient.

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?

All 3 parameters have descriptions in the schema (100% coverage), providing basic meaning. The description adds context beyond the schema by noting that patterns match net names and results are sorted by length for bus matching. This added value justifies a score above baseline 3.

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?

Description clearly states it lists routed lengths for nets matching a glob/regex, sorted by length for bus matching review. The verb 'list' and resource 'routed lengths of nets' are specific. This distinguishes it from siblings like pcb_net_route or pcb_highlight_net, which serve different purposes.

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?

The description mentions a use case ('for bus matching review') but does not explicitly exclude other scenarios or compare to alternatives. While the context implies when to use it, there is no 'when not to use' guidance.

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

pcb_net_routeA

Analyze one PCB net's routed copper length, layer usage, widths, vias, endpoints, and copper-island connectivity.

ParametersJSON Schema

Name	Required	Description	Default
`net`	Yes	Net name or net number
`source`	Yes	Board name from config OR path to a .kicad_pcb file

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It lists analyzed aspects (length, layers, widths, vias, endpoints, connectivity) which implies read-only behavior and no side effects. However, it does not disclose error handling (e.g., if net doesn't exist) or any limitations. Adequate but not comprehensive.

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?

Single sentence of 18 words, front-loaded with action and resource, no redundancy. Every part adds value—concise and well-structured.

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 no output schema, the description explains what the tool analyzes (length, layers, etc.), providing sufficient context for a net analysis tool. However, it could mention that it returns a report or modifies nothing. Sibling comparison suggests it's detailed enough for its role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for 'net' and 'source'. The tool description does not add extra meaning beyond these schema descriptions; it merely implies 'net' is the net to analyze. Baseline 3 applies.

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 clearly states the tool analyzes one PCB net's routed copper length, layer usage, widths, vias, endpoints, and connectivity. This distinguishes it from siblings like pcb_net_lengths (only length) and pcb_overview (board-level). The specific verb 'Analyze' and resource 'one PCB net' provide precise purpose.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like pcb_net_lengths or pcb_highlight_net. The description does not specify prerequisites (e.g., board must be loaded) or scenarios (e.g., for detailed routing inspection). The agent is left to infer usage context.

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

pcb_overviewB

Get a PCB layout overview: board dimensions, layer/stackup summary, footprint/track/via/zone counts, net count, and top nets by copper element count.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Board name from config OR path to a .kicad_pcb file

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as whether the tool is read-only, requires a loaded board, or has any side effects. For a tool with no annotations, this is insufficient.

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?

A single, well-structured sentence that efficiently conveys the tool's output. No wasted words.

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 simple overview tool with one parameter and no output schema, the description adequately lists the returned information. However, missing details on return format or limitations slightly reduce completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds no extra meaning beyond the schema's description of the 'source' parameter. Baseline of 3 is appropriate.

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 explicitly lists what the tool returns (board dimensions, layer summary, counts of footprints/tracks/vias/zones, net count, top nets), clearly distinguishing it from sibling tools that focus on specific aspects like net lengths or components.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. Sibling tools like pcb_component or pcb_net_lengths are more specialized, but the description does not mention which scenarios warrant a general overview.

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

pcb_renderA

Render a PCB in 3D to a PNG and return the image plus the saved file path. Supports camera controls: side, zoom, rotate, pan, pivot, perspective, floor.

ParametersJSON Schema

Name	Required	Description	Default
`pan`	No	Pan camera 'X,Y,Z'
`side`	No	Camera side	top
`zoom`	No	Camera zoom (default 1)
`floor`	No	Enable floor, shadows, post-processing
`pivot`	No	Pivot point relative to board center in cm 'X,Y,Z'
`width`	No	Image width in px
`height`	No	Image height in px
`rotate`	No	Rotate board 'X,Y,Z' e.g. '-45,0,45' for isometric
`source`	Yes	Board name from config OR path to .kicad_pcb (or sibling .kicad_sch)
`quality`	No	Render quality	basic
`background`	No	Background: default, transparent, or opaque
`perspective`	No	Use perspective projection

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It states the output (image + file path) and lists camera controls, but does not clarify whether the tool modifies any state, requires specific prerequisites, or has side effects. It is assumed read-only but not explicitly stated.

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?

Both sentences are concise and informative. The first sentence covers purpose and output, the second lists controls. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not explain the default behavior for camera controls, the format of the returned image (e.g., base64 string or binary), or the exact structure of the saved file path. Given no output schema and 12 parameters, the description could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 12 parameters with descriptions, so the description adds little extra value beyond grouping parameters as 'camera controls'. The baseline for 100% schema coverage is 3.

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 clearly states it renders a PCB in 3D to PNG and returns image and file path. This distinguishes it from sibling tools like pcb_crop or pcb_export_layers which produce different outputs.

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?

The description provides no explicit guidance on when to use this tool versus alternatives like pcb_crop or pcb_export_layers. It only implies usage for 3D rendering needs.

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

reload_configA

Reload configuration from disk without restarting the server

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It states the action but does not disclose potential side effects, error handling, or whether the reload is incremental or full. This is adequate for a simple tool but lacks depth.

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?

A single, front-loaded sentence conveys all essential information with zero waste. Every word contributes meaning.

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 zero parameters and no output schema, the description is sufficiently complete for a straightforward operation. It could mention the default config path, but it's not critical.

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?

The input schema has no parameters, so the description correctly implies no user input is needed. No further parameter documentation is necessary.

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 clearly states the action ('Reload configuration from disk') and distinguishes it from sibling tools like load_board or add_system. It specifies both the resource (configuration) and the effect (without restarting the server).

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?

The description implies usage for applying config changes without downtime, which is clear. However, it does not explicitly mention when not to use it or provide alternatives, though no direct alternative exists among siblings.

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

remove_boardB

Remove a board from the configuration

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Board identifier to remove

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states the action without detailing side effects, reversibility, or destruction implications. This is insufficient for a tool likely performing a mutating operation.

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 a single concise sentence, which is appropriate for a simple tool. However, it could be slightly expanded without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and no output schema, the description is minimally adequate. However, it lacks details about the tool's effect on the system state, which an AI agent might need to reason about consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%; the input schema already describes the 'name' parameter as 'Board identifier to remove'. The description adds no additional semantic context beyond what the schema provides.

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 clearly states the action ('Remove') and the resource ('a board from the configuration'). It is specific and distinguishes from sibling tools like 'add_board' and 'remove_system'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs. alternatives like 'remove_system' or 'load_board'. There is no context about prerequisites or conditions for removal.

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

remove_systemB

Remove a system from the configuration

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	System identifier to remove

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'remove' without detailing side effects, reversibility, or dependencies. For a destructive operation, more context is needed.

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?

Single sentence is concise and front-loaded with purpose. However, it lacks structure for additional critical details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, description fails to explain return value, error cases, or impact on configuration. Minimal completeness for a deletion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter 'name' described as 'System identifier to remove'. Description adds no extra meaning beyond the 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?

Description clearly states action ('Remove') and resource ('a system from the configuration'), distinguishing it from siblings like 'remove_board' or 'add_system'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like modifying configuration directly or using other removal tools. No prerequisites mentioned.

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

search_datasheetB

Search for component datasheet URL using manufacturer and part number

ParametersJSON Schema

Name	Required	Description
`part_number`	Yes	Component part number (e.g., 'ADS1299IPAGR', 'STM32F4')
`manufacturer`	Yes	Component manufacturer (e.g., 'Texas Instruments', 'STMicroelectronics')
`force_refresh`	No	Force new search even if cached result exists

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not mention that this likely performs a web search, whether results are cached, or any side effects. For a read tool, more transparency about the search behavior is expected.

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 very concise, using a single sentence with no wasted words. For a simple tool, this is appropriate. However, it could be slightly expanded to include the optional force_refresh parameter without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description is too minimal. It does not explain the return format, any limitations (e.g., supported manufacturers), or the effect of force_refresh. The tool's complexity is low, but completeness is lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning all three parameters are described in the input schema. The description adds no additional meaning beyond the schema (e.g., it repeats 'manufacturer and part number' but does not clarify force_refresh). Baseline score of 3 is appropriate.

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 clearly states the tool's purpose: searching for a datasheet URL using manufacturer and part number. The verb 'search' is specific, and the resource 'datasheet URL' is precise. Sibling tools are all unrelated to datasheet lookup, so there is no confusion with alternatives.

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?

The description implies usage when a datasheet URL is needed, but lacks explicit guidance on when not to use it (e.g., if the datasheet is already known) or alternatives. No mention of caching behavior or the force_refresh parameter is provided.

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

trace_cross_board_signalC

Trace a signal across multiple boards in a system

ParametersJSON Schema

Name	Required	Description
`signal_net`	Yes	Signal/net name to trace (e.g., '/MISO')
`system_name`	Yes	System name from config
`end_component`	No	Optional: Ending component reference
`start_component`	No	Optional: Starting component reference

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only states 'trace a signal' without any details on side effects (e.g., whether it modifies the system, returns a path, or requires an open session).

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 single-sentence description is concise and to the point, but lacks structural elements like bullet points or separators for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 4 parameters, the description is incomplete. It does not explain return values, output format, or complex behaviors, which is insufficient for a tool that spans multiple boards.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it simply restates the tool's overall purpose.

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?

The description clearly states the tool traces a signal across multiple boards, effectively distinguishing it from sibling tools like pcb_highlight_net or kicad_highlight_net that operate on single boards. However, 'trace' could be more specific (e.g., 'find connectivity path').

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like pcb_net_route or pcb_net_lengths. The description lacks context about prerequisites or scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

30 tool updatesv0.2.0Jul 5, 2026
- First observedadd_board
- First observedadd_system
- First observedget_system_overview
- First observedkicad_focus
- First observedkicad_get_selection
- First observedkicad_highlight_net
- First observedkicad_open_board
- First observedkicad_session
- First observedlist_configured_boards
- First observedlist_configured_systems
- First observedload_board
- First observedload_system
- First observedpcb_component
- First observedpcb_components_near
- First observedpcb_crop
- First observedpcb_current_capacity
- First observedpcb_diff_pair
- First observedpcb_drc
- First observedpcb_export_layers
- First observedpcb_highlight_net
- First observedpcb_impedance_estimate
- First observedpcb_net_lengths
- First observedpcb_net_route
- First observedpcb_overview
- First observedpcb_render
- First observedreload_config
- First observedremove_board
- First observedremove_system
- First observedsearch_datasheet
- First observedtrace_cross_board_signal

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, with detailed descriptions that prevent overlap. Tools like pcb_net_lengths and pcb_net_route both deal with nets but address different analysis aspects, and kicad_* functions for GUI interaction are uniquely scoped.

Naming Consistency4/5

Naming follows consistent prefixes within domains (kicad_, pcb_, add/remove/list/load) but varies between domains. The pattern is predictable and readable, though not uniform across all tools.

Tool Count5/5

30 tools cover a comprehensive range of PCB design operations and KiCad integration without redundancy. The count aligns well with the server's intended scope as an MCP assistant for KiCad.

Completeness4/5

The set covers board management, PCB analysis, rendering, and live KiCad interaction thoroughly. Minor gaps exist (e.g., no schematic or component editing tools), but these are reasonable given the server's focus on analysis and retrieval.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

boardrepo AOAuth
com.boardrepo
Search and review real KiCad and Altium PCB designs: schematics, BOMs, netlists, DRC/ERC.
Developer Tools Embedded system
112
partreel A
io.github.mingyo186
Verified KiCad footprints, symbols & 3D models for AI agents. No signup, CC-BY-4.0, quality-gated.
Embedded system Developer Tools
72
sheetsdata-mcp A
io.github.octoco-ltd
Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
Embedded system Developer Tools Research & Data
12210
catalog A
ai.partsgraph
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Search E-commerce & Retail
111

Related MCP Servers

KiCad MCP Server
Developer Tools Search Documentation Access
skeptomai
A
license
Not graded
quality
D
maintenance
Enables natural language search and exploration of KiCad component symbol libraries with fast full-text search across 20,000+ components including metadata like datasheets, footprints, and descriptions.
Updated 9 months ago (2025-12-08 17:45 UTC)
MIT
kicad-mcp
RAG Systems Design Tools
fsbondtec
A
license
Not graded
quality
B
maintenance
Enables natural language interaction with KiCad projects, schematics, and PCBs, supporting project management, design rule checking, netlist extraction, and datasheet RAG search.
Updated 20 days ago (2026-08-18 06:04 UTC)
2
MIT
KiCAD Schematic Manipulation
Developer Tools
richard-luc
A
license
Not graded
quality
D
maintenance
Enables AI tools to create, edit, and inspect KiCAD schematic files, including components, wires, labels, and sheets.
Updated 6 months ago (2026-03-16 04:38 UTC)
MIT
KiCad MCP Server
Design Tools Command Line Developer Tools
brovk2008
A
license
C
quality
C
maintenance
Enables LLMs to inspect, edit, analyze, and render PCB layouts in real-time using the KiCad IPC API, providing tools for board configuration, footprints, tracks, zones, nets, text, shapes, dimensions, exports, screenshots, and CLI automation.
Updated 2 months ago (2026-07-09 01:29 UTC)
100
1
MIT

Appeared in Searches

A tool for parsing and analyzing CAD drawings

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/bleugreen/kicad-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server