Skip to main content
Glama
HackerFund

Glendale GIS MCP Server

by HackerFund

query_dataset

Read-onlyIdempotent

Query Glendale GIS datasets with attribute filters, proximity, or bounding box to locate zoning, parcels, schools, or hazard zones.

Instructions

Search one dataset with attribute filters, a location (near) or a bounding box, with paging. Use it for questions the dedicated tools don't cover: zoning or the parcel at a location, schools of a type, bus stops on a route, all dams affecting an area. Results carry total, next_offset for the next page, and a ref for each feature. Geometry is off by default to save context. Parcels are queried live from the city; everything else comes from the offline snapshot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNoSpatial filter: [min_lon, min_lat, max_lon, max_lat]
nearNoSpatial filter: {"lat", "lon", "radius_m"} (radius up to 5000 m). radius_m 0 returns features containing the point, e.g. the zoning or parcel at a location. Results are sorted by distance.
limitNoPage size, 1-100
fieldsNoAttributes to return (default all); the object ID is always kept
offsetNoSkip this many results (paging)
datasetYesDataset id from list_datasets
filtersNoAttribute conditions, all of which must match. Each is {"field", "op", "value"}; op is eq, ne, lt, lte, gt, gte, in (value is a list), contains, starts_with, is_null or not_null. Field names are case-sensitive (see describe_dataset); text comparisons ignore case. Example: [{"field": "School_typ", "op": "eq", "value": "High School"}]
include_geometryNoReturn GeoJSON geometry; very large shapes are left out

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
_metaYes
notesNo
totalYesFeatures matching the query
offsetYes
datasetYes
featuresYes
returnedYes
next_offsetYesOffset for the next page; null on the last

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds valuable behavioral details: geometry is off by default to save context, results include total and next_offset for paging, and data source differences (live vs snapshot). This goes beyond the structured annotations and helps the agent set expectations.

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 concise (three sentences) and front-loaded with the primary purpose. It efficiently conveys scope, usage guidance, and key behavioral traits without repetition or fluff. Every sentence contributes meaning.

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 (8 parameters, nested objects) and that an output schema exists, the description covers all essential aspects: how to use it, when to use it, pagination behavior, geometry default, and data freshness. No critical information 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.

Parameters3/5

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

Schema description coverage is 100%, so the schema thoroughly documents all parameters (near, bbox, filters, limit, offset, fields, include_geometry, dataset). The description adds no new parameter semantics beyond what the schema already provides—it references paging but doesn't elaborate on parameter syntax. Thus baseline 3 applies.

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 starts with a clear verb+resource: 'Search one dataset' with attribute filters, location, bbox, and paging. It distinguishes itself from the sibling dedicated tools by providing concrete example queries (zoning, schools, bus stops, dams) that this generic tool covers, making its purpose unambiguous.

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?

It explicitly instructs to use this tool for questions the dedicated tools don't cover and gives examples. It also discloses the data freshness distinction (live parcels vs offline snapshot), which is essential for choosing this tool over specialized ones. No exclusions are listed, but the guidance is clear and actionable.

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