The geoanalisis-mcp server enables reading, analyzing, and visualizing vector geospatial data, integrating with Claude Desktop. It supports FileGDB, Shapefile, GeoJSON, GeoPackage, KML, and any GDAL/OGR-compatible format.
list_layers: List all layers in a spatial file, including geometry type, feature count, and CRS.
get_layer_schema: Retrieve a layer's full schema — fields/types, bounding box, CRS (EPSG code + WKT), and feature count.
scan_field_stats: Compute descriptive statistics per field — min/max/mean/std for numeric fields; unique counts and value samples for categorical fields.
read_features: Extract features as a GeoJSON FeatureCollection, with support for SQL WHERE filters and bounding box (bbox) spatial filters.
preview_geometries: Preview geometries of the first N features in WKT format, including geometry type and individual bounding boxes.
render_map: Generate an interactive HTML map with Canvas 2D rendering, pan/zoom, click-to-inspect attributes, and thematic coloring by field. This is the primary visualization method.
export_map_image: Export a PNG map with symbology, basemap, and intelligent labeling.
export_map_cartographic: Export a full cartographic PNG layout including title, legend, scale bar, north arrow, and coordinate grid.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@geoanalisis-mcp list layers in sample.gdb"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP para lectura, análisis y cartografía de datos espaciales vectoriales, integrado con Claude Desktop. De una instrucción en lenguaje natural a un mapa profesional, sin abrir un SIG de escritorio.
Tool | Descripción |
| Lista las capas de un archivo espacial (nombre + tipo de geometría), enumeración liviana de catálogo — no abre cada capa |
| Esquema completo de UNA capa puntual: campos, tipos, bbox, CRS, feature count |
| Estadísticas descriptivas por campo (numéricos y categóricos) |
| Lee features como GeoJSON FeatureCollection con filtros WHERE y bbox; |
| Vista previa de geometrías en WKT |
| Vista rápida de UNA capa: imagen inline (garantizada en todo cliente MCP) + mapa HTML interactivo (solo en clientes que renderizan recursos HTML) |
| Mapa dinámico Leaflet (pan/zoom, clic para atributos, multicapa con toggle, basemap, leyenda, escala) + HTML de alta fidelidad en disco |
| Imagen del mapa (JPG/PNG/PDF/SVG) con basemap, simbología, leyenda, escala, norte y etiquetado |
| Plancha cartográfica formal: título, panel lateral con leyenda e índice de localización, escala gráfica, norte y grilla de coordenadas |
Capacidades transversales (compartidas por las herramientas de mapas; view_layer es deliberadamente simple y no incluye extra_layers ni basemap):
Multicapa — extra_layers superpone capas adicionales con color, estilo de línea, transparencia y etiqueta propios por capa. Cada capa extra acepta además where (filtro por atributo) y, en los exports, color_by/style para categorizarla por campo sin dividir el archivo — la leyenda muestra cada clase prefijada con el nombre de la capa.
Simbología — color_by para categorías rápidas, o style avanzado categorized / graduated (rampas de color y cortes de clase).
Basemap personalizado — basemap acepta la raíz de un ArcGIS MapServer tileado o una plantilla XYZ {z}/{x}/{y}; default Esri World Light Gray Canvas (CartoDB Positron, el default anterior, hornea la marca "API KEY REQUIRED" en los tiles desde 2026).
Filtros — where (SQL OGR) y bbox; con where la extensión del mapa se ajusta a las features filtradas.
CRS — reproyección automática a WGS84; source_crs / crs para archivos que no declaran sistema de referencia.
Etiquetado — label_by etiqueta features por campo con colocación inteligente. En export_map_image y export_map_cartographic es multicapa: cada entrada de extra_layers acepta su propio label_by, con detección de colisiones compartida (las etiquetas de la capa principal tienen prioridad). El ancla se calcula sobre la parte visible de la geometría (con where/zoom, un polígono recortado se etiqueta dentro de la vista). El reporte de salida siempre indica cuántas etiquetas se renderizaron y cuántas se omitieron (solapamiento, tamaño mínimo, fuera de vista); label_collision="none" desactiva los filtros y renderiza todas las visibles.
Formatos soportados: FileGDB (.gdb), Shapefile (.shp), GeoJSON, GeoPackage (.gpkg), KML y cualquier formato vectorial compatible con GDAL/OGR.
Related MCP server: Excel Analytics MCP Server
Requiere uv instalado.
Descarga geoanalisis-mcp-X.Y.Z.mcpb desde Releases
Ábrelo con Claude Desktop (doble clic o Configuración → Extensiones → Instalar extensión)
Listo — las dependencias se resuelven automáticamente con uv al primer arranque
Para generar el bundle desde el código fuente:
npx @anthropic-ai/mcpb pack . geoanalisis-mcp.mcpbRequiere Python ≥ 3.11 y uv.
git clone https://github.com/alexrobl/geoanalisis-mcp
cd geoanalisis-mcp
uv syncAgrega esto a tu claude_desktop_config.json:
{
"mcpServers": {
"geoanalisis": {
"command": "/ruta/al/repo/.venv/bin/geoanalisis-mcp"
}
}
}Petición del usuario | Herramienta |
"Muéstrame la capa", "mapa básico", vista rápida |
|
Mapa dinámico/interactivo, varias capas, basemap, HTML como archivo |
|
Imagen estática (PNG/JPG/PDF/SVG) |
|
Plancha o producto cartográfico formal |
|
Vista rápida de una sola capa. Devuelve dos representaciones, sin detectar el cliente:
Imagen inline (JPEG) — sin basemap/escala/norte, con auto-encuadre y leyenda. Es la garantía real de visibilidad: se muestra en cualquier cliente MCP, incluyendo Claude Desktop/Cowork.
Mapa HTML interactivo — Leaflet vectorial con grilla de coordenadas, pan/zoom, popups de atributos y escala. Solo se ve inline en clientes que renderizan recursos text/html como iframe (claude.ai). En clientes que no lo hacen (Cowork/Claude Desktop) llega como texto/JSON crudo — se puede ignorar, no indica un problema con los datos.
No escribe archivos a disco.
Genera un mapa dinámico HTML con Leaflet directamente en Claude, con doble salida:
Inline en el chat — pan, zoom, clic en un feature para ver sus atributos, control de capas con toggle, leyenda, barra de escala y coordenadas del cursor. Dentro del sandbox de Claude los tiles externos están bloqueados: si en ~1.5 s no carga ningún tile se dibuja automáticamente una grilla de coordenadas como fondo de respaldo.
Alta fidelidad en disco — guarda además un HTML ({capa}_dynamic.html) donde el basemap sí carga al abrirlo en el navegador.
Los datos se embeben server-side (con muestreo uniforme si se supera limit), sin gastar contexto de la conversación.
Generan la imagen server-side con matplotlib + contextily: se muestra inline en el chat (72 DPI) y se guarda en disco en alta resolución (dpi configurable; con dpi > 150 los tiles del basemap se piden a mayor zoom para conservar la nitidez). Ambas devuelven además un reporte textual de la simbología realmente aplicada a cada capa.
export_map_image — vista rápida para revisión: leyenda, escala, norte y créditos opcionales. Salida .png, .jpg, .pdf (vectorial) o .svg.
export_map_cartographic — producto formal de entrega: título institucional, panel lateral con leyenda, convenciones e índice de localización, y franja inferior con norte, escala gráfica y fuente. Recomendado .jpg para trabajo y .pdf para entrega.
Genera un mapa cartográfico técnico con layout formal completo: título institucional · panel lateral (leyenda, convenciones, índice de localización) · franja inferior (norte, escala, parámetros/fuente). Devuelve además un reporte textual de la simbología realmente aplicada a cada capa: VERIFICARLO antes de afirmar que un color/estilo cambió.
Usar para productos formales ("mapa cartográfico", "carta", "entrega", "producto"). Para exploración rápida usar export_map_image.
Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa (None = primera capa). limit: Máximo de features (default 5000). color_by: Campo para colorear por categoría (colores automáticos). where: Filtro SQL OGR. Si se aplica, la extensión del mapa se ajusta (zoom) a las features filtradas; las capas extra quedan como contexto recortado sin ampliar la vista. bbox: Extensión [xmin, ymin, xmax, ymax] en el CRS de la capa. style: Estilo avanzado (mismo formato que export_map_image): Categorizado: {"type":"categorized","field":"X", "categories":{"A":"#e74c3c"}} Graduado: {"type":"graduated","field":"X", "ramp":"RdYlGn_r","breaks":5} output_path: Ruta de salida. .jpg para trabajo, .pdf para entrega. Default: "{capa}_cartographic.jpg" junto al archivo fuente. dpi: Resolución (default 150). Con dpi > 150 los tiles del basemap se piden a mayor zoom para mantener la nitidez (descarga más tiles: más lento). figsize: [ancho, alto] en pulgadas. Default auto-calculado. title: Título del mapa. Default: nombre de la capa. credits: Texto de fuente/créditos para el panel inferior. Ej: "Fuente: IGAC 2024 | Sistema: WGS84 EPSG:4326" label_by: Campo para etiquetar features de la capa PRINCIPAL (colocación inteligente, anclada en la parte visible de la geometría). Para etiquetar capas extra, usar la clave 'label_by' dentro de cada entrada de extra_layers. El reporte de salida SIEMPRE indica cuántas etiquetas se renderizaron y cuántas se omitieron (y por qué). label_collision: "auto" (default) descarta etiquetas solapadas o de polígonos que ocupan <0.02% de la vista; "none" renderiza TODAS las etiquetas visibles aunque se amontonen. extra_layers: Capas adicionales (mismo formato que export_map_image, incluidas las claves 'crs' para capas sin CRS definido, 'label_by' para etiquetar cada capa extra por su propio campo, 'where' para filtrarla por atributo, y 'color_by'/'style' para categorizarla sin dividir el archivo). IMPORTANTE: pasar SIEMPRE 'color' explícito y distinto por capa (matiz diferente) y 'label' descriptivo; el gris default es solo para capas de puro contexto. source_crs: CRS a asumir para la capa principal SOLO si el archivo no define uno (ej. "EPSG:3116"). Ver export_map_image. basemap: URL de un basemap alternativo al default Esri World Light Gray Canvas: raíz de un ArcGIS MapServer con cache de tiles en Web Mercator o plantilla XYZ con tokens {z}/{x}/{y}. Ver export_map_image. markersize: Tamaño del marcador para capas de puntos, en pt². Default None = automático según número de puntos y ancho del lienzo, con halo blanco. Ver export_map_image.
| Name | Required | Description | Default |
|---|---|---|---|
| dpi | No | ||
| bbox | No | ||
| path | Yes | ||
| layer | No | ||
| limit | No | ||
| style | No | ||
| title | No | ||
| where | No | ||
| basemap | No | ||
| credits | No | ||
| figsize | No | ||
| color_by | No | ||
| label_by | No | ||
| markersize | No | ||
| source_crs | No | ||
| output_path | No | ||
| extra_layers | No | ||
| label_collision | No | auto |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden and does so thoroughly. It discloses the textual symbology report, label collision behavior, dpi/tile download implications, extent adjustment with filters, and the requirement to use explicit distinct colors for extra layers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but warranted given 18 parameters. It is well-structured with an Args list, inline JSON examples, and clear warnings. Key behavioral notes are front-loaded before the parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high parameter count and complexity, the description is complete: it covers defaults, output behavior, cautionary notes, and cross-references to sibling tools. The reported output schema and textual report are also mentioned, leaving little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates comprehensively by documenting all 18 parameters with defaults, ranges, formats, and examples. It adds meaning far beyond bare JSON schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Genera un mapa cartográfico técnico con layout formal completo') and explicitly contrasts itself with export_map_image for quick exploration. It clearly identifies the resource and output type, so an agent can distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly states when to use this tool ('Usar para productos formales') and when not to ('Para exploración rápida usar export_map_image'). It also references export_map_image for shared parameters, giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera una imagen del mapa con basemap Esri World Light Gray Canvas mostrada INLINE en el chat y guardada en disco en alta resolución. Devuelve además un reporte textual de la simbología realmente aplicada a cada capa: VERIFICARLO antes de afirmar que un color/estilo fue cambiado.
Args:
path: Ruta al archivo o directorio espacial.
layer: Nombre de la capa (None = primera capa).
limit: Máximo de features (default 5000).
color_by: Campo para colorear por categoría con colores automáticos.
Alternativa simple a style.
where: Filtro SQL OGR. Si se aplica, la extensión del mapa se ajusta
(zoom) a las features filtradas; las capas extra quedan como
contexto recortado sin ampliar la vista.
bbox: Extensión [xmin, ymin, xmax, ymax].
style: Estilo avanzado:
Categorizado: {"type": "categorized", "field": "Tipo",
"categories": {"A": "#e74c3c", "B": "#2ecc71"}}
Graduado: {"type": "graduated", "field": "Tiempo",
"ramp": "RdYlGn_r", "breaks": 5}
breaks = int (clases iguales) o lista de cortes explícitos.
Rampas útiles: RdYlGn_r, YlOrRd, Blues, viridis, plasma.
"field" en style tiene precedencia sobre color_by.
output_path: Ruta completa de salida incluyendo extensión.
.png = PNG lossless · .jpg = JPEG · .pdf = PDF vectorial · .svg = SVG.
Si None guarda "{capa}_map.jpg" junto al archivo fuente.
legend: Mostrar leyenda (default True).
dpi: Resolución en DPI para disco (default 150). La imagen inline del chat
siempre usa 72 DPI para mantener el tamaño manejable.
Con dpi > 150 los tiles del basemap se piden a mayor zoom
para mantener la nitidez (descarga más tiles: más lento).
figsize: Tamaño [ancho, alto] en pulgadas, ej. [14, 8.5] para A4 horizontal.
Default [10, 6].
scalebar: Mostrar barra de escala en esquina inferior izquierda (default True).
north_arrow: Mostrar flecha de norte en esquina superior izquierda (default True).
credits: Texto de créditos en pie de mapa,
ej. "Fuente: INEGI 2024 | Elaborado con GeoAnalisis MCP".
label_by: Campo para etiquetar cada feature de la capa PRINCIPAL (anclaje
dentro de la parte visible de la geometría). Para etiquetar capas
extra, usar la clave 'label_by' dentro de cada entrada de
extra_layers. El reporte de salida SIEMPRE indica cuántas
etiquetas se renderizaron y cuántas se omitieron (y por qué).
label_collision: "auto" (default) descarta etiquetas que se solapan o cuyo
polígono ocupa <0.02% de la vista; "none" desactiva ambos
filtros y renderiza TODAS las etiquetas visibles aunque se
amontonen. Usar "none" cuando el usuario pida ver todas.
extra_layers: Capas adicionales a superponer sobre el basemap, en orden ascendente
(primera entrada = capa más baja). Cada capa aparece en la leyenda.
IMPORTANTE: pasar SIEMPRE 'color' explícito y distinto por capa
(matiz diferente); el gris default es solo para puro contexto.
Cada entrada es un dict con:
path (str, requerido), layer (str), limit (int, default 10000),
where (str; filtro SQL OGR aplicado a ESA capa,
ej. "INTERVALO <= 10"),
color_by (str; campo de ESA capa para colorear por categorías
— un solo archivo con clases, sin dividirlo en varios),
style (dict; simbología avanzada de ESA capa, mismo formato
que el style de la capa principal: type "categorized"
con categories, o "graduated" con field/ramp/breaks.
La leyenda muestra cada clase prefijada con el nombre
de la capa),
color (str; ej. "#e74c3c". Default "#888" gris. Ignorado si
se pasa color_by o style),
alpha (float; default 0.9 líneas, 0.7 resto),
linewidth (float; default 1.5 líneas, 0.5 resto),
linestyle (str, default "-"; "--" discontinua, ":" punteada),
edgecolor (str, default "none"), markersize (float, default 4),
label (str; nombre en leyenda, default nombre de capa/archivo),
label_by (str; campo de ESA capa para etiquetar sus features —
colocación inteligente compartida con la capa principal:
las etiquetas de la principal tienen prioridad),
zorder (int; opcional, para dibujar sobre la capa principal),
crs (str; ej. "EPSG:9377". Solo si el archivo NO define CRS:
se asume ese. Si define uno, se respeta el del archivo).
Cualquier otra clave se ignora y se reporta en el texto de salida.
source_crs: CRS a asumir para la capa principal SOLO si el archivo no define
uno (ej. "EPSG:3116"). Sin esto, una capa sin CRS con bounds
lon/lat se asume EPSG:4326; con bounds proyectados se rechaza
indicando cómo corregir. Todas las capas se reproyectan
automáticamente a Web Mercator para el render.
basemap: URL de un basemap alternativo al default Esri World Light Gray Canvas.
Acepta la raíz de un servicio ArcGIS MapServer con cache de
tiles en Web Mercator (ej. "https://host/arcgis/rest/services/
Nombre/MapServer": se valida el cache y se usa la plantilla
/tile/{z}/{y}/{x}, con atribución del copyrightText) o una
plantilla XYZ con tokens, ej. "https://tile.host/{z}/{x}/{y}.png".
Si los tiles fallan al descargar se usa Esri World Light Gray Canvas como
fallback y se reporta en el texto de salida.
markersize: Tamaño del marcador para capas de puntos, en pt² (semántica
matplotlib; ej. 100 ≈ círculo de 3.5 mm). Default None =
automático según número de puntos y ancho del lienzo, con
halo blanco para resaltar sobre el basemap.
| Name | Required | Description | Default |
|---|---|---|---|
| dpi | No | ||
| bbox | No | ||
| path | Yes | ||
| layer | No | ||
| limit | No | ||
| style | No | ||
| where | No | ||
| legend | No | ||
| basemap | No | ||
| credits | No | ||
| figsize | No | ||
| color_by | No | ||
| label_by | No | ||
| scalebar | No | ||
| markersize | No | ||
| source_crs | No | ||
| north_arrow | No | ||
| output_path | No | ||
| extra_layers | No | ||
| label_collision | No | auto |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so extensively. It discloses inline DPI vs. disk DPI behavior, basemap fallback, automatic reprojection to Web Mercator, precedence of style over color_by, label collision handling, and that unknown extra_layers keys are ignored and reported. It even warns the agent to verify the symbology report before claiming a style changed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is necessary given 20 undocumented parameters. It is organized as a clear intro followed by a per-argument list where each line earns its place. Examples are compact and the structure is scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a complex tool with 20 parameters and no annotations. It covers output behavior, defaults, fallbacks, failure handling, and parameter interactions. Since an output schema exists, the description need not restate return structures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter includes defaults, formats, concrete examples, edge cases, and interactions, such as extra_layers ordering, source_crs fallback logic, and style dict structure. This goes far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Genera una imagen del mapa'), names the default basemap, and clarifies that the image is shown inline and saved to disk at high resolution, with a symbology report returned. It is clear and specific, but it does not explicitly contrast itself with sibling tools like render_map or export_map_cartographic, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to choose this tool over alternatives such as render_map or export_map_cartographic. It documents parameters thoroughly but does not state usage context, exclusions, or conditions under which a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene el esquema completo de una capa espacial.
Devuelve: nombre de la capa, driver GDAL, tipo de geometría, número de features, CRS (código EPSG + WKT), extensión espacial (bbox) y lista de campos con sus tipos.
Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa. Si es None usa la primera capa disponible.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| layer | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral detail (list of returned metadata) but does not disclose side effects, safety, or performance. It implies a read operation but does not state readOnly or destructive flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear paragraphs: one for purpose and return values, one for parameters. No wasted sentences, though a structured list for returns might enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata tool with 2 params and an output schema present, the description covers the main purpose, return fields, and parameter explanations. It is largely complete but could mention read-only behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema coverage, the description explains both parameters: path (path to spatial file/directory) and layer (name, default first available). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the complete schema of a spatial layer and lists return fields. However, it does not explicitly differentiate from sibling tools like list_layers or read_features, which would help an agent select correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_layers for layer listing, read_features for data). The usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todas las capas disponibles en una fuente de datos espacial.
Soporta .gdb (FileGDB), .gpkg, .shp, .geojson, .kml y cualquier formato GDAL/OGR. Devuelve por capa: nombre y tipo de geometría, vía la enumeración liviana del catálogo (no abre cada capa individualmente) — seguro incluso en FileGDBs con cientos de capas o archivos .lock/.sr.lock residuales de ediciones previas en ArcGIS, donde abrir capa por capa puede colgar el driver OpenFileGDB.
Para feature_count, CRS, bbox y campos de una capa puntual usa get_layer_schema(layer=...).
Args: path: Ruta absoluta al archivo o directorio (.gdb es un directorio).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does this well by revealing that enumeration is lightweight, does not open each layer individually, and is safe even with residual .lock/.sr.lock files. It could additionally state explicit read-only guarantees or error behavior, but the provided safety and performance context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly longer than strictly necessary because of the .lock-file explanation, but that context serves behavioral transparency and is not wasted. The main action is front-loaded, and the alternative-tool routing is placed at the end, which is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers supported formats, what is returned per layer, and when to use a sibling tool. Since an output schema exists, the return structure need not be repeated. Nothing critical is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The Args section does this: it explains that path is an absolute path, can point to a file or directory, and that .gdb is a directory. This adds meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lista todas las capas disponibles en una fuente de datos espacial.' It also differentiates itself from the sibling get_layer_schema by explicitly stating that detailed schema information belongs to that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains when to use this tool (enumeration of layers) and when to use an alternative: 'Para feature_count, CRS, bbox y campos de una capa puntual usa get_layer_schema(layer=...).' This provides explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Previsualiza las geometrías de los primeros N features como WKT.
Devuelve para cada feature: índice, tipo de geometría, WKT de la geometría y su bounding box individual.
Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa (None = primera capa). limit: Número de features a previsualizar (default 5).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| layer | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses return content (index, geometry type, WKT, bounding box) and the limit-driven scope, leaving no ambiguity about the tool's read-only, non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a structured Args section with no superfluous text, front-loaded with the core purpose, achieving maximum clarity with minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return format and parameter semantics adequately for a preview tool, but lacks mention of error handling (e.g., invalid path) or performance characteristics, which would be nice for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains each parameter's role (path, layer with default null meaning first, limit with default 5), adding meaning beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('preview') and resource ('geometries of first N features as WKT'), which distinguishes it from sibling tools like read_features (full feature data) and list_layers (layer enumeration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for quick geometric previews but does not explicitly state when to prefer this over alternatives like read_features or render_map, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lee features de una capa y los devuelve como GeoJSON FeatureCollection.
Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa (None = primera capa). limit: Número máximo de features a retornar (default 10). where: Filtro SQL OGR, ej: "POBLACION > 5000 AND TIPO = 'urbano'". bbox: Filtro espacial [xmin, ymin, xmax, ymax] en el CRS de la capa. geometry: Representación de la geometría en la salida — clave para no agotar el límite de salida con polígonos complejos (miles de vértices): "full" (default) geometría completa. "simplified" Douglas-Peucker con simplify_tolerance. "centroid" un punto representativo dentro de cada geometría. "bbox" el rectángulo envolvente de cada feature. "none" solo atributos; agrega la propiedad "bbox" [xmin, ymin, xmax, ymax] por feature. simplify_tolerance: Tolerancia para geometry="simplified", en unidades del CRS de la capa. Default: 1/1000 del lado mayor del bbox del resultado.
Si el resultado excede el límite de tamaño de salida devuelve un error con sugerencias (reducir limit, filtrar con where/bbox, o bajar el detalle con geometry="simplified"/"centroid"/"bbox"/"none").
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| path | Yes | ||
| layer | No | ||
| limit | No | ||
| where | No | ||
| geometry | No | full | |
| simplify_tolerance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden and exceeds it. It discloses the GeoJSON output, all geometry representation modes, the default limit, the derived default for simplify_tolerance, and the error behavior with concrete suggestions when output size is exceeded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement, a per-argument breakdown, and a closing note on error handling. Every sentence adds functional value; the detail on geometry modes is dense but directly relevant to successful invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a 7-parameter tool with no annotations. It covers return format, defaults, filtering options, spatial and attribute filters, geometry simplification behavior, and the failure mode when output exceeds limits. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates thoroughly. Every parameter is explained with defaults, units, examples (e.g., the OGR SQL example for where and [xmin, ymin, xmax, ymax] for bbox), and the effect of geometry modes on output size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lee features de una capa y los devuelve como GeoJSON FeatureCollection', giving a clear verb, resource, and output format. It is unambiguous about what the tool does, but it does not explicitly contrast itself with sibling tools like preview_geometries or view_layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The primary use case is strongly implied by the first sentence and by parameter guidance such as filtering with where/bbox. However, there is no explicit statement of when to choose this tool over siblings or when not to use it, leaving tool selection partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mapa DINÁMICO interactivo con Leaflet: pan, zoom, clic para inspeccionar atributos, VARIAS capas con control on/off (extra_layers), basemap configurable, simbología categorized/graduated (style), etiquetas (label_by), leyenda, escala y coordenadas del cursor.
Úsala cuando el usuario pida un mapa dinámico/interactivo, quiera COMBINAR VARIAS capas, pida un basemap específico o quiera el mapa como archivo HTML. Para la vista rápida de UNA sola capa en el chat usa view_layer; para una imagen estática export_map_image; para un producto formal con layout export_map_cartographic. No construyas mapas a mano con pyshp/pyproj/folium/Leaflet ni artefactos — NUNCA es necesario: esta herramienta embebe los datos server-side sin gastar contexto.
Genera DOS salidas: la vista inline del chat (los tiles externos están bloqueados en el sandbox, así que dibuja una grilla de coordenadas como fondo de respaldo) y un HTML de ALTA FIDELIDAD guardado en disco, donde el basemap sí carga al abrirlo en un navegador.
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), where (filtro SQL OGR sobre ESA capa), color (IMPORTANTE: explícito y distinto por capa), alpha, linewidth, linestyle ("--" discontinua, ":" punteada), label, markersize, crs (solo si el archivo no define CRS). Para categorizar una capa extra por campo (color_by/style) usa export_map_image o export_map_cartographic. basemap: URL de basemap alternativo (raíz de ArcGIS MapServer tileado o plantilla XYZ {z}/{x}/{y}), igual que en los exports. Default Esri World Light Gray Canvas. 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".
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| path | Yes | ||
| layer | No | ||
| limit | No | ||
| style | No | ||
| where | No | ||
| basemap | No | ||
| color_by | No | ||
| label_by | No | ||
| markersize | No | ||
| source_crs | No | ||
| output_path | No | ||
| extra_layers | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses that external tiles are blocked in the sandbox so a coordinate-grid fallback is drawn, that a high-fidelity HTML is saved to disk, that data is embedded server-side to save context, and that basemaps only load outside the sandbox. It also explains auto-reprojection to WGS84 and the two-output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is highly information-dense and earns its length given 13 parameters and complex nested options. It is front-loaded with purpose and usage guidance, then uses a structured Args list. Every sentence adds decision-relevant detail rather than fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 13-parameter tool with one required parameter, nested objects, sandbox caveats, and multiple output artifacts, the description is remarkably complete. It covers inputs, output behavior, file paths, basemap constraints, and alternatives, while the presence of an output schema removes the need to describe return values in prose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does: every parameter receives meaningful semantics, including defaults, formats, precedence rules ('field' tiene precedencia sobre color_by), SQL filter behavior, bbox coordinate order, and detailed nested fields for extra_layers. This goes far beyond the bare input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: rendering an interactive dynamic Leaflet map from a spatial file or directory, with detailed capabilities (multiple layers, basemap, symbology, labels). It also explicitly distinguishes itself from siblings such as view_layer, export_map_image, and export_map_cartographic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Úsala cuando el usuario pida un mapa dinámico/interactivo, quiera COMBINAR VARIAS capas, pida un basemap específico o quiera el mapa como archivo HTML') and names alternatives with their conditions. It also tells the agent not to hand-build maps with low-level libraries, which is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcula estadísticas descriptivas por campo en una capa espacial.
Campos numéricos → min, max, media, desviación estándar, nulos. Campos de texto/categoría → conteo de únicos, muestra de valores, nulos.
Args: path: Ruta al archivo o directorio espacial. layer: Nombre de la capa (None = primera capa). fields: Lista de campos a analizar. None = todos los campos no-geometría. max_features: Límite de features a leer para calcular estadísticas (default 50000).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| layer | No | ||
| fields | No | ||
| max_features | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides basic behavioral information (numeric vs text stats, max_features limit) but lacks disclosure of side effects, performance, or error conditions; since no annotations exist, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, followed by detailed stats and parameter documentation, all in a concise format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, parameters, and basic behavior; with an output schema available, it provides sufficient contextual completeness, though minor aspects like error handling are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides parameter explanations (path, layer, fields, max_features) that add meaning beyond the raw schema, though concise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes descriptive statistics per field in a spatial layer, distinguishing between numeric and text fields, and is distinct from sibling tools like get_layer_schema or read_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing field statistics but lacks explicit guidance on when to use this vs. other tools or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vista rápida de UNA capa, mostrada directamente en el chat. Úsala cuando el usuario pida "ver", "visualizar" o "mostrar" una capa, un "mapa básico" o una vista simple — sin multicapa, sin basemap y sin archivos.
Devuelve DOS representaciones de la misma vista, sin depender de detectar el cliente MCP: una IMAGEN estática (JPEG inline, sin basemap/escala/norte) que se muestra en cualquier cliente — es la garantía real de visibilidad, incluyendo Claude Desktop/Cowork, que no renderiza recursos HTML — y, además, un mapa HTML interactivo (pan/zoom, popups de atributos al clic, grilla de coordenadas de fondo) que solo se ve inline en clientes que renderizan recursos text/html como iframe (ej. claude.ai); en los que no, llega como texto/JSON crudo y debe ignorarse — no es un error de datos. NUNCA construyas esta vista a mano con HTML/folium/Leaflet ni artefactos: esta herramienta embebe los datos server-side sin gastar contexto.
Escalar a otra herramienta cuando el usuario pida más: varias capas, basemap o archivo HTML → render_map · imagen con basemap/escala/norte/ disco → export_map_image · producto formal con layout → export_map_cartographic.
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). markersize: Tamaño de puntos en pt² (semántica de los exports); default automático según cantidad de puntos.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| path | Yes | ||
| layer | No | ||
| limit | No | ||
| style | No | ||
| where | No | ||
| color_by | No | ||
| label_by | No | ||
| markersize | No | ||
| source_crs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden, and it delivers: it discloses the dual return (static JPEG plus HTML map), client-dependent rendering (Claude Desktop/Cowork vs claude.ai), and that raw HTML/JSON should be ignored rather than treated as an error. It also warns against hand-building the view and explains server-side embedding to save context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed and clearly structured: purpose, behavior, escalation routing, then Args. No filler; each paragraph and argument line carries operational information required for correct use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter dual-output tool with no annotations, the description covers what the tool does, when to choose it, what it returns, how clients render it, how to escalate, and semantics for every argument. The output schema covers return structure, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the Arg list fully compensates: each of the 10 parameters gets semantic detail beyond the schema, e.g., source_crs applies only if the file lacks a CRS and reprojects to WGS84; label_by changes tooltip behavior based on feature count; markersize is in pt² with automatic default. This is high-value parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Vista rápida de UNA capa, mostrada directamente en el chat.' It explicitly excludes multi-layer, basemap, and file cases, and names escalation siblings, so it is distinguishable from render_map/export_map_image/export_map_cartographic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger phrases ('ver', 'visualizar', 'mostrar') and exclusions ('sin multicapa, sin basemap y sin archivos'). It then names the exact sibling to escalate to for multi-layer/basemap, image with basemap/scale/north, and formal layout. This is textbook when-to-use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.10export_map_cartographic1 field changedInput schema / properties / label_collisionAdded value: +{
+ "default": "auto",
+ "title": "Label Collision",
+ "type": "string"
+}export_map_image1 field changedInput schema / properties / label_collisionAdded value: +{
+ "default": "auto",
+ "title": "Label Collision",
+ "type": "string"
+}read_features2 fields changedInput schema / properties / geometryAdded value: +{
+ "default": "full",
+ "title": "Geometry",
+ "type": "string"
+}Input schema / properties / simplify_toleranceAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Simplify Tolerance"
+}view_layerv0.2.9export_map_cartographicexport_map_imagerender_map10 fields changedInput schema / properties / basemapAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Basemap"
+}Input schema / properties / extra_layersAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Extra Layers"
+}Input schema / properties / label_byAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Label By"
+}Input schema / properties / markersizeAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Markersize"
+}Input schema / properties / output_pathAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Output Path"
+}Input schema / properties / source_crsAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Source Crs"
+}Input schema / properties / styleAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Style"
+}Output schema / $defsAdded value: +{
+ "Annotations": {
+ "additionalProperties": true,
+ "properties": {
+ "audience": {
+ "anyOf": [
+ {
+ "items": {
+ "enum": [
+ "user",
+ "assistant"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Audience"
+ },
+ "priority": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Priority"
+ }
+ },
+ "title": "Annotations",
+ "type": "object"
+ },
+ "BlobResourceContents": {
+ "additionalProperties": true,
+ "description": "Binary contents of a resource.",
+ "properties": {
+ "_meta": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Meta"
+ },
+ "blob": {
+ "title": "Blob",
+ "type": "string"
+ },
+ "mimeType": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Mimetype"
+ },
+ "uri": {
+ "format": "uri",
+ "minLength": 1,
+ "title": "Uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "uri",
+ "blob"
+ ],
+ "title": "BlobResourceContents",
+ "type": "object"
+ },
+ "EmbeddedResource": {
+ "additionalProperties": true,
+ "description": "The contents of a resource, embedded into a prompt or tool call result.\n\nIt is up to the client how best to render embedded resources for the benefit\nof the LLM and/or the user.",
+ "properties": {
+ "_meta": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Meta"
+ },
+ "annotations": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Annotations"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "resource": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/TextResourceContents"
+ },
+ {
+ "$ref": "#/$defs/BlobResourceContents"
+ }
+ ],
+ "title": "Resource"
+ },
+ "type": {
+ "const": "resource",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "resource"
+ ],
+ "title": "EmbeddedResource",
+ "type": "object"
+ },
+ "TextContent": {
+ "additionalProperties": true,
+ "description": "Text content for a message.",
+ "properties": {
+ "_meta": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Meta"
+ },
+ "annotations": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/Annotations"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "text": {
+ "title": "Text",
+ "type": "string"
+ },
+ "type": {
+ "const": "text",
+ "title": "Type",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "title": "TextContent",
+ "type": "object"
+ },
+ "TextResourceContents": {
+ "additionalProperties": true,
+ "description": "Text contents of a resource.",
+ "properties": {
+ "_meta": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Meta"
+ },
+ "mimeType": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Mimetype"
+ },
+ "text": {
+ "title": "Text",
+ "type": "string"
+ },
+ "uri": {
+ "format": "uri",
+ "minLength": 1,
+ "title": "Uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "uri",
+ "text"
+ ],
+ "title": "TextResourceContents",
+ "type": "object"
+ }
+}Output schema / properties / result / itemsAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/TextContent"
+ },
+ {
+ "$ref": "#/$defs/EmbeddedResource"
+ }
+ ]
+}Output schema / properties / result / typePrevious value: -"string"New value: +"array"v0.1.0get_layer_schemalist_layerspreview_geometriesread_featuresrender_mapscan_field_statsScored across 9 tools
Cada herramienta tiene un propósito claramente distinto: listado de capas, esquema, estadísticas, lectura de features, previsualización WKT, vista rápida, mapa dinámico, imagen estática y producto cartográfico. Las herramientas de visualización (view_layer, render_map, export_map_image, export_map_cartographic) se diferencian explícitamente por nivel de detalle, interactividad y uso final, con referencias cruzadas que guían la selección.
Todas las herramientas siguen un patrón consistente verbo_sustantivo en minúsculas y snake_case: list_layers, get_layer_schema, scan_field_stats, read_features, preview_geometries, view_layer, render_map, export_map_image, export_map_cartographic. No hay mezcla de estilos ni nombres vagos.
Con 9 herramientas, el conjunto está bien dimensionado para un servidor de análisis geoespacial: cubre el flujo completo desde exploración de datos hasta exportación de mapas, sin redundancia innecesaria ni carencias evidentes. Cada herramienta tiene un rol específico y no sobra ninguna.
El conjunto cubre integralmente el ciclo de trabajo geoespacial: descubrimiento (list_layers), inspección (get_layer_schema, scan_field_stats), extracción (read_features), previsualización (preview_geometries) y cuatro niveles de visualización/exportación adaptados a distintos contextos (vista rápida, dinámico, imagen estática, cartográfico). No se detectan vacíos relevantes para el propósito del servidor.
A collaborative substrate over your data: vector, knowledge graph, SQL, geospatial, streaming.
Generate and run high performance queries on open and private spatial data at-scale in the cloud
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
