Skip to main content
Glama
Sign In
Copper

Copper

by claynicholson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Schematic: read

sch_read
Read-onlyIdempotent

Reads KiCad schematic data compactly for review or pre-edit checks: component counts, parts, pin names and nets, labels, and unconnected pins with fixes. Use filters to find exact pins.

Instructions

Read the schematic compactly: before editing an existing design, and to find exact pin names. query: summary (default, counts) | components (ref, value, lib_id, footprint, LCSC, position) | pins (every pin of ref with number, name, type and its net) | nets (net -> ['REF.PIN', ...], KiCad's full net names) | labels | unconnected (pins ERC will flag, each with a ready fix). filter = case-insensitive substring. Example: sch_read(query='pins', ref='U1') · sch_read(query='nets', filter='USB')

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sch_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
netNoSingle net for query='nets': full name ('/power/EN') or label name ('EN').
refNoReference for query='pins' (e.g. 'U1').
limitNoMax rows (default 80).
queryNo
sheetNoSub-sheet file or sheet name (default: root sheet).
filterNoCase-insensitive substring filter.
projectNoproject path (default: active)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: compact output by design, default row cap via limit=80, case-insensitive filter matching, KiCad full net-name conventions, and that 'unconnected' entries come with a ready fix. It does not discuss large-design performance or truncation behavior, keeping it from a 5.

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

Conciseness4/5

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

Front-loaded imperative followed by a dense pipe-delimited mode table and two example calls; no filler sentences. The single-line mode list is information-rich but visually packed, which slightly slows parsing compared with a cleaner list structure.

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

Completeness5/5

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

With 7 optional parameters and no output schema, the description carries the return-value burden itself and does so by describing the shape of each query mode (components fields, nets mapping to 'REF.PIN', unconnected with fixes). Combined with schema-documented project/sheet/limit defaults, an agent has enough to call this correctly on the first attempt.

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 86%, so the baseline is 3, but the description explains the query enum values individually — something the bare enum in the schema does not do — and clarifies how ref drives 'pins' and net/filter interplay for 'nets'. The worked examples (sch_read(query='pins', ref='U1')) demonstrate parameter combination concretely.

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

Purpose5/5

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

States a specific verb and resource ('Read the schematic') and immediately enumerates the seven query modes with what each returns, so an agent knows exactly what class of data this yields. The distinction from the PCB sibling is carried by the resource name itself, and 'before editing an existing design' implicitly separates it from the sch_apply write path.

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

Usage Guidelines4/5

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

Gives explicit usage contexts: 'before editing an existing design, and to find exact pin names' — that is a clear trigger for calling it. It does not name an alternative tool or a when-not condition, so it falls short of full routing guidance, but the intended moment of use is unambiguous.

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

Deploy Server

Other Tools