easyeda-mcp-pro

List PCB components

easyeda_pcb_components

Read-onlyIdempotent

List all components on the active PCB layout in EasyEDA Pro, including designators, footprints, positions, rotations, and layers. Requires a focused PCB tab; returns an empty list if none is active.

Instructions

List components placed on the active PCB layout: primitiveId, designator, footprint identity, position/rotation/layer. Requires a focused PCB tab in EasyEDA Pro — returns an empty list (not an error) if none is active.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`projectId`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`total`	Yes
`components`	Yes
`project_id`	Yes
`not_available`	No

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"

Addedv0.19.1Jul 15, 2026

TDQS

A4/5.0

Behavior4/5

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

With readOnlyHint and idempotentHint already provided, the description adds useful behavioral context: the focused-tab prerequisite and the fact that an empty list is returned rather than an error when no PCB tab is active. It does not cover pagination or permission details beyond that.

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?

The description is front-loaded with the core action and returned fields, followed by a compact prerequisite/behavior note. It is appropriately sized with no filler sentences.

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

Completeness3/5

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

The output schema exists, so return values need not be fully explained, and the annotations cover safety traits. However, with zero schema description coverage, the missing parameter documentation (projectId, limit, offset) leaves a meaningful gap for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0% for all three parameters, and the description does not explain projectId, limit, or offset. It mentions returned fields, not input parameters, so it fails to compensate for the undocumented schema.

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?

The description states a specific verb (List) and resource (components placed on the active PCB layout), and it names the returned identity fields. It clearly distinguishes this PCB component listing from sibling tools like pcb_tracks and schematic_components by specifying 'active PCB layout'.

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

Usage Guidelines4/5

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

It gives clear usage context: the tool requires a focused PCB tab in EasyEDA Pro, and it describes the no-active-tab behavior. However, it does not explicitly compare against alternatives or state when not to use this tool.

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

Deploy Server