Skip to main content
Glama

Caja delimitadora alrededor de un punto

geo-bounding-box
Read-onlyIdempotent

Calcula la caja delimitadora que encierra un círculo de radio dado alrededor de un punto, útil para filtros "a menos de N km". Cuándo: hay que calcular coordenadas, distancias, rumbos o áreas a partir de puntos dados. No para: calcular la caja delimitadora de un objeto GeoJSON (geojson-bbox). 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 (min/max latitude and longitude) enclosing a circle of a given radius around a point, e.g. for "within N km" pre-filters; handles poles and the antimeridian. When: coordinates, distances, bearings or areas have to be computed from given points. Not for: computing the bounding box of a GeoJSON object (geojson-bbox). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
unitNoDistance unit (optional; one of: m, km, mi, nmi, ft; default "km").km
centerYesPoint as {lat, lon} in decimal degrees (WGS84) (object; required).
radiusYesRadius (number; required; > 0; max 20000000).

Output Schema

NameRequiredDescriptionDefault
max_latNo
max_lonNo
min_latNo
min_lonNo
crosses_antimeridianNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / center / examples
      Added value: +[
      +  {
      +    "lat": 4.711,
      +    "lon": -74.0721
      +  }
      +]
    • addedInput schema / properties / radius / examples
      Added value: +[
      +  10
      +]
  2. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Computes the bounding box (min/max latitude and longitude) enclosing a circle of a given radius around a point, e.g. for \"within N km\" pre-filters; handles poles and the antimeridian. When: coordinates, distances, bearings or areas have to be computed from given points. Not for: computing the bounding box of a GeoJSON object (geojson-bbox). 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."
  3. First observed

TDQS

A4/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 safety is covered; the description adds genuine new context beyond that: pole and antimeridian handling, and hard limits (64 KB input, 1 s per call, 1 MB result). Only the determinism sentence largely restates idempotentHint.

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

Conciseness3/5

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

Content is well front-loaded (purpose, when, not-for, side effects, limits), but the Spanish and English blocks are near-verbatim duplicates and the trailing '[EN completo / full EN: inputSchema.description]' is noise. The same information could be delivered in about half the length.

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

Completeness4/5

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

An output schema exists and annotations are rich, so the description needn't explain return values; it is nonetheless complete on side effects, determinism and resource limits. Only the underspecified positive 'when to use' leaves a small routing gap against the many geo-* siblings.

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 100% with per-property descriptions, enums and bounds, so the schema does the heavy lifting and baseline 3 applies. The description mentions 'radius' and implies unit choice via 'dentro de N km', but adds no semantics beyond what the schema states.

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+resource: 'Computes the bounding box ... enclosing a circle of a given radius around a point', and explicitly names the sibling it is not (geojson-bbox). An agent can distinguish it from geo-haversine/geo-polygon-area without opening the schema.

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

Usage Guidelines4/5

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

It gives an explicit exclusion with a named alternative ('No para: calcular la caja delimitadora de un objeto GeoJSON (geojson-bbox)') and a concrete use case ('within N km' pre-filters). However, the 'Cuándo' clause ('calcular coordenadas, distancias, rumbos o áreas a partir de puntos dados') is generic and overlaps a dozen geo siblings, so the positive routing is weaker than the negative routing.

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