easyeda-mcp-pro

Create net flag

easyeda_schematic_create_net_flag

Place a named net flag, generic label, or power/ground symbol on an EasyEDA schematic to label VCC, GND, or test nets and bind flags to pins.

Instructions

Create a named net flag/label. With identification (Power/Ground/AnalogGround/ProtectGround) it places a power-flag symbol binding to a coincident pin (use for VCC/GND). Without it, a generic net label — cosmetic only; connect pins with add_wire stubs sharing one netName.

Input Schema

TableJSON Schema

Name	Required	Description
`x`	Yes	X coordinate on the schematic canvas
`y`	Yes	Y coordinate on the schematic canvas
`netName`	Yes	The net name to assign (e.g. VCC, GND, TEST_NET)
`rotation`	No	Rotation in degrees (0, 90, 180, 270)
`projectId`	Yes	The project/schematic ID
`confirmWrite`	Yes	Must be the literal boolean true (not the string "true") to allow this write.
`identification`	No	Power-flag identification. When set, places an EasyEDA power/ground flag symbol of this type. When omitted, places a generic named net label instead.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.19.2Oct 2, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed2 schema fields changedv0.19.1Jul 15, 2026

addedInput schema / properties / confirmWrite / description

Added value: +"Must be the literal boolean true (not the string \"true\") to allow this write."

addedInput schema / properties / identification

Added value: +{
+  "description": "Power-flag identification. When set, places an EasyEDA power/ground flag symbol of this type. When omitted, places a generic named net label instead.",
+  "enum": [
+    "Power",
+    "Ground",
+    "AnalogGround",
+    "ProtectGround"
+  ],
+  "type": "string"
+}

First observedv0.19.0Jul 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only flag readOnlyHint=false and idempotentHint=false. The description adds real behavioral context beyond that: a power flag binds to a coincident pin, whereas a generic label is cosmetic-only and does not electrically connect. It does not mention the confirmWrite gate, but that is documented in the schema.

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

Conciseness5/5

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

Two dense sentences with the default case and the branching case front-loaded. Every clause carries meaning (mode, symbol type, binding behavior, cosmetic caveat, alternative).

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

Completeness5/5

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

With an output schema present and 100% schema coverage, the description need only cover mode selection and the cosmetic-connectivity gotcha, both of which it handles. Nothing an agent needs to invoke it correctly is missing.

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%, so both `identification` and the coordinate/name params are already documented. The description restates the identification semantics (power-flag vs generic label) that the schema's own description already captures, so it adds little beyond the baseline.

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

Purpose5/5

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

States a specific verb+resource (create a named net flag/label) and cleanly distinguishes its two operating modes by the presence or absence of `identification`. An agent can tell this apart from siblings like add_wire or create_net_port without opening a schema.

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

Usage Guidelines5/5

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

Explicitly conditions usage: use `identification` with VCC/GND power flags pinning to a coincident pin, and without it a cosmetic label. It also names the alternative path (add_wire stubs sharing one netName) for actually connecting pins.

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

Deploy Server