export_gerbers

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description thoroughly discloses behavior beyond annotations: it explains the single-layer versus multi-layer output modes, what output fields are populated in each case, the default behavior when 'layers' is omitted, and that 'include_drill' is ignored in single-layer mode. It also notes that pcb_path and output_dir fall back to configured defaults. This is a model of transparency.

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 efficient and well-organized: a purpose sentence, a behavioral paragraph, then a bulleted Arg list. It packs a lot of information into a relatively small space, though the prose could be slightly more scannable with better use of formatting (e.g., bolding modes). For its length, it's highly effective.

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 file-export tool with all-optional parameters and a clear output schema, the description covers the essential behaviors: mode selection, defaults, and drill handling. Minor edge cases (e.g., behavior with invalid layer names) are not discussed, but these are reasonably outside the core use case and the output schema covers return values.

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?

Since schema description coverage is 0%, the description carries the full burden and does so excellently. It explains each parameter's meaning, defaults, and inter-relationships (e.g., 'include_drill' ignored in single-layer mode, 'layers' with one item yields a single file). This adds immense value beyond the bare schema.

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 opens with 'Export Gerber files for manufacturing,' giving a specific verb and resource that clearly distinguishes it from sibling export tools (e.g., export_pcb, export_netlist, export_3d). It further clarifies the output mode (single file vs directory) and key output fields, leaving no ambiguity about 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it doesn't name sibling alternatives explicitly, it provides clear context on when this tool is appropriate (manufacturing output) and explains the two behavioral modes (single-layer vs multi-layer). The description implies usage through its detailed mode logic but could have gone further to say 'use this instead of X when you need Gerber files.' The guidance is clear and practical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.