Export Excellon drill files for the open PCB to a chosen directory, creating it if needed and optionally saving the board first.
Export drill files (Excellon) for the open PCB into a directory.
Args: output_dir: Destination directory (created if needed). save_first: Save the board before exporting.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | Yes | ||
| save_first | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some useful context: output_dir is 'created if needed' and save_first 'Save the board before exporting.' However, it does not disclose whether existing files are overwritten, what happens on failure, or any permission requirements, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a single-sentence purpose statement followed by a compact Args section. Every sentence serves a purpose, and the core action is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with an output schema already documenting return values and no annotations to cover, the description is largely complete. It covers purpose and both parameters adequately. A minor gap remains regarding overwrite behavior and error conditions, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the schema's lack of parameter documentation. It defines both parameters: output_dir as the destination directory (created if needed) and save_first as saving the board before exporting. This adds clear meaning beyond the bare schema titles, though it could include more detail on path format or overwrite behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Export drill files (Excellon) for the open PCB into a directory.' It clearly distinguishes this tool from other export siblings (e.g., export_gerbers, export_step) by naming the exact file type and format. An agent can identify the tool's purpose without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives like export_gerbers or export_pos. It merely restates the tool's action, leaving the agent to infer usage context entirely. No prerequisites, exclusions, or comparative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.