drc_klayout

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

With no annotations provided, the description must fully convey behavior. It accurately describes the operation (batch DRC run), mentions the default smoke deck, and clarifies that it is not LVS. However, it does not explicitly state whether the tool modifies any files or generates a report, though the DRC context implies read-only analysis. This is a minor gap given the lack of annotations.

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 concise and well-structured: it opens with the primary action, clarifies the default behavior, then provides the custom deck option, and ends with an explicit LVS exclusion. Each sentence adds essential information without fluff or redundancy.

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?

The description gives sufficient context for selecting and invoking the tool, including the default vs. custom deck use case and the LVS distinction. However, it does not mention what output or report format the DRC run produces, which could be useful for interpreting results. Since no output schema is provided, this slight omission leaves a minor gap in completeness.

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?

All five parameters are documented in the input schema with meaningful descriptions (e.g., cwd as working directory, gds_file as the layout, space_um and width_um with defaults, deck_file for custom DRC rules). The main description adds context on how to use deck_file versus the default, fully covering parameter meaning. Schema coverage is 100%, leaving no ambiguity.

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 clearly states that the tool runs KLayout batch DRC on a GDS file, distinguishing it from other EDA tools like LVS or extraction. It also specifies the default smoke deck behavior versus custom PDK decks, making the purpose unambiguous.

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 explicitly states when to use the default mode versus passing a deck_file for real PDK rules, and explicitly says 'Does not do LVS; use lvs_netgen for netlist comparison,' which provides clear direction and prevents misuse. It also implies that gds_info or gds_stream_out are separate tools for other tasks.

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