Skip to main content
Glama
Sign In
Copper

Copper

by claynicholson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Copper status

copper_status
Read-onlyIdempotent

Checks Copper and KiCad installation status, available board-editing and routing capabilities, active project health, and session costs, then recommends the next useful call.

Instructions

Start here. Shows Copper + KiCad versions and installs, what works on this machine (kicad-cli, KiCad's pcbnew Python for board edits, live IPC socket, Freerouting/Java for autorouting), the active project (+ whether it's open in KiCad, last ERC/DRC counts), recent projects, tool modules that failed to load, session (what this session's Copper calls cost so far) and next: the single most useful next call. detail='credits' returns the per-tool table instead: calls, result bytes, images, estimated tokens.

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

Input Schema

NameRequiredDescriptionDefault
detailNocredits = per-tool cost of this session

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/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 the safety profile is covered; the description adds what the call actually inspects, including failed tool modules and per-session cost accounting. It also discloses the 'next' field, which is non-obvious behavioral guidance an agent could not infer from structured fields.

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 imperative "Start here" is front-loaded and the credits alternative is placed last as a secondary mode. The middle sentence is a long comma-separated inventory, but each item carries distinct information rather than filler.

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?

With no output schema, the description carries the burden of describing returns, and it does so item by item, including the diagnostic fields that matter most before other calls. Minor gap: nothing says how the 'next' recommendation is chosen or whether the status is cheap to re-poll.

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% and the single enum is already documented, so the baseline is 3. The description goes beyond it by spelling out the columns of the credits table (calls, result bytes, images, estimated tokens), giving the agent a reason to choose that mode.

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 purpose with a concrete verb-and-resource inventory: Copper + KiCad versions and installs, capability detection (kicad-cli, pcbnew Python, IPC socket, Freerouting/Java), active project with ERC/DRC counts, recent projects, failed modules, and session cost. That enumeration makes it clearly distinguishable from siblings like project_summary or copper_help.

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?

"Start here" is an explicit entry-point directive, and the detail='credits' branch tells the agent when to prefer the cost table instead of the status view. It stops short of naming an exclusion against copper_help or project_summary, so it is clear context without full when-not 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