copper-mcp

by seunghyukchoe

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation4/5
Most tools have clearly distinct purposes, but the three board inspection tools (inspect_board, inspect_board_ir, observe_board_scene) could cause selection ambiguity for an agent looking to simply get board state. Descriptions are detailed, but names alone don't fully disambiguate them.
Naming Consistency4/5
Predominantly verb_noun with consistent snake_case. Minor inconsistency: 'compare_candidates' is plural while 'validate_candidate' is singular, and 'server_info' is noun_noun instead of verb_noun, but overall pattern is predictable.
Tool Count5/5
11 tools is well within the ideal range and each serves a distinct purpose in the board design workflow, from inspection to candidate preview/apply.
Completeness4/5
Core route preview/apply, DRC, and board inspection are covered. Placement can only be previewed, not applied, which is a notable but clearly documented gap. There is no direct board editing beyond route application, but the server's stated scope is intentionally limited.
Average 4/5 across 11 of 11 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 152 commits in the last 12 weeks
- Last stable release on August 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It mentions 'normalize' and 'immutable' but does not explain what normalization entails, whether the input is mutated, what validation rules apply, or what the return value looks like. The output schema exists but the description gives no hint of its content.
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 8-word sentence, front-loaded with the verb and directly stating the tool's function. There is zero wasted text, and it conveys the essential purpose efficiently.
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 tool has one nested object parameter and an output schema, the description is too sparse. It omits usage context, validation criteria, normalization behavior, and return value information, leaving the agent to rely on guesswork. The presence of an output schema does not compensate for the missing behavioral and contextual details.
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 only defines a 'candidate' object with no description, so the phrase 'route-candidate manifest' in the description adds semantic meaning by identifying the domain object. However, it does not elaborate on required or expected fields, internal structure, or the effect of normalization, leaving gaps beyond this basic identification.
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 (validate and normalize) and the resource (an immutable route-candidate manifest). This specific verb+resource combination distinguishes it from sibling tools like apply_candidate or compare_candidates, making the purpose unmistakable.
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. It does not mention prerequisites, typical workflows (e.g., before apply_candidate), or any disambiguation from siblings, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It adds useful context by stating that ranking prioritizes hard DRC and connectivity correctness, but it does not state whether the operation is read-only, what the output shape is, or any side effects, leaving noticeable gaps.
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 one sentence, front-loaded with the action and criterion, containing no redundant words. It is concise and well-structured for the information it provides.
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 tool is simple and has an output schema, so return-value details are covered. However, the description lacks context about what fields candidates must contain or how to interpret the ranking, and there are no annotations to fill the gap. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'candidates' array with zero description coverage. The description does not explain the structure of each candidate object or any required fields, so it adds little meaning beyond the parameter name itself.
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 uses the verb 'Rank' with the resource 'candidates' and specifies the ranking criterion (hard DRC and connectivity correctness), which clearly distinguishes it from sibling tools like apply_candidate or validate_candidate. However, it does not explicitly contrast itself with alternatives, so it stops short of a perfect score.
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 when to use the tool (when comparing candidates) but does not explicitly state when to use it over alternatives or mention any exclusions. The usage context is only implied by the name and the ranking statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses two important traits: the tool takes fixed arguments (no customization) and returns a privacy-preserving summary (likely redacting sensitive data). However, it does not state whether the operation is read-only, whether it modifies the board, or what kind of external dependencies (e.g., KiCad installation) are required.
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, front-loaded sentence with no filler. Every phrase earns its place: 'fixed-argument', 'KiCad DRC', and 'privacy-preserving summary' all add meaningful detail without redundancy.
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 tool has only one parameter and an output schema, so the return value is covered. The description is enough to understand the tool's core purpose, but it leaves the parameter semantics unexplained and provides no usage guidance. For a simple tool this is acceptable, yet the missing path semantics and lack of any behavioral context beyond the summary make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single required 'path' parameter with no description. The tool description does not explain what 'path' refers to (board file, project directory, etc.), and schema description coverage is 0%. The parameter name gives a weak hint, but the description fails to add the necessary context.
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 ('Run') and resource ('KiCad DRC'), and adds scope with 'fixed-argument' and 'privacy-preserving summary'. It clearly distinguishes this from sibling tools like inspect_board or validate_candidate, since no other sibling mentions DRC.
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: run this when you need a KiCad DRC check. However, there is no explicit guidance on when to prefer this over alternatives, nor any exclusions or prerequisites. The phrase 'fixed-argument' hints that this is a standard/unconfigurable DRC run, but it does not say 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.
Behavior4/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. It discloses that the tool is a read-only reporting operation ('Report whether') and that it describes structure, which implies no side effects. It does not elaborate on failure modes, prerequisites, or response specifics, but the core behavior is clear.
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, front-loaded sentence with no filler or redundancy. It efficiently states the action and expected outcome, fitting the simple nature of the tool.
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 description covers the high-level purpose but is incomplete for correct invocation. The opaque 'request' parameter and lack of annotations or usage guidance mean the agent cannot determine exactly what input to provide or how this tool relates to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'request' is an opaque, free-form object with 0% schema description coverage. The description never mentions 'request' or its expected contents, only loosely referencing 'a board'. This gives the agent insufficient information to construct a valid request.
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 clearly states the tool's resource ('Board IR') and outcome ('whether a board converts... and describe its structure'). This distinguishes it from sibling tools like inspect_board by focusing on IR conversion specifically.
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 tool is used for checking Board IR conversion and structural description, but it gives no explicit when-to-use or when-not-to-use guidance. Alternatives among siblings are not mentioned, making the usage context only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, offering little safety guidance. The description does add 'private ephemeral' and 'validated', which indicate the resource is temporary and input must be pre-validated. However, it does not disclose what happens on invalid input, whether the operation is repeatable, or any side effects beyond creating the resource.
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 appropriately short—two sentences—with the primary action front-loaded. The second sentence is dense and lists required fields, but it is not overly verbose. A bit more structure (e.g., bullets) would improve readability, but it remains 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?
The tool has a rich output schema and detailed input schema, which reduces the need to describe return values. The description covers input format and resource type, but lacks guidance on validation flow or error behavior. Given the many sibling tools, some cross-referencing would improve completeness.
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?
Although schema coverage is high with descriptions on nested types, the description adds critical semantics: it specifies the exact required fields, the Circuit Intent version 0.1.0, and the allowable component types (two-pin resistors/non-polarized capacitors). This meaningfully complements the schema's structural definitions.
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 opens with a specific verb and resource: 'Render validated Circuit Intent content into one private ephemeral KiCad resource.' This clearly distinguishes the tool from board-focused siblings like inspect_board or preview_placement. The scope is explicit: it renders schematics only.
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 by focusing on Circuit Intent content and the render action, but it does not explicitly state when to choose this over alternatives or mention validation as a prerequisite. The sibling tools are board-focused, so context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the key behavioral traits: the operation is non-modifying and deterministic, and the optional token is single-use and scoped to a specific candidate, board revision, and path. This is excellent 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?
Two concise sentences front-load the core action and then add the optional token behavior. Every word earns its place with no redundancy.
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 poor input schema and no annotations, the description is not complete enough for an agent to construct a valid request. It mentions one optional parameter but omits what data is required in the request object, making usage ambiguous despite the available output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'request' object with no property definitions and 0% coverage, so the description must compensate. It does explain the behavior of one option ('include_apply_token'), but fails to describe other required request fields, leaving the parameter structure largely undefined.
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 ('Preview') tied to a clear resource ('one deterministic two-pin route candidate') and explicitly notes it does not modify files, distinguishing it from apply_candidate. This makes the tool's purpose unmistakable.
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 clearly implies usage as a safe preview step before applying, and explains the condition for obtaining an apply token. However, it does not explicitly contrast with sibling tools like validate_candidate or compare_candidates, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly says 'Return' which implies a read-only operation with no side effects. This is sufficient for a simple info tool, though it does not mention potential errors, auth requirements, or rate limits.
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, front-loaded with the verb 'Return', and contains no filler. Every word adds value, making it a model of conciseness.
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?
The tool is simple (no params), and an output schema exists, so return values don't need description. The description fully covers what the tool does and is distinct from the sibling board tools, providing complete context for selection and invocation.
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, and the schema properties are empty, so there is nothing to document. The description adds no param details, but the baseline for 0 params is 4, meaning no deduction is needed.
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: returning server version, maturity, and implemented capabilities. It distinguishes from sibling tools, which are all board/circuit operations, making it obvious this is an informational utility.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer that it should be used to check server info. No mention of prerequisites, timing, or 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.
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 of disclosing behavior. It explicitly states 'without modifying it', signaling a read-only operation, and mentions 'configured workspace', indicating a scoping constraint. It does not detail error handling or return values, but the output schema covers return specifics.
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, front-loaded sentence that communicates the tool's purpose and safety without unnecessary words. Every part earns its place, achieving maximum conciseness.
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's simplicity (one parameter, output schema present, no annotations), the description is nearly complete. It covers what the tool does and its read-only nature. The only missing element is explicit guidance on when to prefer this over inspect_board_ir, but overall it is sufficiently complete for a straightforward inspection 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?
The schema only defines 'path' with a title, and schema coverage is 0%. The description compensates by implying the path refers to a .kicad_pcb file inside the workspace, adding meaning beyond the schema's bare 'Path'. It does not explicitly state path format (e.g., absolute/relative), but for a single parameter this is sufficient.
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 inspects a .kicad_pcb file within the configured workspace, using a specific verb ('Inspect') and resource (file). It distinguishes from siblings by emphasizing the file type and read-only nature, setting it apart from tools like run_board_drc or observe_board_scene.
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?
Provides clear context by specifying the operation (inspect a board file) and the workspace constraint, implying when to use it (when needing to examine a PCB file without changes). However, it does not explicitly name alternatives or exclusion conditions, leaving some ambiguity relative to similar tools like inspect_board_ir.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, but the description adds substantial behavioral context: it explains that the scene is authoritative, render is advisory and whole-board, strings are untrusted, and objects are split into static/mutable. This goes far beyond the annotations and addresses potential misinterpretations. No contradiction with annotations.
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 thorough but every sentence adds value. It is front-loaded with the core purpose, then systematically explains request parameters, object classification, security stance, and render/scene relationship. Despite length, there is no redundancy or filler; the structure is logical and easy to parse.
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?
Given the tool's complexity and the minimal schema, the description is exceptionally complete. It covers all required parameters, optional parameters, output semantics (via scene and render), data categorization, and security handling. Even without an output schema, the caller would understand what to expect. This is a model description for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal—a single 'request' object with additionalProperties true. The description fully compensates by detailing the required constituents: board, constraints, and region (either a bounding box or around_ref_id with radius_nm), plus optional layers, include_annotations, and include_render. This provides complete semantic meaning where the schema offers none.
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 states a specific verb and resource: 'Observe a workspace board as a bounded, region-scoped Circuit Scene.' This clearly differentiates from siblings by emphasizing the region-scoped scene observation, which is distinctive compared to inspect_board or preview_placement. The purpose is unambiguous and immediately understandable.
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 by explaining the scene's authoritative nature and the advisory render, but it does not explicitly state when to use this tool over siblings like inspect_board or run_board_drc. No alternative tools are named, and no exclusion criteria are given. The context is clear but not directly comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description explains three-valued pad_overlap, that inconclusive is not a failure, courtyard overlap is not_modelled, and that legality is deterministically proven. It also disclaims DRC binding, adding valuable operational context without contradicting annotations.
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 dense but organized into purpose, request structure, and result semantics. While it is longer than typical, each section adds necessary technical detail for a complex tool, and there is no 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?
Given the tool's complexity and the presence of an output schema, the description covers request construction, validation semantics, grid snapping, and return value caveats. It addresses edge cases like inconclusive pad_overlap and non-modelled courtyard overlap, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only exposes a generic 'request' object, so the description is essential. It enumerates the request fields (board, constraints, subjects, optional rules, proposals, placement_grid_nm), describes the seven rule kinds, and explains proposal anchoring by reference rather than absolute coordinates, fully compensating for the empty 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 opening line 'Validate a proposed footprint placement against a board, without changing anything' uses a specific verb and resource, clearly distinguishing it from siblings like apply_candidate and preview_route. The description also clarifies its role as a validation-only tool.
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?
It states the tool never applies a placement, which guides against using it for execution, and positions it as a validation step. However, it does not explicitly name alternative sibling tools or explain when to prefer this over validate_candidate, so the guidance is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint:false and destructiveHint:true, and the description goes far beyond: it explains the disable flag, token requirements, lockfile refusal, pre-apply backup copy as undo, additive-only nature, and exactly what verification does and does not cover. This gives the agent full operational transparency for a destructive mutation.
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?
Well-structured: lead sentence states purpose, then paragraphs cover safety, mechanism, and scope. Every sentence carries unique information; no fluff or repetition of schema. Length is appropriate for the tool's destructive complexity.
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?
Given this is the only mutating tool with complex safety and undo semantics, the description covers prerequisites, failure modes, the backup/undo path, scope limitations, and verification behavior. It is complete for an agent to decide and execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a single opaque 'request' object with additionalProperties:true and 0% field coverage. The description compensates fully by enumerating the fields: board, candidate (manifest from preview), apply_token, expect_board_revision (board digest), and constraints. It also adds meaning to the token and revision fields.
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 opens with a specific verb+resource+effect: 'Apply a previewed route candidate to a board, replacing the file on disk.' It clearly states this is the only tool that changes a board, distinguishing it from all sibling tools like preview_route, inspect_board, and validate_candidate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use (after preview_route with a valid apply_token), when NOT to use (board open in KiCad, placement-only operations), and prerequisites (COPPER_MCP_ALLOW_APPLY=1, token issued by preview_route for exact candidate/revision/path). It also explains the undo mechanism and verification scope, providing complete context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![copper-mcp MCP server](https://glama.ai/mcp/servers/seunghyukchoe/copper-mcp/badges/card.svg)](https://glama.ai/mcp/servers/seunghyukchoe/copper-mcp)

Score Badge

Copy to your README.md:

[![copper-mcp MCP server](https://glama.ai/mcp/servers/seunghyukchoe/copper-mcp/badges/score.svg)](https://glama.ai/mcp/servers/seunghyukchoe/copper-mcp)

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/seunghyukchoe/copper-mcp'

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