eda_sch_document_get_primitive_at_point

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

With no annotations, the description carries the behavioral burden. It states that the tool returns a Promise resolving to ISCH_Primitive or undefined, and explicitly mentions that undefined is returned when no primitive is found at the point. The analogy to mouse click hints at behavior, but it does not disclose potential topmost-priority or coordinate-system details.

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 moderately concise, front-loading the signature and core action. It includes Chinese and English text, some redundancy between the main description and remarks, but overall it is not excessively verbose and each part adds context.

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 explains the return value and undefined case, but it omits important context such as the coordinate system/units (e.g., mm or mil) and behavior when multiple primitives overlap at the same point. These gaps could lead to incorrect usage, though the tool's core purpose is clear.

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 only describes 'args' and 'windowId' generically. The description provides the actual signature with x and y as numbers, and clarifies that args is a JSON array in official signature order. This adds meaning beyond the schema, which is crucial for the agent to construct correct arguments.

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 the tool gets the primitive at a coordinate point, with a specific method signature (getPrimitiveAtPoint(x,y)). It is distinct from siblings like get_primitives_in_region or get_primitive_by_primitive_id, so an agent can differentiate it.

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 remark that it is similar to a front-end mouse click provides context, but it does not explicitly mention when to use this versus alternatives like get_primitives_in_region or get_primitive_by_primitive_id. Usage is implied rather than explicitly guided.

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