Skip to main content
Glama
alexrobl

geoanalisis-mcp

by alexrobl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

read_features

Read features from a spatial layer and return them as GeoJSON, using attribute and bounding box filters, with geometry options to control output size.

Instructions

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").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNo
pathYes
layerNo
limitNo
whereNo
geometryNofull
simplify_toleranceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.10
    • addedInput schema / properties / geometry
      Added value: +{
+  "default": "full",
+  "title": "Geometry",
+  "type": "string"
+}
    • addedInput schema / properties / simplify_tolerance
      Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Simplify Tolerance"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools