Skip to main content
Glama
geolens-mcp

geolens-mcp

Official

query

Run read-only SQL SELECT queries against accessible GeoLens datasets in a sandboxed PostGIS environment. Specify allowed tables and row limits to retrieve columns and rows safely.

Instructions

Run one read-only SQL SELECT against accessible datasets.

Executes through the server's hardened SQL sandbox: a single SELECT over data.* tables, an allowlisted function set (aggregates, math, string, date, JSON), and a strict server-side budget (a 5 s statement timeout, a repetition cap on self-joins, and row_limit rows, at most 1000). Returns {columns, rows, row_count, truncated} with rows as lists in column order. Geometry columns come back as hex EWKB; select ST_AsText(geom) or ST_AsGeoJSON(geom) for readable geometry. ST_AsGeoJSON(geom, 6) rounds coordinates to six decimals, which suits display but can make a small polygon invalid.

PostGIS functions allowed: ST_Area, ST_AsGeoJSON, ST_AsText, ST_Buffer, ST_Centroid, ST_Collect, ST_Contains, ST_Distance, ST_DWithin, ST_GeometryType, ST_GeomFromGeoJSON, ST_GeomFromText, ST_Intersects, ST_IsValid, ST_Length, ST_MakeEnvelope, ST_MakePoint, ST_NPoints, ST_Point, ST_SetSRID, ST_Transform, ST_Union, ST_Within, ST_X, ST_Y. ST_Collect and ST_Union take two geometries (no aggregate form). The && bounding-box operator works, as do ::geography / ::geometry and geography(geom).

Requires credentials with AI-chat permission — anonymous configurations cannot use this tool. Workflow: search_datasets to find a dataset, then get_dataset_schema for its table_name and columns, then reference it as data.<table_name> in the SQL and list the same table_name in restrict_tables. Every table the query touches must be listed there; the scope can only narrow what your credentials already see. Writes, other schemas, and unlisted functions are rejected with a short reason that names the refused function.

Args: sql: A single SELECT statement over data.* tables. restrict_tables: Table names (no data. prefix) the query may touch. Required and non-empty. row_limit: Max rows to return (1-1000, default 100).

Input Schema

NameRequiredDescriptionDefault
sqlYes
row_limitNo
restrict_tablesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.25.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / row_limit / maximum
      Added value: +1000
    • addedInput schema / properties / row_limit / minimum
      Added value: +1
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: read-only enforcement, sandbox restrictions, 5-second timeout, self-join repetition cap, row limit, allowed functions, credential requirements, and rejection behavior are all disclosed. It also explains the return shape and geometry encoding.

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?

The description is front-loaded with purpose and sandbox behavior, and most sentences add operational value. It is longer than typical because of the exhaustive PostGIS function allowlist and detailed edge cases, but that detail is relevant for complex SQL generation rather than pure padding.

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?

There is no output schema, yet the description specifies the return object's fields, truncation behavior, and geometry encoding. It also covers credentials, table-scoping rules, query restrictions, and the prerequisite workflow, leaving little needed before an agent can 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%, so the description must compensate, and it does: sql is constrained to a single SELECT over data.* tables, restrict_tables requires non-empty table names without the data. prefix and must list every touched table, and row_limit is explained as max rows with a 1–1000 range and default 100.

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 opens with a precise verb and resource: 'Run one read-only SQL SELECT against accessible datasets.' It clearly distinguishes this tool as the SQL execution path, and the workflow references search_datasets and get_dataset_schema as prerequisite siblings.

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 provides a clear end-to-end workflow: use search_datasets, then get_dataset_schema, then reference the table as data.<table_name> and list it in restrict_tables. However, it does not explicitly say when to use this instead of sibling tools like get_features or get_map, so it lacks full when-not/alternative guidance.

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