eda_sch_primitive_get_primitives_by_primitive_id

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

Annotations are absent, so the description must carry behavioral disclosure. It only mentions the return type (Promise<Array<ISCH_Primitive>>) and that all properties are returned, but does not describe potential errors (e.g., missing IDs), whether it is a read-only operation, or any side effects. This is minimal for a tool with no 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, consisting of a signature line and two short Chinese sentences. It is front-loaded with the function signature and provides the core purpose without unnecessary detail. However, it lacks a clear structure that separates purpose, usage, and returns.

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 the tool's simplicity and the absence of an output schema, the description should clarify the expected return structure and differentiate it from the singular getter. It does not mention how to handle multiple IDs in the args array, error cases, or whether the windowId is required. This leaves the agent with gaps in correctly invoking the tool.

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?

The schema describes both args (a generic JSON parameter array in official signature order) and windowId (target EDA window), providing 100% coverage. The description adds the function signature, which clarifies that the main argument is an array of string IDs, but it does not explicitly explain how to map the ids into the args array (e.g., as the first element). This adds some meaning beyond the schema but leaves room for 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 retrieves all properties of primitives by their IDs ("获取指定所有 ID 的图元的所有属性"), and the function signature indicates it takes an array of string IDs. However, it does not explicitly contrast with the singular sibling tool (eda_sch_primitive_get_primitive_by_primitive_id), though the name and plural 'primitives' imply it handles multiple IDs.

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?

There is no guidance on when to use this tool versus alternatives. The description only states what it does; it does not mention scenarios where the singular getter or other primitive retrieval tools would be more appropriate, nor does it list exclusions or prerequisites.

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