Key Takeaways:
- MCP (Model Context Protocol) is an open standard, introduced by Anthropic in November 2024 and since adopted across the AI industry, for connecting AI models to external tools and data through typed tool definitions rather than free-form access
- Spatial questions are naturally tool-shaped: geocode this address, find features within this boundary, compute the distance between these points, fetch this layer, run this analysis, each maps to one well-defined function call
- Geospatial data rarely fits in a model's context window and its coordinates must be exact, not generated, which makes it a strong argument for typed tools over letting a model write its own SQL
- A well-designed geospatial MCP server keeps responses small and structured, is read-only by default, scopes credentials tightly, and logs every call with its inputs and outputs
- Mapular runs MCP servers over geospatial data in daily production use, internally and in client systems, and builds agentic workflows on top of them
Ask an AI model what is within two kilometres of a given address, and it will happily answer, with coordinates that look plausible and are frequently wrong. It was never given the address, the road network or the two kilometres. It generated an answer with the shape of a correct one. This is the core problem the Model Context Protocol solves for geospatial work: it lets a model ask a real system a real question and get back a real, verifiable answer, instead of pattern-matching its way to something that merely looks right.
What MCP actually is
The Model Context Protocol (MCP) is an open standard for connecting AI models to external tools, data sources and systems. Anthropic introduced it in November 2024, and it has since been adopted broadly across the AI industry, with client and server implementations built by many other model providers, IDE vendors and platform teams. The idea is deliberately simple: instead of a model trying to do everything inside its own context window, an MCP server exposes a small set of typed tools, each with a name, a description and a defined input and output schema. The model decides which tool to call and with what arguments; the server does the actual work and returns a result.
This is a different pattern from stuffing documents into a prompt and hoping the model finds what it needs. A tool call is explicit, inspectable and repeatable: you know exactly what the model asked for and what it was given back, and you can log, rate-limit or reject that call independently of the model's own reasoning. That separation of "what the model wants" from "what actually happens" is what makes MCP useful for anything where correctness matters more than plausibility.
Why geospatial data is an unusually good fit
Most domains that get connected to AI models through MCP benefit from it. Geospatial data benefits from it more than most, for three reasons that compound.
First, spatial questions are already tool-shaped. "Geocode this address," "find every feature within this boundary," "compute the distance between these two points," "fetch this layer," "run a buffer and intersect it with that other layer" are not vague requests. Each one is a well-defined function with clear inputs and a clear output. A geospatial workflow is naturally a sequence of such calls, which is exactly the shape MCP tools are built for.
Second, the data itself does not fit in a model's context. A cadastral layer, a points-of-interest dataset or a road network lives in a database or a catalogue with millions of rows and geometries with thousands of vertices each. There is no reasonable way to paste that into a prompt, and there is no need to: the model does not need to see the whole dataset, it needs a tool that can query the relevant slice of it on demand.
Third, and most importantly, coordinates and geometries have to be exact. A latitude and longitude, a parcel boundary, a distance in metres, these are not the kind of thing a language model should generate from its training data. Language models are good at producing text that resembles correct text, and a set of coordinates that resembles a real address is exactly as useless as a citation that resembles a real paper. MCP tools let the model ask a system that actually holds the ground truth, geocode the address, query the database, run the spatial function, rather than inventing something in the right format.
Practical patterns for a geospatial MCP server
Once you accept that the model should call tools rather than generate answers, the design question becomes which tools to expose. In practice, a small set of categories covers most of what a geospatial MCP server needs to do:
- Query tools over spatial databases: given a bounding box, a polygon or a set of filters, return matching features as a bounded, structured result, never an unbounded dump of a table.
- Catalogue and discovery tools: let the model ask what layers exist, what their schema is, and what their coverage and freshness look like, before it queries them.
- Geocoding tools: turn an address or place name into coordinates, and the reverse. This is the most common entry point into a spatial workflow and the step most prone to ambiguity, so it deserves its own dedicated tool rather than a general query.
- Analysis tools: buffers, spatial joins, distance and area calculations, aggregation by region. These do the computation server-side rather than asking the model to reason about geometry itself.
- Export tools: hand back a result as a file, a map layer or a link, once a result is too large to usefully return as text.
The pattern across all five categories is the same: the tool does the spatial work, and the model decides which tool to call and interprets the result. Keeping responses small and structured is not a minor implementation detail, it is the difference between a usable tool and a broken one. A model does not want, and cannot usefully process, two million vertices of a coastline. It wants a count, a summary, a handful of representative features, or a file it can point at. Every geospatial MCP tool should be designed around the question "what does the model actually need to answer the user's question," not "what does the underlying dataset contain."
Typed tools versus letting a model write SQL
There is a tempting shortcut here: instead of building typed tools, give the model direct access to a spatial database and let it write its own SQL. It is faster to set up, and a capable model can write reasonable spatial SQL. It is also, beyond a personal prototype, the wrong choice.
A typed tool has a fixed shape. "Find features within this radius of this point" takes a point, a radius and a layer, and nothing else. The model cannot ask it to drop a table, cannot construct a query that scans a multi-million-row layer without a spatial index, and cannot leak columns never meant to be exposed. Free-form SQL access has none of those constraints by default. Every guardrail you would want, read-only access, row limits, column allowlists, has to be bolted on separately, and a creative enough prompt can often find its way around a filter applied at the SQL layer rather than enforced by the interface itself.
The difference shows up the first time something goes wrong. With a typed tool, a mistake produces a wrong or empty result: the model asked for the wrong radius, or queried the wrong layer. With free-form SQL access, a mistake can lock a table, scan far more data than intended, or return a column nobody meant to hand to a model. Typed tools make the failure mode boring, which is exactly what you want from a system a model is driving.
Guardrails that matter in production
None of the above works without guardrails, and the guardrails that matter for geospatial MCP servers are the same ones that matter for any tool a model can call, applied consistently:
- Read-only by default. A tool that queries a layer should not be able to write to it. If a workflow genuinely needs a write (updating a record, committing a change to a dataset), that is a separate, explicitly named tool, not a side effect of a query tool.
- Scoped credentials. The credentials behind an MCP server should have access to exactly the layers and operations the tools expose, not the full permissions of whatever service account was easiest to configure. A tool that can only ever see one dataset cannot leak a different one.
- Result size limits. Every query tool needs a hard cap on rows, vertices or file size returned, enforced server-side, not left to the model to request politely.
- Provenance and logging. Every call, its inputs, and its output should be logged. When a downstream answer is wrong, you need to be able to trace it back to the specific tool call that produced the bad data, rather than guessing at what the model might have done internally.
- Human confirmation for anything that writes. Any tool that changes data, moves a boundary, updates a record, triggers a downstream process, should require an explicit confirmation step rather than executing on the model's first pass.
What still goes wrong, honestly
Even with all of this in place, geospatial MCP servers still fail in a few predictable ways, and it is worth naming them rather than pretending the protocol solves everything on its own.
Models hallucinate place names. Given an ambiguous or misspelled address, a model will sometimes propose a plausible-sounding correction rather than surface the ambiguity, so a geocoding tool should return multiple candidates with confidence scores rather than a single silent guess. Models mix up coordinate reference systems, treating a projected coordinate as latitude and longitude, or assuming a dataset is in WGS84 when it is not; a well-designed tool states its CRS explicitly in every response rather than assuming the model will ask. And models over-fetch: asked for "the parcels near this site," a model will sometimes request a far larger area than the question needed, because a bigger radius feels safer than a precise one.
None of this is a protocol failure. It is the same class of mistake a junior analyst makes in their first week with a new dataset, and the fix is the same: design the tools so a mistake is cheap to make and cheap to catch. A capped result size turns an over-fetch into a truncated list, not a runaway query. An explicit CRS turns a coordinate mix-up into a visible mismatch, not a silently wrong map. A geocoding tool that returns candidates instead of a single answer turns a hallucinated place name into a question back to the user, not a confident error.
Where Mapular fits
We run MCP servers over geospatial data in daily production use, both internally and inside client systems, and we build agentic workflows on top of them: agents that query spatial databases, run analysis and hand back structured results a person or a downstream system can act on. If you are building on top of your own geospatial data and want AI models to be able to query, analyse or reason over it safely, get in touch.
