GeoCroissant MCP Server
This server lets MCP clients discover, search, and turn Earth observation data into validated GeoCroissant ML-Ready metadata.
List registered STAC catalogs (Earth Search, NASA VEDA) and browse/search EO collections by topic or keyword.
Search satellite scenes by bounding box, date range, cloud cover, and collection, or count scenes before generating metadata.
Geocode place names to EPSG:4326 bounding boxes.
Generate validated GeoCroissant JSON-LD from live STAC searches (single source or multiple independent sources).
Create a standards-conformant GeoCroissant scaffold from dataset parameters.
Validate, inspect, and summarize Croissant/GeoCroissant documents, including geospatial properties, distributions, RecordSets, and fields.
Extract distribution URLs, media types, checksums, and file patterns for direct data access.
Preview actual dataset records by running the mlcroissant data pipeline.
Get structure graphs of dataset lineage and dependencies.
Read GeoCroissant specification reference documentation and Python API snippets.
Provides access to NASA's VEDA STAC catalog for discovering Earth observation collections and scenes and generating GeoCroissant metadata from them.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@GeoCroissant MCP Server search for Sentinel-2 flood scenes near Houston and generate GeoCroissant metadata"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
GeoCroissant MCP Server
The GeoCroissant MCP Server gives Model Context Protocol (MCP) clients access to GeoCroissant, the geospatial extension of MLCommons Croissant.
Through Model Context Protocol (MCP), a client can explore Earth observation
datasets in catalogs and create GeoCroissant ML-Ready Metadata from selected scenes,
validate metadata, inspect dataset structure, and preview records with
mlcroissant.
The server provides current catalog and dataset information. The connected MCP client uses this information to understand the request and choose a suitable catalog and collection.
GeoCroissant workflow
A client can create and explore a GeoCroissant dataset in one workflow:
List the registered STAC catalogs.
Search their current collections and review the most relevant results.
Resolve a place to an EPSG:4326 bounding box when coordinates are not already available.
Count matching scenes before requesting records.
Generate GeoCroissant JSON-LD for the chosen collections, area, dates, and optional cloud-cover limit.
Validate or inspect the resulting metadata and preview its records.
user request
-> select a catalog from list_eo_catalogs
-> find collections with search_eo_datasets
-> inspect candidates with get_eo_dataset_details
-> resolve a place with geocode_place, when needed
-> verify availability with count_eo_scenes
-> generate one source with create_geocroissant_from_stac
or multiple sources with create_geocroissant_from_stac_sources
-> use json_ld and asset_urls in the clientThe result describes the dataset's location, time range, coordinate reference system, raster bands, and available spectral properties. Each selected STAC scene becomes an inline record connected to its source assets.
Remote clients: Generation returns the complete document in json_ld.
A returned path refers to the server's filesystem, so a remote client
should use json_ld when it needs to store the document locally.
Related MCP server: Copernicus Earth Observation MCP Server
MCP tools
Tool | Purpose |
| Return |
| Create GeoCroissant JSON-LD from a STAC search and return the selected source asset URIs. |
| Compose independent searches from any registered catalogs into source-specific RecordSets. |
| Create a GeoCroissant starting point from dataset details and return its validation result. |
| Check a document and return validation errors, warnings, and conformance information. |
| Summarize the dataset, geospatial properties, distributions, RecordSets, and Fields. |
| Show the nodes and relationships in the metadata graph. |
| List RecordSets and their keys, records, examples, and Fields. |
| Read a small, optionally filtered sample from a RecordSet. |
| List distribution URIs, media types, checksums, archive links, and FileSet patterns. |
| Read the GeoCroissant overview, context, properties, example, or Python API reference. |
| List the STAC services in the active YAML configuration. |
| Browse collections from a selected STAC service. |
| Read the provider's details for one collection. |
| Find candidate EPSG:4326 bounding boxes for a place name. |
| Count scenes for the chosen collections, area, dates, and optional cloud-cover limit. |
| Find STAC scenes that match the selected collections and search options. |
Source assets
The generated metadata keeps each selected asset URI in the format published
by its STAC provider, including s3://, https://, and other supported URI
schemes. Clients can then access each source using the connection method and
credentials provided for that service.
Multiple sources
create_geocroissant_from_stac_sources accepts an arbitrary list of explicit
STAC searches. Each source requires catalog_id, collection_id, and an
EPSG:4326 bbox; it can also set source_id, datetime_range,
max_cloud_cover, and limit. Catalog IDs must exist in the active YAML
registry. Sources may use different catalogs or repeat one catalog with
different collections.
{
"name": "Combined observations",
"sources": [
{
"source_id": "source_a",
"catalog_id": "catalog-a",
"collection_id": "collection-a",
"bbox": [-53, -31, -50, -28],
"datetime_range": "2026-08-01/2026-08-25",
"limit": 10
},
{
"source_id": "source_b",
"catalog_id": "catalog-b",
"collection_id": "collection-b",
"bbox": [-53, -31, -50, -28],
"limit": 10
}
]
}The result contains one RecordSet per source, source and catalog provenance, provider-native asset URIs, and per-source search results. It records the selected observations without claiming that sources are spatially, temporally, spectrally, or tensor aligned. Downstream code must apply the dataset-specific access, alignment, and preprocessing required for its model.
Catalog registry
The bundled registry is
src/geocr_mcp_server/config/catalogs.yaml. It currently defines:
earth-search: Element84 Earth Search, the default catalog.veda: NASA Visualization, Exploration, and Data Analysis (VEDA).
Each entry contains an identifier, display name, STAC endpoint, description,
and a collection snapshot. Searches use the provider's current catalog, so
new collections can appear before the snapshot is updated. When catalog_id
is omitted, default_catalog selects the service.
To use another registry, copy the YAML file, add the required catalog entries, and set its absolute path in the server environment:
{
"env": {
"GEOCR_CATALOGS_CONFIG": "/path/to/catalogs.yaml"
}
}No Python change is required. The server checks the configuration when it loads the registry.
Installation
Python 3.10 or newer is required. For an MCP client, uvx can install and run
the server without a manual checkout:
uvx --from "geocr-mcp @ git+https://github.com/HarshShinde0/geocr_mcp.git@main" geocr-mcp-serverTo install the command in the active Python environment:
pip install git+https://github.com/HarshShinde0/geocr_mcp.git@mainThe installation includes the GeoCroissant-enabled mlcroissant dependency.
Docker
docker build -t geocr-mcp-server .
docker run -i --rm geocr-mcp-serverFor streamable HTTP:
docker run -p 8000:8000 geocr-mcp-server \
--transport streamable-http --host 0.0.0.0 --port 8000Client configuration
The clients below use different configuration filenames and remote-server keys. Use the example for your client rather than copying a configuration between clients unchanged.
Configuration references: VS Code, Cursor, Antigravity, Kiro, Claude Code, and OpenCode. Claude Desktop configures remote custom connectors through the Claude account.
VS Code
Use.vscode/mcp.json with the top-level servers key. Hosted servers use
type: "http"; local servers use type: "stdio" with command and args.
Hosted server
Add the hosted streamable HTTP server to .vscode/mcp.json:
{
"servers": {
"geocr-mcp": {
"type": "http",
"url": "https://geocr-mcp-server.onrender.com/mcp"
}
},
"inputs": []
}Local development checkout
Use the local project directory and stdio transport when testing server changes.
For this repository checkout, add the following to .vscode/mcp.json:
{
"servers": {
"geocr-mcp-local": {
"type": "stdio",
"command": "uv",
"args": [
"--directory",
"${workspaceFolder}/geocr_mcp",
"run",
"geocr-mcp-server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
},
"inputs": []
}When geocr_mcp itself is the workspace root, use ${workspaceFolder} instead.
Do not add the --transport stdio arguments: stdio is already the local default.
Run MCP: List Servers from the Command Palette to inspect the connection and server output.
Cursor
Use.cursor/mcp.json with the top-level mcpServers key. Hosted servers use
url; local servers use type: "stdio" with command and args.
Add project-specific servers to .cursor/mcp.json, or use
~/.cursor/mcp.json to make them available in every project.
Hosted server
{
"mcpServers": {
"geocr-mcp": {
"url": "https://geocr-mcp-server.onrender.com/mcp"
}
}
}Local development checkout
{
"mcpServers": {
"geocr-mcp-local": {
"type": "stdio",
"command": "uv",
"args": [
"--directory",
"${workspaceFolder}/geocr_mcp",
"run",
"geocr-mcp-server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}When geocr_mcp itself is the project root, use ${workspaceFolder} instead.
Check Customize > MCP for server status, or select MCP Logs in Cursor's
Output panel.
Antigravity
Use.agents/mcp_config.json with the top-level mcpServers key. Hosted
servers must use serverUrl, while local servers use command and args.
Add project-specific servers to .agents/mcp_config.json, or use
~/.gemini/config/mcp_config.json to make them available globally.
Hosted server
Antigravity requires serverUrl for remote servers; url and httpUrl are not
supported.
{
"mcpServers": {
"geocr-mcp": {
"serverUrl": "https://geocr-mcp-server.onrender.com/mcp"
}
}
}Local development checkout
Replace /absolute/path/to/croissant with the path to this repository checkout.
{
"mcpServers": {
"geocr-mcp-local": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/croissant/geocr_mcp",
"run",
"geocr-mcp-server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}Open MCP Servers > Manage MCP Servers in the agent panel to reload the configuration and inspect connection status.
Kiro
Use.kiro/settings/mcp.json with the top-level mcpServers key. Hosted
servers use url; local servers use command and args.
Add project-specific servers to .kiro/settings/mcp.json, or use
~/.kiro/settings/mcp.json to make them available globally.
Hosted server
{
"mcpServers": {
"geocr-mcp": {
"url": "https://geocr-mcp-server.onrender.com/mcp"
}
}
}Local development checkout
Replace /absolute/path/to/croissant with the path to this repository checkout.
{
"mcpServers": {
"geocr-mcp-local": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/croissant/geocr_mcp",
"run",
"geocr-mcp-server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}Kiro reloads the file when it is saved. Check the MCP servers tab in the Kiro panel; connection logs are available under Kiro - MCP Logs in Output.
Claude Code
Use.mcp.json with the top-level mcpServers key. Hosted servers require
type: "http" and url; local servers use type: "stdio".
Add project-specific servers to .mcp.json in the project root.
Hosted server
{
"mcpServers": {
"geocr-mcp": {
"type": "http",
"url": "https://geocr-mcp-server.onrender.com/mcp"
}
}
}The equivalent project-scoped command is:
claude mcp add --transport http --scope project \
geocr-mcp https://geocr-mcp-server.onrender.com/mcpLocal development checkout
{
"mcpServers": {
"geocr-mcp-local": {
"type": "stdio",
"command": "uv",
"args": [
"--directory",
"${CLAUDE_PROJECT_DIR:-.}/geocr_mcp",
"run",
"geocr-mcp-server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}When geocr_mcp itself is the project root, use
${CLAUDE_PROJECT_DIR:-.} instead. Run claude mcp get geocr-mcp or use /mcp
inside Claude Code to verify the connection. Project-scoped servers require
approval when first loaded interactively.
Claude Desktop
Add hosted servers throughCustomize > Connectors. Use
claude_desktop_config.json only for local stdio servers.
For the hosted server, add the endpoint as a custom connector under
Customize > Connectors in Claude; remote connectors are configured through
the Claude account rather than claude_desktop_config.json:
https://geocr-mcp-server.onrender.com/mcpFor a local server, add a stdio entry to claude_desktop_config.json. Replace
/absolute/path/to/croissant with the path to this repository checkout:
{
"mcpServers": {
"geocr-mcp-local": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/croissant/geocr_mcp",
"run",
"geocr-mcp-server"
],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}OpenCode
Useopencode.json in the project root (or ~/.config/opencode/opencode.json
for global scope) with the top-level mcp key — not mcpServers. Hosted
servers require type: "remote" and url; local servers use
type: "local" with a command array and environment.
Hosted server
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"geocr-mcp": {
"type": "remote",
"url": "https://geocr-mcp-server.onrender.com/mcp",
"timeout": 60000
}
}
}The timeout is optional but recommended for the hosted server: free-tier
hosting can cold-start for tens of seconds, exceeding OpenCode's default
5-second timeout.
Local development checkout
Replace /absolute/path/to/croissant with the path to this repository checkout.
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"geocr-mcp-local": {
"type": "local",
"command": [
"uv",
"--directory",
"/absolute/path/to/croissant/geocr_mcp",
"run",
"geocr-mcp-server"
],
"environment": {
"FASTMCP_LOG_LEVEL": "ERROR"
}
}
}
}When geocr_mcp itself is the project root, point --directory at ..
Config is loaded once at startup, so quit and restart OpenCode after saving;
verify with opencode mcp list or by using a tool in a prompt.
Hosted server
Start a shared endpoint with the streamable HTTP transport:
geocr-mcp-server \
--transport streamable-http \
--host 0.0.0.0 \
--port "$PORT"The included render.yaml deploys the same command on Render. The current
hosted endpoint is:
https://geocr-mcp-server.onrender.com/mcpUse the client-specific hosted configuration above; remote-server keys are not portable between all clients.
When a reverse proxy provides TLS, bind the server withGEOCR_HOST=0.0.0.0 and set GEOCR_TRANSPORT=streamable-http.
Environment variables
Variable | Default | Purpose |
|
| Set stderr logging to |
| System temporary directory | Choose where generated files are written. Supplied filenames are reduced to their basename. |
| Bundled YAML registry | Load catalog definitions from another YAML file. |
|
| Set the bind address for SSE or streamable HTTP. |
|
| Set the port for SSE or streamable HTTP. |
|
| Select the MCP transport. |
Network and file handling
Catalog searches, scene requests, geocoding, URL inputs, and remote record previews connect to their configured services.
Scene and preview limits help keep requests manageable for large datasets.
Generated files are written inside
GEOCR_OUTPUT_DIR, and output names are reduced to their basename.The provided container runs as a non-root user by default.
Development
From the geocr_mcp directory:
uv venv
uv sync --all-groups
uv run ruff check src tests
uv run python -m pytest --cov --cov-branch
uv run python -m pytest -o addopts='' -m liveThe default test run covers local behavior and the MCP protocol. The live test group connects to Earth Search, NASA VEDA, and Nominatim.
For interactive protocol inspection:
npx @modelcontextprotocol/inspector geocr-mcp-serverAvailable Tools
12 toolscreate_geocroissant_from_stacA
Searches live EO data and generates VALIDATED GeoCroissant metadata from it.
This is the flagship end-to-end pipeline of this server:
1. Runs a real STAC search (bbox + collections + datetime + cloud cover).
2. Derives GeoCroissant properties from the results: schema.org spatial/
temporal coverage, CRS (EPSG:4326), record endpoint, band
configuration and spectral band metadata from `eo:bands`
(micrometers converted to nanometers), distribution FileObjects for
direct asset URLs, and a RecordSet with one inline row per scene.
3. Validates the document through the official `mlcroissant` library
before returning it.
Usage: THE tool for turning discovered EO data into GeoCroissant.
After generation use `inspect_geocroissant`, `get_records_preview`
and `extract_distribution_urls` on the output.
Returns:
--------
Dictionary containing:
- valid/errors/warnings: mlcroissant validation outcome.
- json_ld: The generated GeoCroissant document.
- path: Output file path when output_filename was given.
- search_summary: What was searched and how many scenes matched.
Inputs: bbox (required), name (required), limit, license, +7 more. Returns: object
create_geocroissant_scaffoldA
Generates a validated GeoCroissant JSON-LD scaffold from parameters.
Produces a standards-conformant starting point modeled on the official
GeoCroissant example: correct @context (including the `geocr` prefix),
dual conformance (`croissant/1.1` + `geocr`), schema.org spatial/temporal
coverage, GeoCroissant properties (CRS, resolutions, band configuration,
spectral bands), distribution entries and a RecordSet wired to them via
proper cr:source/cr:extract declarations.
The generated document is then parsed and checked by the real
``mlcroissant`` validator, so `valid=True` means the scaffold already
passes the official library checks.
Usage: Call FIRST when creating new dataset metadata, then edit the
returned JSON-LD for domain specifics and re-check with
`validate_croissant`. Use `inspect_geocroissant` afterwards to review it.
Returns:
--------
ScaffoldResult containing:
- valid: Whether the scaffold passed mlcroissant validation.
- json_ld: The generated document.
- errors/warnings: Library messages when not fully clean.
- path: Output file path when output_filename was given.
Inputs: name (required), bbox, license, version, +21 more. Returns: Result of generating a GeoCroissant JSON-LD scaffold.
extract_distribution_urlsA
Extracts downloadable URLs from a Croissant document's distribution.
Collects the `contentUrl` of every FileObject together with its encoding
formats, sizes and checksums, plus FileSet include patterns and archive
containers. These are the direct access points for the dataset bytes.
Usage: Use this tool to obtain concrete download links (e.g. GeoTIFF /
COG / ZIP assets) for ingestion code without parsing the JSON manually.
Returns:
--------
DistributionUrls containing:
- urls: One entry per distribution item (name, type, contentUrl,
encodingFormat, md5/sha256, includes/containedIn when present).
- count: Number of distribution items with at least one URL.
Inputs: jsonld_url, jsonld_path, jsonld_content. Returns: Downloadable URLs extracted from a dataset distribution.
get_geocroissant_spec_referenceA
Returns the GeoCroissant specification reference documentation.
Provides the vocabulary cheat sheet distilled from the official GeoCroissant
specification: namespace IRIs and prefixes, conformance declarations, every
`geocr:` property with expected types/domains/cardinality, the canonical
JSON-LD @context, a full sample document, and Python snippets for the
``mlcroissant`` API (load, validate, iterate records).
Usage: Read this ONCE before authoring or editing GeoCroissant documents so
property names, types and cardinalities match the specification exactly.
Then use `create_geocroissant_scaffold` and `validate_croissant`.
Returns:
--------
Markdown-formatted reference documentation for the requested topic.
Inputs: topic. Returns: result
get_records_previewA
Materializes the first records of a RecordSet by executing the data pipeline.
This tool runs the real ``mlcroissant`` operation graph: it downloads (or
resolves locally) the declared FileObjects/FileSets, applies extracts and
transforms, and yields actual records - exactly what
``Dataset.records(record_set)`` yields in Python.
Usage: Use it to preview/sample a dataset's actual data before writing
training code, or to sanity-check that a generated Croissant description
produces the expected columns and values.
IMPORTANT: For remote distributions this may download data; keep `limit`
small on large datasets. Datasets with inline `cr:data` return those rows
directly without downloads.
Returns:
--------
RecordsPreview containing:
- record_set: The RecordSet @id that was read.
- columns: Column names found across returned records.
- rows: List of records keyed by fully-qualified field ids.
- truncated: True if more records exist beyond `limit`.
Inputs: record_set (required), limit, filters, jsonld_url, +2 more. Returns: First records materialized from a RecordSet.
get_structure_graphA
Extracts the internal structure graph of a Croissant document.
Builds the directed multigraph that ``mlcroissant`` uses internally for
static analysis: nodes are Metadata / FileObject / FileSet / RecordSet /
Field objects and edges connect fields to their data sources, record sets
to their fields, files to archives they are contained in, and referenced
(foreign-key) fields.
Usage: Use this tool to reason about dataset lineage and dependencies,
e.g. "which files feed this field?", "what does this join look like?",
or to explain a dataset's architecture before writing loading code.
Returns:
--------
StructureGraph containing:
- nodes: Every node with @id, type, name and parent @id.
- edges: Directed edges as {source, target} @id pairs.
Inputs: jsonld_url, jsonld_path, jsonld_content. Returns: Nodes and edges of the Croissant structure graph.
inspect_geocroissantA
Inspects a Croissant/GeoCroissant document and returns a structured summary.
Parses the document through the ``mlcroissant`` library (which also acts as
a strict syntax/schema check - invalid documents are rejected) and returns
a structured digest: core metadata, GeoCroissant extension properties
(CRS, resolutions, band configuration, spectral bands, record endpoint...),
distribution entries (FileObjects/FileSets with URLs, formats, hashes),
and every RecordSet with its Fields (data types, array shapes,
source/extract/transform chains).
Usage: Use this tool to READ and UNDERSTAND a dataset description before
consuming it, comparing datasets, or planning how to load records.
Returns:
--------
Dictionary containing:
- name/description/license/version/conformsTo and other core metadata.
- geospatial: All declared `geocr:` extension properties.
- distribution: FileObject/FileSet entries.
- record_sets: RecordSets with nested fields and geo properties.
Inputs: jsonld_url, jsonld_path, jsonld_content. Returns: object
list_eo_catalogsA
Lists the Earth observation STAC catalogs registered on this server.
The registry is data-driven (config/catalogs.yaml): today it contains
Element84 Earth Search over AWS Open Data
(https://earth-search.aws.element84.com/v1) with its searchable
modalities, curated collections and topic keywords.
Usage: Call once to see where EO data can be discovered from before
using `search_eo_datasets` / `search_eo_scenes`.
Returns:
--------
Dictionary containing:
- catalogs: Registered catalogs with id, name, URL, description,
modalities, common collections and supported topics.
Inputs: no named parameters. Returns: object
list_record_setsA
Lists the RecordSets of a Croissant/GeoCroissant document.
A RecordSet is a collection of records (rows/examples) produced by
applying the declared extraction pipeline to the distribution. This tool
returns each RecordSet's @id, name, description, key fields, enumeration
flag, number of inline records/examples and its Fields with their data
types and source chains.
Usage: Call this tool to discover what data a dataset exposes and which
RecordSet names to pass to `get_records_preview`.
Returns:
--------
List of dictionaries, one per RecordSet, each including:
- @id: The RecordSet identifier used by other tools.
- fields: Nested field summaries (dataType, isArray/arrayShape,
source extract/transform chain, geo band properties).
Inputs: jsonld_url, jsonld_path, jsonld_content. Returns: result
search_eo_datasetsA
Searches Earth observation DATASETS (STAC collections) by keyword.
Performs collection-level search on the Earth Search STAC API
(AWS Open Data). Queries hit the topics map first ('flood' -> Sentinel-1
+ Sentinel-2, 'dem' -> Copernicus DEM...), then fall back to keyword
matching against live collection metadata; every hit is classified by
sensor modality (optical / radar / elevation).
Usage: Start here for dataset-level discovery ("find me flood/burn
scar/terrain datasets"). Then use the returned collection ids with
`search_eo_scenes`, or jump straight to `create_geocroissant_from_stac`
to get GeoCroissant metadata.
Returns:
--------
Dictionary containing:
- matched_topics: Topic-map hits for the query.
- count: Number of matching collections found.
- collections: Matches with catalog, collection id, title,
description snippet, modality, license and temporal extent.
Inputs: query, modality. Returns: object
search_eo_scenesA
Searches satellite SCENES inside a bounding box on Earth Search.
Executes a real STAC item search (pystac-client) against
https://earth-search.aws.element84.com/v1 filtered by spatial extent,
time range and cloud cover. Scenes are the individual acquisitions
(tiles/granules) that become records of a GeoCroissant dataset.
Usage: Use after `search_eo_datasets` (or directly with known
collections) to check actual data availability for an area of interest.
Feed promising results into `create_geocroissant_from_stac`.
Returns:
--------
Dictionary containing:
- scene_count and scenes: Per-scene id, collection, acquisition
datetime, platform, cloud cover, native EPSG and asset keys.
Inputs: bbox (required), limit, modality, collections, +2 more. Returns: object
validate_croissantA
Validates a Croissant or GeoCroissant JSON-LD document.
Runs the official MLCommons ``mlcroissant`` validator: JSON syntax check,
JSON-LD expansion, structure-graph construction (FileObjects/FileSets,
RecordSets, Fields, sources & joins) and full schema conformance checks.
Usage: Call this tool whenever a dataset description is created or edited,
BEFORE publishing it, and after any modification of an existing file.
Works for both plain Croissant documents and documents using the
GeoCroissant extension (`geocr:` properties).
Returns:
--------
Dictionary containing:
- valid: True when the document passes validation.
- errors: Blocking errors reported by the library (empty when valid).
- warnings: Non-blocking recommendations (e.g. missing license).
- is_geospatial: Whether GeoCroissant conformance is declared.
- conforms_to / dataset_name: Extracted metadata when loadable.
Inputs: jsonld_url, jsonld_path, jsonld_content. Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 12 tools
The main workflow stages are clearly separated: discovery tools distinguish catalogs, datasets, and scenes, while generation tools differ by their input source. There is some overlap among the inspection tools—inspect_geocroissant already reports RecordSets and distribution entries, making list_record_sets and extract_distribution_urls partially redundant—but the descriptions are detailed enough to guide selection.
All tool names follow a consistent snake_case verb_noun pattern: list, search, create, validate, inspect, get, and extract are used predictably. The naming also preserves resource hierarchy clearly, from catalogs to datasets to scenes, which helps agents infer relationships between tools.
Twelve tools is an appropriate size for this domain: a few discovery tools, two generation paths, one validator, and several inspection/preview/extraction utilities. The count supports the full workflow without bloating the surface or feeling thin.
The toolset covers the full lifecycle: EO catalog/dataset/scene discovery, GeoCroissant creation from live STAC data or manual parameters, validation, structured inspection, record-set preview, and distribution URL extraction. There are no obvious dead ends because outputs from generation flow naturally into the validation and inspection tools.
Maintenance
Related MCP Connectors
Search dynamical.org's open STAC catalog of weather & climate datasets (GFS, ECMWF, HRRR).
Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
Search, sample and query open reproducible datasets published as immutable Parquet with schemas.
European Sentinel and Copernicus Contributing Mission archive from the EU's Copernicus Data Space…
Related MCP Servers
- AlicenseBqualityCmaintenanceEnables AI assistants to search and access geospatial datasets through STAC (SpatioTemporal Asset Catalog) APIs. Supports querying satellite imagery, weather data, and other geospatial assets with spatial, temporal, and attribute filters.1120MIT
- AlicenseBqualityBmaintenanceProvides tools to search, download, and manage satellite imagery from all Copernicus Sentinel missions via the Copernicus Data Space ecosystem. It enables advanced geospatial queries, temporal coverage analysis, and automated data management for Earth observation tasks.1310LGPL 3.0
- FlicenseAqualityDmaintenanceProvides access to the OpenLandMap STAC catalog, offering over 100 global environmental datasets including soil, climate, and vegetation data. It enables AI agents to discover, search, and retrieve Cloud-Optimized GeoTIFFs for global geospatial analysis.27-
- AlicenseNot gradedqualityDmaintenanceEnables discovery, analysis, and explanation of open satellite data through MCP, with support for STAC catalogs and NASA GIBS.1MIT