mcp-kicad-cli

by SpectraSynq

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.1.0
Disambiguation5/5
Each tool has a unique purpose: schematic tools are prefixed with `sch_`, PCB tools with `pcb_`, and export targets (Gerbers, drill, STEP, IPC2581, GLB) are clearly distinct. No two tools could be confused.
Naming Consistency5/5
Tool names follow a consistent `sch_`/`pcb_` prefix plus verb and optional object pattern, using lowercase with underscores. The `version` tool is the only one without a prefix, but it is a standalone command and does not break the overall consistency.
Tool Count5/5
10 tools is well-scoped for a KiCad CLI server, covering the essential schematic and PCB checks and exports without unnecessary bloat. Each tool serves a distinct and useful function.
Completeness4/5
The set covers core KiCad workflows: ERC/DRC checks, BOM/netlist exports, and common manufacturing outputs (Gerbers, drill, STEP, IPC2581, GLB). Minor gaps like schematic PDF or SVG export are possible additions, but the existing surface is comprehensive for typical use.
Average 2.8/5 across 10 of 10 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Run ERC' without mentioning that it likely writes an output file (`out` parameter), whether it modifies the schematic, or how violations are reported. This lack of behavioral context leaves the agent guessing about side effects and results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified. It lacks essential details, so it is not appropriately sized for the tool's complexity. The brevity is more a drawback than a virtue because it omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no explanation of behavior or usage, the description is severely incomplete. It does not mention what ERC produces, how to interpret results, or how it relates to sibling tools. The agent cannot effectively select and invoke this tool based on the provided description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (`schematic`, `out`, `format`, `exit_code_violations`). It adds no meaning beyond the raw schema, failing to compensate for the absence of parameter documentation.
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 ('Run ERC') and the target resource (a `.kicad_sch` file), making it unmistakable among siblings like `sch_export_bom` and `pcb_drc`. It specifically identifies this as the schematic electrical rules check tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as `pcb_drc` or export tools. It doesn't mention typical use cases, prerequisites, or conditions that would make ERC appropriate. The description only states the action without contextualizing its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral context beyond the tool's name. It does not disclose side effects, whether files are written, required permissions, or anything about the output. The description entirely fails to carry the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but this is under-specification rather than conciseness. It does not earn its place because it provides no additional value over the tool name. A longer description with more detail would be more appropriate.
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 an output schema and only two parameters, but the description is too sparse to be complete. It does not explain the output or any context around the export process. With no annotations, this level of description is inadequate for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The schema itself has 'board' and 'out_dir' with a default, but the description adds no meaning about what these parameters control or how they should be used.
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 'Export drill files' clearly states the verb (export) and resource (drill files), distinguishing it from sibling export tools like pcb_export_gerbers and pcb_export_step. However, it lacks detail about what drill files are or their format, which prevents 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 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 exclusions, prerequisites, or typical scenarios. The only implied usage is literally 'when you need to export drill files,' which is trivial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It merely states 'Run DRC' without revealing side effects (read-only?), output format, exit codes, or error conditions. Even the presence of an output schema isn't referenced, leaving the agent without expectations.
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 a single, waste-free sentence that is easy to parse. However, it lacks structure such as parameter breakdown or output explanation, making it concise but not well-rounded for a tool with four parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters and an output schema (not visible), the description is extremely sparse. It does not explain what the DRC report contains, how the output is saved, or any prerequisites, making it insufficient for an agent to use the tool correctly without additional inference.
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 description mentions the '.kicad_pcb' file, which maps to the required 'board' parameter, but it provides no information about 'out', 'format', or 'exit_code_violations'. With 0% schema description coverage, the description fails to compensate for these undocumented parameters.
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 a specific verb 'Run' and specifies the resource as a '.kicad_pcb' file, clearly identifying the tool as performing design rule check on KiCad PCB files. It distinguishes from sibling tools like sch_erc which targets schematics, but it doesn't expand the DRC acronym or provide additional scope details.
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 guidance on when to use this tool versus alternatives such as sch_erc or export tools. The description does not mention exclusions or specific scenarios (e.g., checking manufacturability), so the agent has no situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'Export a GLB 3D model' without detailing side effects, file creation, overwrite behavior, permissions, or any other behavioral traits. This is minimal and does not inform the agent about operational consequences.
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, front-loaded with the verb and object. It is appropriately brief for a simple export tool, though its brevity borders on under-specification. No unnecessary words are present.
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's complexity (2 parameters) and lack of annotations, the description is insufficiently complete. It omits parameter semantics, usage guidelines, and behavioral context. The presence of an output schema helps but is not referenced, and the agent still lacks key information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters but describes none (0% coverage), and the description adds no additional meaning to 'board' or 'out_file'. There is no explanation of what these parameters represent, their formats, or relationships, leaving the agent to guess despite the parameter names.
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 action (export) and the resource (GLB 3D model), with the format distinguishing it from sibling export tools like pcb_export_step and pcb_export_gerbers. However, it does not explicitly mention the board context, relying on the tool name to imply it, so it lacks full explicit scope.
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 such as STEP or Gerber export. It does not mention typical use cases, prerequisites, or when to avoid this tool, leaving the agent to infer usage entirely from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the high-level function and does not mention side effects, output file handling, or error cases. As an export tool, it likely writes a file but this is not disclosed.
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 with no unnecessary words. It is well-structured and front-loads the primary action, though it sacrifices detail for brevity.
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 having an output schema, the description is too minimal for a tool with three parameters and no annotations. It does not explain the role of 'fields' or 'out_csv', and the lack of parameter semantics makes the tool difficult to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no explanation of the parameters. The parameter names and defaults suggest meanings (e.g., 'schematic' input, 'out_csv' output file, 'fields' selection), but the description adds no value in clarifying expected values or formats.
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 exports a CSV BOM from a KiCad schematic, which is specific enough to distinguish from siblings like netlist export. However, it does not explicitly differentiate from other export tools or mention the context of KiCad projects.
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 about when to use this tool versus alternatives. The description implies usage for BOM generation, but there is no mention of prerequisites, typical workflows, or when another tool like sch_export_netlist would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral disclosure. It only states the action without revealing side effects (e.g., file creation), required permissions, or output behavior. This is insufficient for an export tool.
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 single sentence is not verbose, but it is under-specified rather than appropriately concise. It conveys the core function but omits needed details, so it is not a model of effective brevity.
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 having an output schema, the description lacks critical context for a tool with three parameters and no annotations: what formats are supported, where output is written, whether overwriting occurs, and any prerequisites. It is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The three parameters (fmt, out_net, schematic) are left entirely to the schema, whose titles and defaults are minimal and do not clarify formats or relationships.
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 the specific verb 'Export' and names the resource 'schematic netlist', clearly distinguishing it from sibling tools like sch_export_bom and pcb_export_*. It unambiguously 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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or when a different export tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the action without disclosing side effects, prerequisites, or output behavior. It does not mention that a file is created or whether the board must be open.
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 sentence with no fluff, making it concise and front-loaded. However, the brevity sacrifices detail, though it earns high marks for structure.
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 is too minimal for a 2-parameter export tool with no annotations, missing context on what IPC-2581 is, what the board parameter expects, and how the output file is used. The presence of an output schema does not compensate for the lack of parameter and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'board' or 'out_file' parameters. The agent must rely solely on parameter names, which is insufficient for correct invocation.
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 IPC-2581 manufacturing data, identifying the specific format and action. This distinguishes it from sibling export tools like pcb_export_gerbers and pcb_export_step.
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, such as selecting IPC-2581 over Gerber or STEP formats. Usage is implied by the format name but never explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Export a STEP 3D model' gives no information about side effects, output location, or required inputs, leaving the agent without critical behavioral context.
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 redundant words. Every word earns its place, making it highly concise and structured.
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 export tool, the description is minimally adequate but lacks context about what 'board' refers to and how the output file is used. The presence of an output schema reduces the need to explain return values, yet the overall description leaves gaps for correct invocation.
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 shows two parameters (board, out_file), but the description adds zero parameter information. With schema description coverage at 0%, the description fails to compensate, leaving the agent to rely solely on parameter names and defaults.
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 exports a STEP 3D model, which is a specific verb and resource. It distinguishes itself from sibling export tools by naming the STEP format, though it does not explicitly contrast with alternatives like pcb_export_glb.
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 other export tools. It merely states the function without context about when STEP is preferred or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose side effects (e.g., writing files, creating directories) or any preconditions. 'Export' implies file writes, but no detail is provided, and there is no mention of output location or potential overwriting.
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, focused sentence with no redundancy, front-loading the action and the key detail (one-file-per-layer). Every word earns its place.
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 (2 params) and has an output schema, but with no annotations and no parameter descriptions, the description is thin. It covers the core purpose but omits context like output location, behavior, and side effects.
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?
Neither the description nor the schema (coverage 0%) explains the 'board' or 'out_dir' parameters. The description does not connect parameters to behavior, leaving the agent with zero parameter semantics beyond names.
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 ('Export'), the resource ('Gerbers'), and a distinguishing format ('one-file-per-layer'), which sets it apart from other export tools like pcb_export_drill or pcb_export_step.
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 (e.g., pcb_export_drill for drill files, pcb_export_step for STEP models). The description only states what it does, leaving usage decisions to the agent.
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. It explicitly indicates a read-only query ('Return the installed...') with no side effects, which is sufficient for this simple tool. Nothing is hidden or misleading.
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, clear, front-loaded sentence with no wasted words. It perfectly conveys the tool's function without padding.
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 minimal complexity (no parameters, no annotations, output schema present), the description fully covers what the tool does. No return value explanation is needed because the output schema exists.
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 is 4. The description adds no parameter details because none are needed; the schema confirms an empty parameter set.
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 returns the installed KiCad CLI version, using a specific verb ('Return') and a clear resource. It is easily distinguished from all sibling tools, which are for schematic/PCB operations.
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 purpose is self-evident: use this when you need the installed CLI version. While it does not explicitly discuss alternatives, the context is clear and there are no competing tools for this function.
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:

[![mcp-kicad-cli MCP server](https://glama.ai/mcp/servers/SpectraSynq/mcp-kicad-cli/badges/card.svg)](https://glama.ai/mcp/servers/SpectraSynq/mcp-kicad-cli)

Score Badge

Copy to your README.md:

[![mcp-kicad-cli MCP server](https://glama.ai/mcp/servers/SpectraSynq/mcp-kicad-cli/badges/score.svg)](https://glama.ai/mcp/servers/SpectraSynq/mcp-kicad-cli)

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

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