Attempts to create a schematic primitive attribute; however, attribute primitives do not support creation, so the call has no effect and returns undefined.
sch_PrimitiveAttribute.create() -> undefined
创建属性
remarks: 属性图元不支持新建，本接口调用将不会有任何效果
returns: undefined
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | 按官方签名顺序排列的JSON参数数组 | |
| windowId | No | 目标EDA窗口ID；省略时使用当前活动窗口 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the behavior: '属性图元不支持新建' (primitive attribute does not support creation) and '本接口调用将不会有任何效果' (this interface call will have no effect). It also states the return value is 'undefined'. No annotations are provided, so the description carries the full burden and does so exceptionally well, being completely transparent about the no-op nature.
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, containing only the essential information: the function signature, the Chinese description of the no-op behavior, and the return type. It is well-structured with clear sections (remarks, returns) and avoids redundancy, though the first line is redundant with the title.
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 that performs no action, the description is complete: it states the effect (none), the return value (undefined), and the reason (unsupported). It does not explain why an agent might invoke it or warn against usage, but that is not essential for a no-op. The schema covers parameter details, so nothing critical is missing.
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% for the two parameters (args and windowId), and the schema already describes their purpose. The description adds no additional parameter semantics, so the baseline of 3 applies as the schema does all the work without needing further explanation.
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 '创建属性' (create attribute) with the function signature 'sch_PrimitiveAttribute.create()', clearly identifying the resource and verb. However, it immediately clarifies that the call will have no effect ('本接口调用将不会有任何效果'), making the actual purpose a no-op. It does not differentiate from sibling create tools like eda_sch_primitive_attribute_create_net_label, but the core purpose is comprehensible.
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?
No guidance is given on when to use this tool or when to avoid it. It only states that the call has no effect, which implicitly suggests it should not be used, but there is no explicit direction or alternative recommendation. The description fails to offer any usage context or selection criteria relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.