Skip to main content
Glama
GeoCroissant MCP Server

GeoCroissant MCP Server

by HarshShinde0

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.

NOTE

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:

  1. List the registered STAC catalogs.

  2. Search their current collections and review the most relevant results.

  3. Resolve a place to an EPSG:4326 bounding box when coordinates are not already available.

  4. Count matching scenes before requesting records.

  5. Generate GeoCroissant JSON-LD for the chosen collections, area, dates, and optional cloud-cover limit.

  6. 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 client

The 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.

TIP

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

ping

Return pong to confirm that the MCP server is available.

create_geocroissant_from_stac

Create GeoCroissant JSON-LD from a STAC search and return the selected source asset URIs.

create_geocroissant_from_stac_sources

Compose independent searches from any registered catalogs into source-specific RecordSets.

create_geocroissant_scaffold

Create a GeoCroissant starting point from dataset details and return its validation result.

validate_croissant

Check a document and return validation errors, warnings, and conformance information.

inspect_geocroissant

Summarize the dataset, geospatial properties, distributions, RecordSets, and Fields.

get_structure_graph

Show the nodes and relationships in the metadata graph.

list_record_sets

List RecordSets and their keys, records, examples, and Fields.

get_records_preview

Read a small, optionally filtered sample from a RecordSet.

extract_distribution_urls

List distribution URIs, media types, checksums, archive links, and FileSet patterns.

get_geocroissant_spec_reference

Read the GeoCroissant overview, context, properties, example, or Python API reference.

list_eo_catalogs

List the STAC services in the active YAML configuration.

search_eo_datasets

Browse collections from a selected STAC service.

get_eo_dataset_details

Read the provider's details for one collection.

geocode_place

Find candidate EPSG:4326 bounding boxes for a place name.

count_eo_scenes

Count scenes for the chosen collections, area, dates, and optional cloud-cover limit.

search_eo_scenes

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-server

To install the command in the active Python environment:

pip install git+https://github.com/HarshShinde0/geocr_mcp.git@main

The installation includes the GeoCroissant-enabled mlcroissant dependency.

Docker

docker build -t geocr-mcp-server .
docker run -i --rm geocr-mcp-server

For streamable HTTP:

docker run -p 8000:8000 geocr-mcp-server \
  --transport streamable-http --host 0.0.0.0 --port 8000

Client 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

TIP

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

TIP

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

TIP

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

TIP

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

TIP

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/mcp

Local 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

TIP

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/mcp

For 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

TIP

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/mcp

Use the client-specific hosted configuration above; remote-server keys are not portable between all clients.

NOTE

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

FASTMCP_LOG_LEVEL

WARNING

Set stderr logging to DEBUG, INFO, WARNING, or ERROR.

GEOCR_OUTPUT_DIR

System temporary directory

Choose where generated files are written. Supplied filenames are reduced to their basename.

GEOCR_CATALOGS_CONFIG

Bundled YAML registry

Load catalog definitions from another YAML file.

GEOCR_HOST

127.0.0.1 locally; 0.0.0.0 in cloud environments

Set the bind address for SSE or streamable HTTP.

GEOCR_PORT

8000

Set the port for SSE or streamable HTTP.

GEOCR_TRANSPORT

stdio locally; streamable-http in cloud environments

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 live

The 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-server

Available Tools

12 tools
create_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

    A4.4/5.0

    Scored across 12 tools

    Disambiguation4/5

    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.

    Naming Consistency5/5

    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.

    Tool Count5/5

    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.

    Completeness5/5

    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

    ActivitySlowing
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      C
      maintenance
      Enables 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.
      11
      20
      MIT
    • A
      license
      B
      quality
      B
      maintenance
      Provides 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.
      13
      10
      LGPL 3.0
    • F
      license
      A
      quality
      D
      maintenance
      Provides 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
      -