Skip to main content
Glama
mayjack0312
by mayjack0312

eda_sch_primitive_attribute_create_net_label

Create a schematic net label at specified x, y coordinates with a given net name. Use this to programmatically add net labels for wiring and net identification.

Instructions

sch_PrimitiveAttribute.createNetLabel(x: number, y: number, net: string) -> Promise<ISCH_PrimitiveAttribute | undefined> 创建网络标签 remarks: ADD since EDA v4 returns: 网络标签属性图元

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNo按官方签名顺序排列的JSON参数数组
windowIdNo目标EDA窗口ID;省略时使用当前活动窗口

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses the return type (Promise<ISCH_PrimitiveAttribute | undefined>) and that it is ADD since EDA v4, but it does not explain side effects, coordinate system/units, whether the net must already exist, or what happens on failure (undefined). For a creation tool, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: a signature line, a short Chinese summary, and two remarks lines. It front-loads the essential call signature. The Chinese-only summary ('创建网络标签') is redundant with the English name but the signature and remarks add value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with no annotations and no output schema, the description is incomplete. It lacks coordinate/unit context, net existence requirements, error behavior, and any mention of the windowId parameter's role. The return type is mentioned but the meaning of 'undefined' is not explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the two wrapper parameters (args array and windowId), but the actual function parameters (x, y, net) are only listed in the description signature without type details or semantics. The description adds the parameter names and order, which is useful, but it doesn't explain units, coordinate origin, or net name constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('create') and resource ('net label' / 网络标签) with a clear signature. It is distinguishable from siblings like eda_sch_primitive_attribute_create (generic attribute) and eda_sch_primitive_component_create_net_flag (net flag), though it doesn't explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like eda_sch_primitive_component_create_net_flag or eda_sch_primitive_attribute_create. The context implies it is for creating a net label primitive, but there are no explicit conditions, prerequisites, or exclusions.

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

Deploy Server

Other Tools