QGIS MCP Server

Undo Edits

undo_edits

Revert recent edit operations on a QGIS layer using its own undo stack and return how many steps were actually undone. Specify the layer and an optional step count.

Instructions

Undo the last edit operations on a layer (its own undo stack). Returns how many steps were actually undone.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "layer_id": "<layer_id>"
    },
    "name": "undo_edits"
  }
}

Input Schema

Name	Required	Description	Default
`steps`	No
`layer_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

B3.4/5.0

Behavior3/5

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

The description reveals that it returns the actual number of steps undone and that it operates on the layer's own undo stack. However, it does not disclose side effects, permission needs, or behavior when no edits are available, which would be valuable given the lack of annotations.

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 sentences, front-loaded with the action, no unnecessary words. Efficient and readable.

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?

For a simple undo tool, the description is adequate but lacks edge-case behavior (e.g., no edits to undo, invalid or negative steps, interaction with editing sessions). Since there is no output schema, mentioning the return count helps but more details would improve completeness.

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?

With 0% schema description coverage, the description must compensate but does not explicitly explain the 'layer_id' or 'steps' parameters. The phrase 'last edit operations' and 'how many steps' imply the 'steps' parameter, but no direct mapping or details are given.

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 clearly states the action (undo), the resource (layer), and the scope (its own undo stack), distinguishing it from siblings like redo_edits or rollback_edits. The return value is also specified.

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 explicit guidance on when to use this tool versus alternatives. It implies usage for undoing layer edits but does not mention when not to use it or how it differs from rollback_edits or redo_edits.

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

Deploy Server