eda_sch_netlist_get_netlist

Does 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 does mention '[已弃用]' (deprecated), which is valuable and signals the agent to prefer alternatives. However, it fails to disclose what the returned string contains (e.g., format, scope: current sheet vs. project), whether it depends on a currently open schematic, or why it is deprecated and which sibling should be used instead.

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 very short and front-loads the signature, return type, and Chinese purpose in a compact form. The '[已弃用]' deprecation marker is clear. It loses one point for mixing signature syntax and Chinese without any plain-language explanation, but every line carries information and there is no padding.

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 deprecated tool with no annotations and no output schema, the description is incomplete. An agent cannot tell what netlist scope is returned, what format it has, what the optional type argument means, which document is targeted, or which non-deprecated sibling to call instead. The existence of multiple netlist-related siblings (`eda_sch_manufacture_data_get_netlist_file`, `eda_pcb_net_get_netlist`) makes this incompleteness harmful because the agent may mistake this tool for the correct one.

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% per context signals, but the schema only describes `args` as a JSON array and `windowId` as an optional window ID. The description's type signature mentions `type?: ESYS_NetlistType`, showing one optional enum-like parameter, but it does not explain what values `ESYS_NetlistType` accepts, what the 'default' behavior is when omitted, or how to pass it through `args`. With only placeholder schema items and no enum list, the description fails to compensate for the lack of actionable parameter meaning.

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 the verb 'get' and resource 'netlist' in the signature line 'sch_Netlist.getNetlist(type?: ESYS_NetlistType) -> Promise<string>', and the Chinese '获取网表' (get netlist) clarifies the action. However, it does not explain what a netlist is, what format it takes (e.g., string content), or how it differs from the nearby sibling `eda_sch_manufacture_data_get_netlist_file` and `eda_pcb_net_get_netlist`. The clear resource and action elevate it above a tautology, but lack of differentiation keeps it at a 3.

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 guidance on when to use this tool versus alternatives. Sibling tools like `eda_sch_manufacture_data_get_netlist_file`, `eda_sch_manufacture_data_get_simulation_netlist_file`, and `eda_pcb_net_get_netlist` exist, but the description does not mention them or state the intended use context (e.g., retrieving the current schematic netlist in-memory vs. generating a file export). There is also no mention of the `windowId` parameter or which document it applies to.

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