eda_sch_document_auto_layout

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 states the operation (auto layout) and the default behavior (all components if no params), but it doesn't disclose whether this modifies the document irreversibly, whether it requires a specific document type to be active, whether it can be undone, or what the returned '自动布局结果' (auto layout result) contains. For a mutation-like operation with zero annotation coverage, this is a significant gap.

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 compact: a TypeScript signature, a two-character Chinese phrase, a remark, and a returns line. It's not bloated, but the structure is a bit disjointed—the Chinese phrase '自动布局' is redundant with the name, and the returns line '自动布局结果' is vague. The most useful information (default behavior) is in the remark, which is not front-loaded.

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 tool with no annotations, no output schema, and a complex optional props structure, the description is incomplete. It doesn't explain what the netlist and designatorDeviceTypeMap parameters do, what the return value contains, or what side effects occur. The default behavior note is helpful, but an agent would struggle to know how to construct the props correctly or interpret the result.

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 100%, so the schema already documents the two parameters (args array and windowId). The description's TypeScript signature adds some meaning by showing the props structure (uuids, netlist, designatorDeviceTypeMap), but it doesn't explain the semantics of these fields beyond their names. The remark about no-params behavior adds value. Baseline 3 is appropriate since the schema does the heavy lifting.

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: 'sch_Document.autoLayout' performs automatic layout on schematic document components. The Chinese remark '自动布局' (auto layout) reinforces the purpose. It doesn't explicitly differentiate from sibling tools like eda_pcb_document_auto_layout, but the name and description make the schematic context clear.

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 includes a remark: '如不传入任何参数，将对所有器件进行自动布局' (if no parameters are passed, all components will be auto-laid-out). This gives a clear usage condition for the default case. However, it doesn't explain when to use this tool versus alternatives like eda_pcb_document_auto_layout or eda_sch_document_auto_routing, nor does it mention prerequisites like having a schematic document open.

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