Skip to main content
Glama
Sign In
Copper

Copper

by claynicholson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Source BOM

parts_source_bom
Idempotent

Source orderable parts for every schematic component from project providers, checking stock and package and writing part-number, MPN, and manufacturer fields before BOM/fab.

Instructions

BOM sourcing pass: give every schematic component (all sheets) a part from the project's parts providers. Run it once the schematic has values and footprints, before the fab pack. Per component it decides from an existing MPN field, then value + footprint package, then an MPN in the footprint name; existing part numbers are kept (overwrite=true re-picks) and checked against stock and package. Writes the provider's part-number field plus MPN / Manufacturer (write=false reports only). Returns summary (sourced %, parts by class, setup-fee and cost estimates), lines (decided), manual (could not decide: reason + options) and stock_risks. Example: parts_source_bom(write=false) to preview, then parts_source_bom()

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": "parts_source_bom"
  }
}

Input Schema

NameRequiredDescriptionDefault
liveNouse live stock/search (default true; false = offline data only)
writeNowrite fields into the schematic (default true)
boardsNobuild quantity for stock-risk maths (default 5)
projectNoproject path (default: active)
providerNoparts provider to ask (default: the project's parts.providers, in order): lcsc | local | kicad | a third-party name
overwriteNore-pick parts that already have a part number (default false)
basic_onlyNoonly a provider's cheapest assembly class, e.g. JLC Basic (default: the config policy, false)
while_openNorefuse (default) | revert
allow_extendedNoallow them when nothing cheaper fits (default: the config policy, true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the decision precedence (existing MPN field, then value + footprint package, then MPN in footprint name), that existing part numbers are preserved unless overwrite=true, that picks are validated against stock and package, and exactly which fields are written. It also states what write=false does, which is the key safety behavior an agent needs before mutating a schematic.

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

Conciseness4/5

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

Front-loaded with the purpose, then the timing, then the decision logic, then the return shape and an example — a sensible order. It is dense and runs long as one block, but nearly every clause carries operational information rather than filler.

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

Completeness5/5

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

For a 9-parameter mutation tool with no output schema, the description covers the missing piece by naming the return contents (summary percentages, lines, manual with reason + options, stock_risks). An agent knows what it will get back and what state the schematic will be in afterwards.

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, and the description still adds meaning: overwrite=true 're-picks' rather than duplicating, write=false 'reports only', and the provider defaults to the project's ordered parts.providers. The remaining parameters (live, boards, basic_only, allow_extended, while_open) are left to the schema, which is adequate given full coverage.

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 with scope: 'BOM sourcing pass: give every schematic component (all sheets) a part from the project's parts providers.' The batch-assignment nature plus the 'all sheets' scope distinguishes it from the per-part siblings (parts_search, parts_get, parts_alternatives) without needing their schemas.

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

Usage Guidelines4/5

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

Gives clear timing: 'Run it once the schematic has values and footprints, before the fab pack,' and an explicit preview-then-apply workflow via the write=false example. It stops short of naming an alternative for undecided components (e.g. routing 'manual' entries elsewhere), so it is clear context rather than full when/when-not/alternatives guidance.

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