Skip to main content
Glama

render_map

Export the current QGIS map view to an image file with customizable dimensions for sharing or documentation purposes.

Instructions

Render the current map view to an image file with the specified dimensions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
widthNo
heightNo

Implementation Reference

  • Core handler implementing map rendering using QGIS QgsMapSettings and QgsMapRendererParallelJob to capture the current map canvas extent and save as image.
    def render_map(self, path, width=800, height=600, **kwargs):
        """Render the current map view to an image"""
        try:
            # Create map settings
            ms = QgsMapSettings()
            
            # Set layers to render
            layers = list(QgsProject.instance().mapLayers().values())
            ms.setLayers(layers)
            
            # Set map canvas properties
            rect = self.iface.mapCanvas().extent()
            ms.setExtent(rect)
            ms.setOutputSize(QSize(width, height))
            ms.setBackgroundColor(QColor(255, 255, 255))
            ms.setOutputDpi(96)
            
            # Create the render
            render = QgsMapRendererParallelJob(ms)
            
            # Start rendering
            render.start()
            render.waitForFinished()
            
            # Get the image and save
            img = render.renderedImage()
            if img.save(path):
                return {
                    "rendered": True,
                    "path": path,
                    "width": width,
                    "height": height
                }
            else:
                raise Exception(f"Failed to save rendered image to {path}")
                
        except Exception as e:
            raise Exception(f"Render error: {str(e)}")
  • MCP server tool handler for render_map, which proxies the command to the QGIS plugin server via socket connection.
    @mcp.tool()
    def render_map(ctx: Context, path: str, width: int = 800, height: int = 600) -> str:
        """Render the current map view to an image file with the specified dimensions."""
        qgis = get_qgis_connection()
        result = qgis.send_command("render_map", {"path": path, "width": width, "height": height})
        return json.dumps(result, indent=2)
  • Registration of socket command handlers in QGIS plugin server, mapping 'render_map' to its handler method.
    handlers = {
        "ping": self.ping,
        "get_qgis_info": self.get_qgis_info,
        "load_project": self.load_project,
        "get_project_info": self.get_project_info,
        "execute_code": self.execute_code,
        "add_vector_layer": self.add_vector_layer,
        "add_raster_layer": self.add_raster_layer,
        "get_layers": self.get_layers,
        "remove_layer": self.remove_layer,
        "zoom_to_layer": self.zoom_to_layer,
        "get_layer_features": self.get_layer_features,
        "execute_processing": self.execute_processing,
        "save_project": self.save_project,
        "render_map": self.render_map,
        "create_new_project": self.create_new_project,
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool renders to an image file but doesn't disclose critical traits: whether it overwrites existing files, requires specific permissions, has performance implications (e.g., large dimensions slowing down), or what happens on failure. For a tool with 3 parameters and no annotations, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads the core action ('Render the current map view') and key details ('to an image file with the specified dimensions'). There is no wasted text, and it directly communicates the tool's function without redundancy.

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

Completeness2/5

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

Given the complexity (a rendering tool with file output), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't address what the output looks like (e.g., image format, success/failure indicators), error conditions, or dependencies on other tools (e.g., 'load_project'). For a tool that modifies files, more context is needed.

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 mentions 'specified dimensions,' which hints at the 'width' and 'height' parameters, and 'image file' implies the 'path' parameter for output location. However, it doesn't explain parameter meanings beyond this (e.g., path format, dimension constraints, defaults). The description adds some value but doesn't fully cover the 3 undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Render') and resource ('current map view'), specifying the output format ('image file') and mentioning key parameters ('specified dimensions'). It distinguishes itself from siblings like 'save_project' or 'get_project_info' by focusing on visual rendering rather than project management or data retrieval.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a loaded project or active map), exclusions, or comparisons to sibling tools like 'execute_processing' for other rendering tasks. Usage is implied only by the action described, with no explicit context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/syauqi-uqi/qgis_mcp_modify1'

If you have feedback or need assistance with the MCP directory API, please join our Discord server