Skip to main content
Glama
rteina

geoparquet-mcp

by rteina

geoparquet_run_sql

Run ad-hoc read-only SQL on remote GeoParquet datasets to answer questions no typed tool supports, such as joins, HAVING, and window functions.

Instructions

Run one read-only SELECT against the datasets in scope, for questions the other tools do not have a shape for.

WHEN TO USE IT. Last, not first. The typed tools push their filters into the remote Parquet file by construction; an ad-hoc query pushes down only what its WHERE clause happens to express, so a query that forgets a bbox predicate can read gigabytes to answer something geoparquet_aggregate_attribute would have answered in kilobytes. Reach for it for genuine gaps: a join between two datasets, a HAVING clause, a window function, a self-join.

WHAT YOU CAN QUERY. Each dataset in scope is a table named exactly as the dataset is — overture_places, overture_divisions, overture_buildings — and those are the only tables that exist. There is no way to name a file: table functions such as read_parquet are refused, and so is anything that is not a single SELECT. That is a perimeter, not a lint rule.

WRITING A FAST ONE. Constrain bbox explicitly, as four comparisons on its members, because that is the form Parquet statistics can prune on:

SELECT categories.primary AS category, count(*) AS n FROM overture_places WHERE bbox.xmin <= 2.40 AND bbox.xmax >= 2.30 AND bbox.ymin <= 48.88 AND bbox.ymax >= 48.85 GROUP BY 1 ORDER BY n DESC

Writing that filter with a geometry function instead would be correct and would read the entire file, because the Parquet reader cannot see through it. Select named columns rather than *, for the same reason: unread columns are unfetched.

PARAMETERS. sql: one SELECT statement. max_rows: row ceiling, applied as an outer LIMIT. Hard, and capped at 1000. max_bytes: byte ceiling. Reported, not pre-emptive — see below.

WHAT COMES BACK. rows, tables_read, the executed_sql actually run, the scan block, and byte_budget_exceeded. That last one is a verdict after the fact, not a brake: DuckDB cannot abort a scan on bytes already transferred, so the rows are returned — they have been paid for — and the flag tells you the query was too expensive and the next one should be narrower. The row ceiling, by contrast, is enforced.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
max_rowsNo
max_bytesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it delivers extensively. It discloses that only a single SELECT is permitted, table functions are refused, read_parquet is blocked, and the 'perimeter' is intentional. It also explains that byte_budget_exceeded is a post-hoc verdict rather than a pre-emptive brake, and that max_rows is hard-enforced while max_bytes is not.

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 long but every section earns its place, and clear headers make it scannable: WHEN TO USE IT, WHAT YOU CAN QUERY, WRITING A FAST ONE, PARAMETERS, WHAT COMES BACK. It front-loads the most important guidance first and uses a concrete query example to illustrate the bbox pushdown point efficiently.

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?

For a complex, flexible SQL tool with no annotations, the description is exceptionally complete. It covers query scope, performance optimization, filter pushdown mechanics, parameter semantics, and result fields including executed_sql, scan, and byte_budget_exceeded. Even though an output schema exists, the descriptive explanation of post-hoc byte budget behavior is necessary context that the schema alone would not convey.

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%, but the dedicated PARAMETERS section fully compensates. It explains sql as 'one SELECT statement,' max_rows as an outer LIMIT that is hard and capped at 1000, and max_bytes as a reported ceiling rather than pre-emptive. This goes far beyond the raw schema and gives an agent the operational meaning of each parameter.

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 SELECT against the datasets in scope.' It explicitly frames the tool as covering questions 'the other tools do not have a shape for,' distinguishing it from the typed sibling tools. It also clarifies that datasets are the only queryable tables, removing ambiguity about the tool's scope.

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?

The 'WHEN TO USE IT' section is explicit and actionable: 'Last, not first,' with concrete examples of genuine gaps such as joins, HAVING, window functions, and self-joins. It warns against using ad-hoc queries when a typed tool would push filters down efficiently, naming the tradeoff explicitly and thereby guiding selection among siblings.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rteina/geoparquet-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server