Skip to main content
Glama
rteina

geoparquet-mcp

by rteina

geoparquet_count_in_polygons

Counts point features from one remote GeoParquet dataset inside each polygon from another within a bounding box, returning areas with feature counts for geographic grouping.

Instructions

Count how many features of one dataset fall inside each polygon of another: a point-in-polygon join between two remote datasets, restricted to a rectangle.

WHEN TO USE IT. For "how many of these are in each district", "which neighbourhood has the most of them", "break this down by administrative area" — any question whose answer is a table of areas with a number against each. It is the only tool that reads two datasets at once, and the only way to group by something that is not a column but a shape.

Use geoparquet_aggregate_attribute instead when you can group by a column the dataset already carries; it is much cheaper. Use this one when the grouping is geographic and the boundaries live in a different file.

COST. This is the most expensive tool here, and knowingly so: the rectangle prunes both datasets before the join, but the containment test still has to decode real geometry on both sides. Expect tens of megabytes and tens of seconds on a city-sized box, against single-digit megabytes for the other tools. Keep the rectangle tight, and prefer a narrower polygon_subtype.

PARAMETERS. min_lon, min_lat, max_lon, max_lat: the rectangle, in WGS 84 degrees. All four are required — this tool has no whole-world mode. point_source: the dataset being counted. polygon_source: the dataset providing the containing areas. It must be a polygonal dataset; a point dataset is refused before anything is read. polygon_subtype: narrows the polygon side to one administrative level, for example 'locality' or 'county'. Without it a country-sized polygon is returned alongside a neighbourhood one, because both overlap the rectangle, and the counts are then not comparable to each other. limit: maximum polygons returned, ordered by count descending.

WHAT COMES BACK. polygons, each with polygon_name, polygon_subtype and feature_count; the sql that ran; and the scan block. The count is the number of features whose geometry is contained by that polygon, not merely overlapping its bounding box.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
max_latYes
max_lonYes
min_latYes
min_lonYes
point_sourceNooverture_places
polygon_sourceNooverture_divisions
polygon_subtypeNo

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?

With no annotations provided, the description carries the full behavioral disclosure burden and does so thoroughly. It discloses that this is the most expensive tool, explains the rectangle pruning and geometry decode costs, refuses point datasets for polygon_source, and clarifies that counts are based on true containment rather than bounding-box overlap.

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 tightly organized into labeled sections: purpose, when-to-use, cost, parameters, and return value. Each section adds decision-relevant information that is not available in the schema, and the main purpose is front-loaded. No sentence feels redundant or filler.

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?

Given the tool's complexity, zero annotations, and 0% schema description coverage, the description is remarkably complete. It covers selection criteria, cost/performance expectations, parameter behavior, output shape, and a key semantic caveat about containment versus bounding boxes, leaving the agent with everything needed to invoke 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. Every parameter is explained with practical guidance: the rectangle is required and WGS 84, polygon_source must be polygonal, polygon_subtype prevents incomparable mixed granularity, and limit controls count-descending output.

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 specific verb-plus-resource statement: counting features from one dataset inside polygons of another via a point-in-polygon join. It further distinguishes itself from siblings by noting it is the only tool that reads two datasets at once and the only way to group by a shape rather than a column.

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 gives concrete natural-language queries, explicitly names the cheaper alternative geoparquet_aggregate_attribute, and states the condition for choosing this tool instead: geographic grouping where boundaries live in a separate file. This gives an agent clear selection criteria rather than leaving the decision to inference.

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