kicad-mcp

by lucatib

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 targets a distinct resource and action: schematic vs board vs library vs project vs status. The few symbol-related tools are clearly differentiated by their purpose (listing placed symbols, searching libraries, getting pin data).
Naming Consistency4/5
The majority follow a consistent verb_noun pattern (list_*, get_*, run_*, export_*, search_*, open_*, find_*, create_*). Two tools deviate slightly: 'schematic_netlist' and 'kicad_status' are noun_noun, but they remain readable and the overall style is uniform.
Tool Count3/5
At 23 tools, this sits at the high end of the expected range. The count is justified by KiCad's breadth (schematic, board, libraries, execution), but it feels slightly heavy for a single server and will require careful descriptions to avoid overwhelming agents.
Completeness4/5
The tool surface covers the key read/analyze operations for schematics, boards, and libraries, plus generation via create_pinout_schematic and arbitrary extension via run_kicad_script. Missing are explicit edit/update operations for board or schematic elements, but the script runner mitigates those gaps.
Average 3.7/5 across 23 of 23 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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, the description carries full burden. It states the output formats and mentions kicad-cli, but does not disclose that the tool writes a file to disk, whether it overwrites existing files, or any required permissions or side effects. This is minimal behavioral transparency for a tool with no annotation support.
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 sentence that is front-loaded with the action and resource, and every word adds value. It is appropriately sized for a simple tool with a clear purpose, avoiding unnecessary detail.
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 absence of annotations and an output schema, the description should provide more context about invocation, expected results, and limitations. It only covers the 'what' and not the 'how' or 'when', leaving significant gaps for correct usage.
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?
Schema description coverage is 0%, so the description must compensate. It implicitly covers the 'fmt' parameter by listing allowed formats, but it offers no explanation for the required 'path' parameter or the optional 'output' parameter. The meaning of these parameters is left entirely to the schema, which lacks descriptions.
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 'plot' with a clear resource 'schematic' and enumerates the supported output formats (pdf, svg, dxf, ps, hpgl). This clearly distinguishes it from sibling tools like export_bom or schematic_netlist, which focus on other output types.
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. It does not mention that for netlist export one should use schematic_netlist or for BOM export use export_bom. The only contextual hint is 'via kicad-cli', but that does not clarify selection criteria.
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 must fully disclose behavior. It states the operation (listing nets) but does not explicitly mention that it is read-only, how it handles missing boards, the format of glob patterns, or any potential side effects. The absence of such details leaves the agent without a complete behavioral picture.
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 that is front-loaded with the primary action 'List nets' and includes the key optional filter. Every word adds value, and there is no redundant information or filler.
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?
This is a simple tool, but without annotations or an output schema, the description must explain the expected return and any constraints. It does not describe what information is returned for each net, how limit interacts with the results, or any error conditions, making the tool's behavior incomplete for an agent.
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?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains that 'name' filters by glob pattern, but it entirely omits the 'limit' parameter, which controls the maximum number of results. With one parameter unexplained, the description only partially compensates for the missing schema descriptions.
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 identifies the tool as listing nets on the open board, with an optional filter by glob pattern. It uses a specific verb ('List') and resource ('nets'), and the mention of nets distinguishes it from sibling tools like list_tracks_vias and list_zones.
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 only 'on the open board' as context, implying the tool operates on the current board, but it gives no explicit guidance on when to choose this tool over alternatives or any exclusions. There is no mention of scenarios where this tool is not appropriate or when a sibling tool 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 must carry behavioral disclosure. It states the tool lists zones on the open board, but does not mention the default limit of 100 or whether results can be truncated, nor what happens if no board is open. This leaves important behavioral traits undisclosed.
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, focused sentence that efficiently states the tool's purpose without waste.
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 description is adequate for a simple list tool, mentioning the resource and key output fields, but lacks context about the limit parameter and usage scenarios; with no output schema, the return format is only partially implied.
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 'limit' parameter with no description, and the tool description does not mention it, so the agent receives no explanation of how the limit works or its default value. The description fails to compensate for the 0% schema 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?
The description uses the specific verb 'List' and identifies the resource as 'copper zones on the open board,' also noting the returned attributes 'nets and layers.' This clearly distinguishes it from sibling tools like list_tracks_vias.
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 usage guidance is provided; the description does not specify when to choose this tool over alternatives like list_tracks_vias or list_nets, nor does it mention any exclusions.
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 of behavioral disclosure. It does not mention potential side effects (e.g., file creation/overwriting), whether the schematic must be open, or any permissions required. The phrase 'Export ... to CSV' implies writing but is not explicit.
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, front-loaded sentence directly states the tool's operation without wasteful words.
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?
Given the minimal 2-parameter schema and no output schema, the description gives the core action but omits details like default output path, whether the tool writes files, and error conditions. It is adequate but incomplete for an agent needing to invoke it safely.
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?
Schema descriptions are 0% covered. The description partially compensates by linking 'schematic' to the required path parameter and 'CSV' to the output parameter, but it doesn't explain the optional output behavior or default.
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 names an explicit verb 'Export' and identifies the resource 'a Bill of Materials from a schematic' and the format 'CSV via kicad-cli', making it clear and distinct from sibling tools like export_schematic.
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 instead of alternatives, nor any prerequisites or exclusions. The description only states the action, leaving users to infer usage 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only lists file categories and does not mention whether the search is recursive, whether paths are absolute or relative, how errors are handled, or what the return format looks like.
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 clear sentence that is front-loaded with the action and includes concise examples of file types. No unnecessary words or 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?
Despite being a simple tool, there is no output schema and no annotations, so the description must explain return values and edge cases. It does not mention what is returned (e.g., file names, full paths) or behavior like recursion, making it insufficient for an agent to invoke it with full confidence.
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?
With schema description coverage at 0%, the description must compensate. It only says 'in a directory', which barely adds meaning to the parameter name 'directory'. It does not explain the expected format (e.g., absolute/relative path), whether the directory must exist, or how it is used.
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 verb 'List', the resource 'KiCad project files', and the scope 'in a directory'. It further specifies file types ('schematics, boards, and project files'), which distinguishes it from sibling tools that list other entities like tracks or symbols.
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 stating it lists project files in a directory, but it does not explicitly say when to use this tool versus alternatives or provide exclusions. There is no mention of prerequisites or comparison to sibling tools.
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, and the description does not disclose side effects, permissions, or prerequisites. It mentions the returned data but fails to clarify that it is a read-only operation or what happens if the symbol is not found.
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 two concise sentences, front-loaded with the core function and ending with a practical usage hint. 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?
Provides a clear purpose and usage context, but omits parameter semantics and behavioral details. Given the lack of annotations and output schema, the description could be more comprehensive, but it remains minimally viable for a simple getter.
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 has 0% description coverage, and the description does not explain the meaning or usage of lib_id or project_dir. The description adds no parameter-level guidance whatsoever.
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?
Description clearly identifies the tool's function: retrieving every pin of a library symbol with specific attributes (number, name, electrical type, position). It distinguishes itself from sibling tools like list_symbol_libraries or list_schematic_symbols by focusing on pin-level data.
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?
Explicitly states when to use the tool ('Use this to learn a part's pinout before wiring it'). However, it does not mention when not to use it or provide alternative tool names, so it falls 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.
Behavior3/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 defines the stackup content but does not explicitly state that the operation is read-only, nor does it mention any side effects, prerequisites, or error conditions. The read-only nature is implied by the 'get' prefix, but that is not sufficient for a higher score.
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 that immediately identifies the subject and lists the key data types. No waste or redundancy.
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 (no parameters, no output schema), the description covers the primary content returned. However, it could be slightly more complete by explicitly stating the return structure or units, and it lacks usage context relative to sibling tools.
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 takes zero parameters, so the baseline of 4 applies. There are no parameter details to elaborate beyond the empty schema.
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 identifies the resource as the board's physical stackup and enumerates the contained information (layer order, materials, thicknesses). However, it uses a noun phrase rather than an explicit action verb, relying on the tool name 'get' to imply the operation.
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 regarding when to use this tool or how it differs from siblings like get_layers. There are no prerequisites, exclusions, or alternative tool mentions.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It mentions using kicad-cli and the output contents, but it does not clarify whether the operation is read-only, whether it writes files, how the 'limit' parameter affects results, or any other side effects.
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 short and front-loaded: two sentences that convey the core function and the key benefit. Every word adds value, and there is no redundant filler.
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 3 parameters, no annotations, and no output schema, so the description must compensate. It explains the general result but leaves out important contextual details like return structure, pagination/limiting behavior, the meaning of include_nodes, and whether the operation is destructive or read-only. This is insufficient for reliable tool selection and 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?
Schema description coverage is 0%, and the description does not explain the 'path', 'limit', or 'include_nodes' parameters. More critically, it claims 'every component and every net' but the schema shows a default 'limit' of 400, which may conflict with that claim and confuses users about parameter behavior.
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 specific verbs ('Export and parse') and a clear resource ('a schematic's netlist'), and explains the content: every component and every net with connected pins. It also distinguishes itself as 'the most complete view of schematic connectivity' among sibling tools like list_nets.
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 this tool is for full, comprehensive connectivity data ('The most complete view...'), but it does not explicitly state when to prefer it over alternatives like list_nets or export_schematic, nor does it mention any exclusions or prerequisites.
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?
With no annotations, the description discloses the substring matching behavior and that the return value is lib_ids. However, it does not cover behavior around optional parameters (library, project_dir), limit, case sensitivity, or empty results.
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-loaded with the verb and resource, with examples. Every word adds value; no filler.
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 4 parameters, no output schema, and no annotations, the description is too short to be complete. It omits the role of library and project_dir filters, the default limit, and any output details beyond lib_ids.
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?
Schema has 4 parameters with 0% description coverage. The description only explains the query parameter indirectly via examples and 'name substring', but leaves limit, library, and project_dir unexplained, so an agent cannot infer their purpose or valid values.
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?
Description clearly states the tool searches symbol libraries by name substring with concrete examples ('ESP32-S3', 'LM358'). It distinguishes from siblings like list_symbol_libraries by focusing on search, and names downstream consumers of the returned lib_ids.
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?
It implies usage context—search when you need a lib_id to pass to get_symbol_pins or create_pinout_schematic—but does not explicitly state alternatives or exclusions. No mention of when to use list_symbol_libraries instead.
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?
With no annotations, the description must disclose behavior, but it only details the output content (pads, net, position, layer). It does not explicitly state that the operation is read-only, nor does it mention error behavior for unknown references. The 'get' prefix implies read-only, but the description adds little beyond that.
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 that immediately conveys the scope and contents. It is front-loaded and contains no redundant information.
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 one-parameter getter, the description covers the returned content but lacks details on the 'reference' parameter format and the exact return structure of pads (e.g., coordinate system, layer names). Without an output schema or annotations, this is a minimum viable description but leaves gaps in parameter semantics and return expectations.
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?
Schema coverage is 0%, so the description must compensate, but it does not explain the 'reference' parameter. It is unclear that 'reference' likely means the footprint's reference designator (e.g., R1, U2). The description mentions 'one footprint' but does not connect it to the parameter semantics.
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 identifies the tool as retrieving full details for a single footprint, including pads with net, position, and layer. This distinguishes it from sibling tools like list_footprints, which list footprints, and get_board_summary, which provides board-level info.
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 for a specific footprint ('one footprint') but does not explicitly mention alternatives or contrast with list_footprints. It offers no when-to-use or when-not-to-use guidance, leaving the context to be 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?
With no annotations provided, the description carries the full burden. It discloses the output fields and filtering behavior, which are behavioral traits, but it does not explicitly state that the operation is read-only, nor does it mention error conditions or path requirements. The verb 'List' implies non-destructive, but more detail would increase 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?
The description is a single sentence, clearly front-loaded with the verb and resource. It concisely lists output fields and the filtering capability without extraneous information. Every word contributes value.
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 description explains what the tool returns and that filters exist, which is adequate for a simple list tool. However, it omits details about parameter semantics and does not provide guidance on when to use the tool relative to siblings. The lack of an output schema puts more burden on the description, but it covers core return fields.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'glob patterns' but does not explain that 'value' and 'reference' parameters are the glob filters or what 'limit' controls. This leaves parameter meanings under-specified beyond the schema's bare titles.
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 function: listing symbols in a .kicad_sch file, and specifies the exact data fields returned (reference, value, lib_id, position, footprint). This verb+resource+scope structure distinguishes it from sibling tools like list_tracks_vias and list_symbol_libraries.
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 for retrieving placed symbols from a schematic file and mentions glob filtering, but it does not explicitly state when to prefer this over alternatives like search_symbols or list_symbol_libraries. There is no exclusion or comparison context, so usage guidance remains implicit rather than explicit.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It adds the key detail that the tool resolves both global and project sym-lib-tables, which is a useful behavioral trait. However, it does not explain what happens when project_dir is null, nor does it hint at the output structure, leaving some behavioral ambiguity.
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 sentence that is front-loaded with the core verb and resource. It is concise with no filler or redundant information, earning a top score.
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 with one optional parameter and no output schema, so the description need not be lengthy. However, it lacks any mention of the return format or how the project_dir parameter alters behavior, which are meaningful gaps for this context. It is minimally adequate but not 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?
Schema description coverage is 0%, so the description must compensate. The only parameter, project_dir, is not explicitly explained in the description. The phrase 'global and project sym-lib-tables' indirectly implies that project_dir selects the project table, but it does not describe the effect of null vs. a provided path, leaving the parameter's semantics unclear.
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 'List' with the resource 'symbol libraries available', clearly distinguishing this from sibling tools like list_schematic_symbols (which lists symbols on a schematic) and search_symbols (which searches for symbols). Mentioning the resolution of KiCad's global and project sym-lib-tables further clarifies the exact scope.
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 for enumerating library definitions but does not explicitly state when to use it versus alternatives such as search_symbols or list_schematic_symbols. There is no explicit exclusions or alternative guidance, so usage context is only implicitly derived from the wording.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the scope ('on the open board') and the optional filtering, which implies a read-only list operation. However, it does not mention any side effects, prerequisites beyond an open board, or the return format/pagination behavior. For a read-only tool, this is passable but not fully transparent.
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, well-formed sentence that front-loads the core verb and resource, then adds the optional filter. There is no redundant wording or unnecessary detail, making it highly concise and readable.
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?
Given the tool's simplicity (two optional params, no output schema, no annotations), the description is minimally adequate but leaves gaps. It does not mention the 'limit' parameter, what data is returned (e.g., coordinates, net associations), or any error conditions. A slightly richer description would improve completeness for agents, but the current one is acceptable for a basic list operation.
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 description coverage is 0%, so the description must compensate for parameter meanings. It clarifies that the 'net' parameter filters by net name, which is helpful. However, it completely omits the 'limit' parameter, leaving its purpose (limiting the number of results) undocumented. With two params and only one partially explained, the description fails to adequately support parameter understanding.
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 'List' and identifies the resource as 'tracks and vias on the open board', which clearly states what the tool does. It also mentions an optional filter by net name, adding precision. This distinguishes it from sibling list tools like list_nets or list_footprints.
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 when you need to inspect tracks/vias on the current board and optionally filter by net, but it provides no explicit guidance on when to prefer this over sibling tools or when not to use it. There are no exclusions or alternative tool references, leaving usage context somewhat vague.
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 that violations are returned as results rather than failures, which is valuable behavioral context. However, it does not state whether the operation is read-only, what happens on invalid file paths, or any side effects. It adds some transparency but is not comprehensive.
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 sentences, front-loaded with the core action. The first sentence gives the verb, resource, and method; the second clarifies a critical interpretation detail. Every sentence earns its place with no wasted words.
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 check tool with only two parameters, the description covers the main action and one key behavioral note. However, it lacks details about the output format, what the report contains, and especially the meaning of severity_all. With no output schema and no annotations, notable gaps remain, though the tool is not highly complex.
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 has 0% description coverage and the description explains neither parameter directly. 'path' is only implied as the schematic file location via 'on a schematic', while 'severity_all' is completely unaddressed. The description does not compensate for the missing schema descriptions, leaving agents to guess the meaning of the boolean parameter.
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 runs an Electrical Rules Check on a schematic via kicad-cli and returns the report. The specific verb+resource and 'Electrical Rules Check' distinguish it from sibling run_drc (Design Rules Check) and other schematic tools. It is unambiguous about what the tool does.
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 for electrical rule checking but does not explicitly contrast with alternatives like run_drc or state when not to use it. The note about non-zero violation count provides output interpretation guidance but not usage timing. There is no explicit when/when-not guidance, though the purpose is clear enough for inference.
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?
The description discloses that it runs kicad-cli and returns a report, but fails to mention whether the operation is read-only, what happens on invalid paths, or the report's format. Since no annotations are provided, these behavioral traits are under-specified.
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 containing all key information: action, target, tool, and result. No unnecessary words or repetition.
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 one-parameter tool with no output schema or annotations, the description is minimally sufficient but lacks details about the report's content or format and the side effects of running DRC. It does not mention error behavior or whether any files are created or modified.
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 provides a parameter named 'path' with no description. The description adds crucial meaning by indicating the path must point to a .kicad_pcb file, which is essential for correct invocation. However, it doesn't detail path constraints like absolute vs relative or validation behavior.
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 'Run' with resource 'Design Rules Check' and specifies the target file type (.kicad_pcb) and method (via kicad-cli). It clearly distinguishes from sibling run_erc, which covers electrical rules checking, and other schematic/PCB tools.
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 use for PCB design rule checking on .kicad_pcb files, but does not explicitly state when to prefer it over alternatives like run_erc or provide exclusions. The context of PCB file type provides some guidance, but no direct comparison is made.
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 the scope (enabled, visible, active layers) and that it lists names. However, it does not describe return format, potential side effects (though 'List' suggests read-only), or other behavioral details. For a simple read-only tool, this is adequate but not rich.
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 that is front-loaded with the action ('List') and resource. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema list tool, the description is complete. It specifies exactly what is listed (enabled, visible, active layers) and with their names. No additional context is needed for an agent to select and invoke it.
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 is empty. Per the rubric, baseline is 4 when there are no parameters. The description does not need to explain parameter meaning since none exist.
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 ('List') and names the resource ('board's enabled, visible, and active layers') with their names. It clearly distinguishes from sibling tools like list_nets or list_zones.
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 (to retrieve layer information) but does not explicitly state when to use this tool versus alternatives, nor any exclusions. Since there is no direct sibling for layers, the implication is sufficient but not explicit.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states what the tool returns (the current selection) and gives a use case, but it does not disclose whether the operation is read-only, what happens when nothing is selected, or the structure of the returned data. This is adequate but leaves gaps for an agent relying solely on this description.
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 two sentences long and front-loaded with the core function. The first sentence states what the tool does, and the second provides usage guidance. Every word earns its place, with no redundancy or unnecessary detail.
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 (no params, no output schema, no annotations), but the description does not explain the return format or edge cases like empty selections. Without an output schema, the description should compensate by specifying what kind of data to expect, which is missing. The purpose and use case are clear, but operational completeness is lacking.
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 schema coverage is trivially 100%. The baseline for 0 params is 4, and the description does not need to add parameter-level detail since there are none. The mention of 'in the KiCad GUI' provides useful context but is not parameter-related.
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 function: returning what the user currently has selected in the KiCad GUI. It uses a specific resource ('selection in KiCad GUI') and distinguishes itself from sibling tools that list specific object types (tracks, zones, symbols) by focusing on the current selection.
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 provides explicit use-case guidance: 'Use this to act on "the thing I'm looking at".' This clearly implies when to use the tool, though it does not explicitly mention alternatives or exclusions. The context is clear enough for an agent to select this over listing tools when the user references their current selection.
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?
Despite having no annotations, the description thoroughly discloses non-obvious behavior: case/underscore/hyphen-insensitive matching, automatic wire/net label creation, power symbol generation with PWR_FLAG, and direct file writing without KiCad. These details go beyond what the schema or annotations provide.
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 short and well-structured, with four information-dense paragraphs that front-load the purpose and then explain key behavioral nuances. There is no filler; every sentence contributes meaningful guidance.
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 description covers the core operation and the most complex parameter, but it omits explanations for 7 of 8 parameters and does not address return values or side effects like overwriting. Given the tool's complexity and lack of annotations, this the description is useful but leaves noticeable gaps for full autonomous use.
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?
Only the `assignments` parameter receives semantic explanation with an example and normalization rules. Other parameters like `connect_power`, `project_dir`, `footprint`, and `reference` are left entirely to the schema's sparse titles, so the description fails to compensate for the 0% schema 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?
The description explicitly states the tool's action and output: 'Create a .kicad_sch from a firmware pinout by importing a symbol from a KiCad library.' This clearly distinguishes it from the read-only sibling tools like list_symbol_libraries or export_schematic.
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 implies the use case (generating a schematic from pin assignments) and notes that KiCad does not need to be running, which signals when this tool is appropriate. However, it does not explicitly name alternative tools or negative conditions, so it lacks a full exclusion list.
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?
With no annotations, the description must disclose behavioral traits. It indicates the tool is a reporting/diagnostic function via 'Report' and mentions checking 'live connection,' implying it verifies connectivity. However, it does not explicitly state it is read-only or describe output format, leaving some ambiguity about side effects.
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 sentences: the first states the purpose with a clear list, the second gives usage guidance. No wasted words.
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?
The description covers the tool's purpose and when to use it. With no output schema, it could describe the return format in more detail, but for a status/health check with zero parameters, the current description is sufficient.
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?
Since the tool takes zero parameters, the description need not explain parameter semantics. It does enumerate what the tool reports, which adds context even though no parameters exist.
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 'Report' and identifies the resource as 'the KiCad environment', listing concrete aspects (install, versions, live connection, capabilities). This clearly distinguishes it from sibling tools that perform specific 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?
It explicitly says 'Call this first when anything behaves unexpectedly,' which provides a clear when-to-use directive. However, it does not mention alternatives or exclusions, so it stops short of a full 5.
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 exist, so the description carries the full burden. It adds useful context ('open board', positions in millimetres) but does not disclose limit behavior, return format, or ordering. Adequate for a simple read-oriented list, but not rich.
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 sentences, front-loaded with the primary action. Every phrase adds information—no filler or repetition.
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?
For a simple list tool with three optional parameters and no output schema, the description covers the core purpose, board scope, filtering capabilities, and unit details. Minor gap: no mention of limit behavior or default count, but overall sufficient.
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 has no property descriptions, and the description compensates by explaining reference ('R*') and value ('10k') with glob examples. However, the 'limit' parameter is left undocumented, so coverage is partial.
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?
Clear verb+resource: 'List footprints on the open board' explicitly states what it does. Distinguishes from siblings by specifying footprints (vs tracks/vias, zones, schematic symbols) and board context.
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: operates on the open board and supports filtering by reference/value with glob patterns. Does not explicitly mention alternatives, but the filter examples give actionable guidance on when to use its features.
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?
With no annotations, the description carries the burden of disclosing behavior. It explains the file-based nature and lack of IPC, which is useful, but it does not describe the output format, error handling, or whether the tool modifies anything. It is a read-like operation implied by 'summarise' but not explicitly stated.
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: the first states the action and expected output, the second provides rationale and limitation. Every word earns its place with no repetition or fluff.
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 only one parameter, no output schema, and no annotations, the description gives a reasonable overview of purpose, file type, and expected summary contents. It could mention return format or file requirements, but it is sufficiently complete for a simple tool and its sibling context.
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 names 'path' as a string with no description. The description's mention of '.kicad_sch file' clarifies that the path must point to a KiCad schematic file, adding meaning beyond the schema. It could be more specific about path format, but for a single parameter this is adequate.
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 opens a .kicad_sch file and produces a summary (title block, counts, child sheets). The specific verb 'Open' and resource type differentiate it from sibling tools like list_schematic_symbols or list_nets.
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 provides clear context: it works with KiCad closed because schematic access is file-based. This implies when to use (file-based, KiCad closed) and indirectly contrasts with tools that may require running KiCad, but it doesn't explicitly name alternatives or exclusions.
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 the tool's behavior by listing the exact return fields and emphasizes that it is a 'cheap orientation call,' indicating low cost. It does not cover error cases, but for a simple summary tool, this is sufficient 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?
The description is two sentences, front-loaded with the verb and resource, and every word adds value. The first sentence states exactly what the tool does; the second provides usage context. There is no redundancy or 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 that the tool has no parameters and no output schema, the description fully covers what the agent needs to know: the purpose, the specific items returned, and the usage context. It is complete for its simplicity.
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 there is nothing for the description to explain about parameters. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description adds no unnecessary parameter details; it focuses on output instead, which is appropriate.
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 action ('Summarise') and resource ('the board open in KiCad'), and specifies the exact content of the summary (name, layer count, item counts, title block, origin). This distinguishes it from sibling tools like list_tracks_vias or get_layers, which focus on specific subsets rather than an overview.
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 explicitly says 'A cheap orientation call before more specific queries,' which informs the agent when to use this tool. While it doesn't name specific alternatives, it clearly positions this as a preliminary overview, implying usage before more detailed sibling tools.
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 provided, the description carries the full burden of disclosure and does so well: it states that the tool runs arbitrary local code with the user's privileges, explains how print output is captured, and how to return a value via the 'result' variable. It also warns about a known broken import.
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 compact and front-loaded, with every sentence providing necessary information: purpose, usage, environment, return mechanism, and warnings. No filler or redundancy.
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?
Despite having no annotations or output schema, the description sufficiently covers the important behavioral aspects of a fallback script execution tool, including environment, return protocol, and safety considerations. Minor gaps like timeout semantics are partially covered by the schema default.
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 description provides context for the `code` parameter by listing available Python names and showing how to return values, but it does not explain the `timeout` parameter at all. With 0% schema description coverage, this gap is not fully compensated.
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 executes Python with the KiCad API pre-imported, and explicitly frames it as a fallback for anything the curated tools do not cover. The verb 'Execute' and resource 'Python with the KiCad API' are specific and distinguish it from the sibling tools.
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?
It gives explicit when-to-use guidance: 'Use this for anything the curated tools do not cover,' implying curated tools should be preferred. It also provides a specific exclusion about kipy.schematic, making limitations clear.
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:

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

Score Badge

Copy to your README.md:

[![kicad-mcp MCP server](https://glama.ai/mcp/servers/lucatib/kicad-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lucatib/kicad-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/lucatib/kicad-mcp'

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