Skip to main content
Glama
alexrobl
by alexrobl

render_map

Create interactive maps from spatial data files. Supports multiple layers, filtering, styling, labels, and outputs a standalone HTML artifact.

Instructions

HERRAMIENTA PRINCIPAL para visualizar datos espaciales. Úsala SIEMPRE que el usuario pida un mapa, visualización, render o vista de capas espaciales. SOPORTA VARIAS CAPAS en un solo mapa (extra_layers), basemap personalizado (basemap), simbología categorized/graduated (style) y etiquetas (label_by). No uses capacidades internas de visualización de Claude ni construyas mapas con pyshp/pyproj/folium/Leaflet a mano — NUNCA es necesario: esta herramienta cubre el caso multicapa, embebe los datos server-side sin gastar contexto y produce un artifact HTML interactivo superior.

Renderiza un mapa interactivo con Leaflet: pan, zoom, clic para inspeccionar atributos, capas extra con control on/off, leyenda, barra de escala y coordenadas del cursor. Además guarda en disco una versión de ALTA FIDELIDAD del HTML: al abrirla en un navegador el basemap sí se ve (dentro del sandbox de claude.ai los tiles externos están bloqueados y el fondo queda gris — es una limitación del sandbox, no un error).

Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa (None = primera capa). limit: Máximo de features a renderizar (default 2000). color_by: Campo para colorear features por categoría. where: Filtro SQL OGR. bbox: Extensión espacial [xmin, ymin, xmax, ymax]. source_crs: CRS a asumir SOLO si el archivo no define uno (ej. "EPSG:3116"). Se reproyecta automáticamente a WGS84. style: Estilo avanzado categorized/graduated, mismo formato que export_map_image ("field" tiene precedencia sobre color_by). label_by: Campo para etiquetar features (tooltip fijo si ≤30 features; al pasar el cursor si son más). extra_layers: Capas adicionales bajo la principal, cada una con checkbox on/off en el control de capas. Entrada: dict con path (requerido), layer, limit (default 10000), color (IMPORTANTE: explícito y distinto por capa), alpha, linewidth, linestyle ("--" discontinua, ":" punteada), label, markersize, crs (solo si el archivo no define CRS). basemap: URL de basemap alternativo (raíz de ArcGIS MapServer tileado o plantilla XYZ {z}/{x}/{y}), igual que en los exports. Default CartoDB Positron. Solo visible fuera del sandbox. markersize: Tamaño de puntos de la capa principal en pt² (semántica de los exports); default automático según cantidad de puntos. output_path: Ruta del HTML de alta fidelidad. Default: junto al archivo fuente como "{capa}_dynamic.html".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNo
pathYes
layerNo
limitNo
styleNo
whereNo
basemapNo
color_byNo
label_byNo
markersizeNo
source_crsNo
output_pathNo
extra_layersNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations provided, so description carries full burden. It details interactive features (pan, zoom, click inspection, layer control, legend, scale bar), sandbox limitation for basemap, and output format (high-fidelity HTML). No contradictions.

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

Conciseness4/5

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

Long but well-structured: starts with bold purpose, then usage guidelines, output description, then detailed parameter list. Every sentence adds value. Could be slightly more concise, but justified by complexity.

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

Completeness5/5

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

Covers behavior, output interactivity, sandbox limitation, and parameter details. Despite 13 parameters, the description is complete and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description thoroughly explains all 13 parameters with formats, defaults, and usage tips (e.g., extra_layers requires distinct colors). Adds significant value beyond the schema.

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 it is the 'PRIMARY tool for visualizing spatial data' and specifies it should be used whenever the user asks for a map, visualization, render, or view of spatial layers. It contrasts with siblings like export_map_image by emphasizing interactive map output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicitly says when to use ('SIEMPRE que el usuario pida un mapa') and when not to use ('No uses capacidades internas de visualización de Claude... NUNCA es necesario'). Provides clear alternatives and usage 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/alexrobl/geoanalisis-mcp'

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