Skip to main content
Glama

Caja y centroide de GeoJSON

geojson-bbox
Read-onlyIdempotent

Calcula la caja delimitadora, número de vértices y centroide de cualquier geometría GeoJSON. Cuándo: hay que calcular coordenadas, distancias, rumbos o áreas a partir de puntos dados. No para: calcular la caja delimitadora de un círculo alrededor de un punto (geo-bounding-box). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Computes the bounding box [minLon, minLat, maxLon, maxLat], vertex count and vertex centroid of any GeoJSON geometry, Feature or FeatureCollection, validating coordinate ranges. When: coordinates, distances, bearings or areas have to be computed from given points. Not for: computing the bounding box of a circle around a point (geo-bounding-box). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB.

Input Schema

NameRequiredDescriptionDefault
geojsonYesGeoJSON object (object; required).

Output Schema

NameRequiredDescriptionDefault
bboxNo
centroidNo
verticesNo
geometry_typesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / geojson / examples
      Added value: +[
      +  {
      +    "coordinates": [
      +      [
      +        [
      +          0,
      +          0
      +        ],
      +        [
      +          2,
      +          0
      +        ],
      +        [
      +          2,
      +          2
      +        ],
      +        [
      +          0,
      +          2
      +        ],
      +        [
      +          0,
      +          0
      +        ]
      +      ]
      +    ],
      +    "type": "Polygon"
      +  }
      +]
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description nonetheless adds concrete operational limits (64 KB input, 1 s per call, 1 MB result) and determinism, which are not in the annotations. It does restate read-only/no-network, which is redundant with annotations, keeping it just below a 5.

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?

Front-loaded with the core action, then organized into labeled clauses (When / Not for / Side effects / Deterministic / Limits). The bilingual duplication adds length but each clause carries distinct information and nothing is wasted.

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?

Output schema exists, yet the description still names the three returned values, and it covers limits, determinism and side effects. For a single-parameter read-only tool, nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100% and there is only one parameter, so the baseline is 3; the description earns a bump by clarifying that the input may be any GeoJSON geometry, Feature or FeatureCollection and that coordinate ranges are validated, which the terse schema description ('GeoJSON object (object; required)') does not convey.

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 (computes bounding box, vertex count, centroid) and names the exact input domain (any GeoJSON geometry, Feature or FeatureCollection). It explicitly distinguishes itself from the sibling geo-bounding-box, so an agent can route without opening either schema.

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?

Provides an explicit 'When' clause (computing coordinates, distances, bearings or areas from given points) and an explicit 'Not for' clause pointing to geo-bounding-box for circle bounding boxes. Both the positive and negative selection conditions are stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources