Skip to main content
Glama

export_map

Render the active QGIS map to a PNG or JPG image, optionally defining extent, width, and height for custom map outputs.

Instructions

Render the map to an image (png/jpg). extent=[xmin,ymin,xmax,ymax] in project CRS; default = canvas. / რუკის ექსპორტი.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
widthNo
extentNo
heightNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, but it does disclose real behavior: supported formats (png/jpg) and that extent is interpreted in project CRS with a canvas default. It omits whether the file is overwritten, whether the project must be loaded/GUI open, and what the tool returns.

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

Conciseness3/5

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

Front-loaded and short, with the key constraint (extent format) placed after the primary purpose. However, the trailing Georgian translation ' / რუკის ექსპორტი.' merely restates the purpose and earns no place for an agent consuming the definition.

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 4-parameter file-writing tool with no annotations and no output schema, the description covers purpose and extent semantics but is silent on the write side effects (file creation/overwrite at path) and on the return value, leaving gaps an agent would have to discover empirically.

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 0%, so the description must compensate. It does explain the one non-obvious parameter well ('extent=[xmin,ymin,xmax,ymax] in project CRS; default = canvas'), which adds real meaning beyond the bare anyOf array, but path, width and height remain entirely unexplained (path format/location especially).

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 and resource: 'Render the map to an image (png/jpg)'. No sibling tool performs map exporting (run_pyqgis and headless_command are generic execution paths), so the agent can identify it without ambiguity.

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?

The description notes that extent defaults to the canvas, which is a useful behavioral default, but it gives no when-to-use guidance and never contrasts itself with the generic run_pyqgis or headless_command siblings that could also produce output files.

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