Export schematic or PCB canvas image

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so safety is covered. The description adds useful rendering context (high resolution, vector vs raster, transparent background, layer visibility), but it omits the behaviorally important question of whether the output is written to a filesystem path or returned inline, which matters for a non-idempotent export.

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?

A single front-loaded sentence with the verb and resource first, followed by the capability modifiers. Every clause carries information and there is no filler, though the trailing list of options is somewhat dense and mirrors schema parameters.

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?

With 9 parameters and no output schema, the description should explain what the call returns or where the artifact lands, and it does not — an agent cannot tell whether it gets a file path, a base64 payload, or a URL. It also does not mention timeoutMs or the default 300 dpi / png behavior, so material gaps remain for a fairly complex tool.

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 89%, so the schema already documents dpi, format, layers, transparentBackground, and the rest. The description still adds meaning the schema does not: it clarifies that layer selection relates to the PCB layer stack, that scaling applies to raster output, and that vector output (SVG) is supported. The only untouched parameter is timeoutMs, so this is slightly above baseline.

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?

States a specific verb and resource ('Exports a high-resolution visual rendering or vector graphic... of the active schematic sheet or PCB layer stack') and names the concrete output formats. It is clear what the tool produces, but it never distinguishes itself from siblings that also produce document output, such as easyeda_export_pdf, easyeda_render_document_view, or easyeda_schematic_snapshot.

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 phrase 'active schematic sheet or PCB layer stack' implies the operating context, and the mention of PNG/SVG/JPG implicitly signals a raster/vector-image use case rather than a print/PDF one. However, there is no explicit when-to-use or when-not-to-use guidance and no routing to the competing export/render siblings.

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