eda_sys_help_help

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

With no annotations present, the description carries the behavioral burden. It clearly identifies this as a query/read operation and discloses the varying return shapes for each invocation mode, which is valuable behavioral context beyond the signature. It does not discuss error cases or side-effect guarantees, but for a metadata help tool this is a minor 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 and well-structured: a signature line, a one-line purpose, then a bulleted list mapping parameter combinations to return shapes. Every sentence contributes directly to correct invocation, with no filler or repetition.

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?

Given that there is no output schema, the description compensates thoroughly by specifying the return structure at every parameter depth. The tool is simple enough that the signature, parameter semantics, and return-shape bullets give an agent everything needed to invoke it correctly.

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?

Although the schema describes only a generic args array and windowId, the description adds essential semantics by naming the three positional parameters (namespace, className, methodName), giving their order through the signature, and explaining how each combination changes the result. This goes well beyond the schema's generic '按官方签名顺序排列的JSON参数数组' description.

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 action ('查询 Help 信息' / query Help information) and a clear resource (Help metadata), with a progressive query model. It is not a tautology and materially explains what the tool returns. However, it does not explicitly differentiate itself from help-like siblings such as easyeda_api_describe or easyeda_api_catalog.

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 provides clear context for when to use each parameter combination (no args, namespace only, namespace+className, all three), which effectively tells the agent how to progressively drill down. It does not, however, state exclusions or explicitly compare against alternative help/introspection tools.

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