-
Notifications
You must be signed in to change notification settings - Fork 5
Home
MCP Geocontext is the central MCP server used to expose trusted geospatial data and services from the Géoplateforme to AI assistants.
It is currently deployed in production as v0.9.8 at:
https://geollm.beta.ign.fr/geocontext/mcp
The production version already provides a broad set of geospatial tools:
- geocoding of places, addresses and points of interest;
- altitude lookup;
- administrative context lookup;
- cadastral information lookup;
- urban planning information lookup;
- public utility easements lookup;
- WFS type search;
- WFS schema description;
- WFS feature retrieval by identifier;
- WFS collection querying with attribute filters, spatial filters, sorting, limits and output modes.
The current production version relies on @ignfab/gpf-schema-store ^0.1.5 for WFS discovery and schema description, while querying the Géoplateforme WFS directly for feature retrieval.
The main branch already contains early changes toward v0.10.0.
The roadmap focuses on four main priorities:
- stabilising the MCP response contract;
- completing the WFS query refactoring;
- reducing response volume and geometry payloads;
- preparing Geocontext for richer spatial workflows and more robust client compatibility.
Objective: stabilise the technical and functional foundations before expanding the toolset.
Clarify and document how Geocontext uses:
-
content; -
structuredContent; -
isError; - textual summaries;
- structured payloads;
- reusable
feature_refobjects.
The goal is to provide predictable responses across different MCP clients, including clients that handle structuredContent properly and clients that still rely mostly on textual content.
Expected outcome:
- a documented response pattern for all tools;
- consistent success and error responses;
- a clear distinction between human-readable summaries and machine-readable payloads;
- reduced ambiguity for downstream clients and tests.
Finish the refactoring already started on the WFS querying tool.
Main tasks:
- fix known bugs;
- clarify the input schema;
- simplify the parameter model;
- improve validation and error reporting;
- support clearer output modes;
- improve handling of
results,hitsandrequest; - consider splitting or paginating
hitsresponses if needed; - make spatial filtering easier to use and easier to test.
The tool should remain general-purpose, but it must become safer, clearer and less likely to produce huge or unusable responses.
Add useful metadata to returned geometries, especially when spatial filters are used.
Possible metadata:
- area for polygon geometries;
- length for linear geometries;
- distance to the reference geometry used in the spatial filter;
- bounding box;
- geometry type;
- original CRS;
- simplified geometry status.
Expected outcome:
- better summaries for assistants;
- less need to inspect raw geometries;
- improved ranking and explanation of spatial results.
Add a geometry_mode parameter to control how much geometry is returned.
Target values:
-
omit: return no geometry; -
centroid: return only centroid geometry; -
bbox: return only bounding box; -
simplify: return simplified geometry; -
original: return original geometry; -
filter_intersection: return only the part intersecting the spatial filter.
This is a core feature for controlling response size and making Geocontext usable with large WFS features.
Continue building end-to-end tests for MCP workflows.
Initial focus:
- trace the global prompt-to-tool path;
- capture intermediate tool calls and responses;
- test representative prompts;
- test the
geocontexttocartochain; - validate behaviour across multiple AI assistants where possible.
Expected outcome:
- better confidence before releasing
v0.10.0; - reproducible test scenarios;
- easier diagnosis of client-specific issues.
Objective: make the stabilised components work together as a coherent product.
Move Geocontext to the next version of gpf-schema-store once its new catalogue model and search engine are stable.
This dependency is important because Geocontext needs richer schema knowledge to:
- improve WFS type discovery;
- better describe available datasets;
- understand geometry characteristics;
- expose lighter and safer query behaviours;
- support enriched schemas such as ADMIN EXPRESS and urban planning datasets.
Expected outcome:
- more reliable dataset discovery;
- improved schema descriptions;
- better grounding for WFS queries;
- fewer poorly targeted requests from assistants.
Implement geometry-light responses as a standard behaviour, not as an afterthought.
Main tasks:
- avoid returning large geometries by default;
- use
geometry_modeconsistently; - return centroids, bounding boxes or simplified geometries when appropriate;
- preserve full geometry access only when explicitly required;
- align this behaviour with schema metadata from
gpf-schema-store.
Expected outcome:
- lower response volume;
- better assistant compatibility;
- faster responses;
- fewer broken interactions caused by oversized payloads.
Complete the isochrone tool and integrate it into Geocontext as a reusable spatial filtering capability.
Expected capabilities:
- compute an isochrone from a point;
- support time-based filtering;
- support travel mode where available;
- use the isochrone as a spatial filter;
- avoid returning heavy geometry to the LLM unless explicitly needed.
Expected outcome:
- users can ask questions such as “which schools are within 15 minutes of this address?”;
- assistants can use isochrones as intermediate spatial constraints;
- Geocontext gains a major practical analysis capability.
Continue improving performance, particularly around WFS calls and schema lookup.
Focus areas:
- WFS rate limiting;
- timeout handling;
- error messages;
- caching opportunities;
- search performance;
- response size;
- resilience under concurrent usage.
Expected outcome:
- more predictable production behaviour;
- improved latency;
- fewer client-side failures.
Finalise the functional integration with mcp-carto, following the work already started in geocontext#133.
The Geocontext roadmap should not absorb Carto entirely at this stage, but it should define a clean contract for handing cartographic outputs to Carto.
Expected outcome:
- Geocontext can produce results that are directly usable by Carto;
- Carto can display Geocontext-generated layers;
- end-to-end scenarios can be tested reliably.
Objective: add new geospatial tools once the core WFS and response foundations are stable.
Candidate tools:
- isodistance;
- routing;
- distance between two points;
- reverse geocoding.
These tools should follow the same principles as the existing Geocontext tools:
- compact textual summary;
- structured payload;
- reusable references;
- controlled geometry output;
- clear error contract;
- predictable input schemas.
Make tool outputs easier to reuse as tool inputs.
Examples:
- use a geocoded point as input for altitude lookup;
- use a cadastral parcel as a spatial filter;
- use an administrative boundary as a WFS query filter;
- use an isochrone as a spatial constraint;
- send a WFS result to Carto for visualisation.
Expected outcome:
- more robust multi-step workflows;
- less repeated geocoding or geometry transfer;
- better assistant planning.
Each new tool should come with:
- unit tests;
- integration tests;
- representative prompt tests;
- failure-mode tests;
- payload-size tests where geometry is involved.
Expected outcome:
- new capabilities do not weaken the existing product;
- regressions are caught before deployment;
- demos become less dependent on luck.
Objective: address structural changes that improve long-term maintainability.
Study and then implement the migration from mcp-framework to the official MCP SDK.
This should be handled after the functional foundations are stable, because changing the MCP server foundation too early would mix protocol migration with business logic refactoring.
Expected outcome:
- closer alignment with the MCP ecosystem;
- better long-term maintainability;
- reduced dependency risk;
- easier compatibility with future MCP clients.
Assess whether Geocontext should directly expose a Carto MCP App, or whether Carto should remain a separate MCP server.
Evaluation criteria:
- client compatibility;
- deployment complexity;
- separation of responsibilities;
- security and CSP constraints;
- user experience;
- testability;
- maintenance cost.
Expected outcome:
- clear architectural decision;
- either a stronger integration contract between Geocontext and Carto, or a partial integration of Carto capabilities into Geocontext.
Run deeper tests on:
- input validation;
- prompt-driven misuse;
- oversized payloads;
- WFS abuse patterns;
- rate limiting;
- CORS configuration;
- MCP client compatibility;
- response leakage risks;
- production performance under load.
Expected outcome:
- safer public exposure;
- clearer operational limits;
- stronger confidence before wider adoption.
| Priority | Objective | Main Geocontext work |
|---|---|---|
| P0 | Stabilise the foundations | Response contract, content / structuredContent, gpf_wfs_get_features refactoring, geometry_mode, geometry metadata, first E2E tests |
| P1 | Make the product coherent and usable | Upgrade to new gpf-schema-store, reduce geometry payloads, finalise isochrone, optimise performance, strengthen Geocontext + Carto integration |
| P2 | Extend capabilities | Add isodistance, routing, point-to-point distance and reverse geocoding; improve chaining between tools; extend tests |
| P3 | Prepare long-term sustainability | Migrate to official MCP SDK, study Carto integration, consolidate security and performance tests |
Main focus:
- stable response model;
- completed
gpf_wfs_get_featuresrefactoring; - initial
geometry_mode; - improved WFS input schema;
- better error handling;
- first stronger E2E coverage.
Main focus:
- migration to the new
gpf-schema-store; - enriched schema usage;
- safer geometry payloads;
- geometry metadata;
- improved WFS discovery;
- performance improvements.
Main focus:
- completed isochrone tool;
- reusable spatial filters;
- stronger chaining between tools;
- improved Geocontext + Carto scenarios.
Main focus:
- isodistance;
- routing;
- distance between two points;
- reverse geocoding;
- expanded prompt and integration tests.
Main focus:
- official MCP SDK migration if validated;
- stable public contracts;
- documented tool behaviours;
- security testing;
- performance testing;
- client compatibility matrix;
- production-grade operational limits.
Geocontext depends on gpf-schema-store for:
- WFS type discovery;
- schema descriptions;
- enriched metadata;
- search quality;
- future geometry-light behaviours;
- dataset coverage and completeness information.
The Geocontext roadmap should therefore track gpf-schema-store closely, without merging both roadmaps into one document.
Geocontext depends on mcp-carto for visual exploration of results.
The priority is not to make Geocontext a cartographic application, but to ensure that Geocontext can produce clean, reusable outputs that Carto can display reliably.
The roadmap depends on stronger test infrastructure for:
- end-to-end MCP scenarios;
- prompt-based workflows;
- tool-call tracing;
- multi-client compatibility;
- performance;
- security.
This is especially important because Geocontext is not just an API wrapper. It is a tool server used by probabilistic assistants, which makes strong contracts and tests essential.
- Prefer structured, reusable outputs over verbose raw payloads.
- Return full geometries only when they are truly needed.
- Make every tool response understandable by both humans and MCP clients.
- Keep WFS querying powerful, but make it safer and easier to guide.
- Use
feature_refobjects to support chaining without duplicating large data. - Treat Carto as a visualisation companion, not as a replacement for Geocontext.
- Test real assistant workflows, not only isolated functions.
- Stabilise contracts before adding too many new tools.