easyeda-mcp-pro

Capture canvas region image

easyeda_canvas_capture_region

Read-only

Capture a specific rectangular canvas region as a PNG by zooming to it; oversized images are downsampled without cropping to keep the full area.

Instructions

Zoom to a rectangular document/canvas region and capture it as PNG. This moves the visible viewport. Oversized PNGs are downsampled without cropping, preserving the complete requested region.

Input Schema

TableJSON Schema

Name	Required	Description
`top`	Yes	First vertical edge in document/canvas coordinates.
`left`	Yes	First horizontal edge in document/canvas coordinates.
`right`	Yes	Second horizontal edge; either edge order is accepted.
`tabId`	No
`bottom`	Yes	Second vertical edge; either edge order is accepted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`captured`	Yes
`file_name`	No
`mime_type`	No
`byte_length`	No
`downsampled`	No
`image_base64`	No
`not_available`	No
`image_dimensions`	No
`payload_budget_bytes`	No
`original_image_dimensions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 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"

addedOutput schema / properties / downsampled
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / image_dimensions

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "height": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    "width": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "width",
+    "height"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / original_image_dimensions

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "height": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    },
+    "width": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "width",
+    "height"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / payload_budget_bytes

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}

Addedv0.19.1Jul 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds two behavioral facts that annotations do not carry: the call mutates viewport state ('This moves the visible viewport'), which explains the idempotentHint=false, and oversized results are downsampled rather than cropped, so the requested region is preserved. It stops short of stating any size threshold or resolution cap for the downsampling.

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?

Three short sentences, each carrying a distinct fact (what it does, the viewport side effect, the downsampling guarantee), with the core action front-loaded. No filler or repetition of the title.

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

Completeness4/5

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

For a capture tool with an output schema to describe the returned image, the description covers action, side effect, and result-fidelity behavior adequately. The only remaining gap is how the tab scope (tabId) interacts with the capture, which neither schema nor description explains.

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 80% and the coordinate parameters are already documented in the schema (including edge-order tolerance); the description adds no coordinate semantics of its own. The undocumented tabId remains unexplained in both places, so the baseline 3 holds.

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 precise verb+resource+output format ('Zoom to a rectangular document/canvas region and capture it as PNG'), which cleanly separates it from the sibling easyeda_canvas_capture (full canvas) and easyeda_canvas_locate. An agent can distinguish it from every other canvas/board tool 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 Guidelines3/5

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

Usage context is implied by the region-capture framing, but there is no explicit when-to-use-vs-alternatives guidance: nothing says to prefer easyeda_canvas_capture for whole-canvas shots or easyeda_canvas_locate for coordinate lookup. The viewport-move warning is a helpful hint but not routing guidance.

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

Deploy Server