Skip to main content
Glama
BnJam

STAC MCP Server

by BnJam
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

STAC MCP Server

PyPI Version Build Status CI Coverage Container Python License PyPI Downloads Ruff

An MCP (Model Context Protocol) Server that provides access to STAC (SpatioTemporal Asset Catalog) APIs for geospatial data discovery and access. Supports dual output modes (text and structured json) for all tools.

The coverage badge is updated automatically on pushes to main by the CI workflow.

Overview

This MCP server enables AI assistants and applications to interact with STAC catalogs to:

  • Search and browse STAC collections

  • Find geospatial datasets (satellite imagery, weather data, etc.)

  • Access metadata and asset information

  • Perform spatial and temporal queries

Related MCP server: SkyFi MCP Server

Features

Available Tools

All tools accept an optional output_format parameter ("text" default, or "json"). JSON mode returns a single MCP TextContent whose text field is a compact JSON envelope: { "mode": "json", "data": { ... } } (or { "mode": "text_fallback", "content": ["..."] } if a handler lacks a JSON branch). This preserves backward compatibility while enabling structured consumption (see ADR 0006 and ASR 1003).

  • get_root: Fetch root document (id/title/description/links/conformance subset)

  • get_conformance: List all conformance classes; optionally verify specific URIs

  • get_capabilities: Get a summary of STAC API capabilities (query, sort, fields, queryables, aggregation, filter)

  • search_collections: List and search available STAC collections

  • get_collection: Get detailed information about a specific collection

  • search_items: Search for STAC items with spatial, temporal, and attribute filters

  • get_item: Get detailed information about a specific STAC item

  • get_queryables: Get queryable properties for a collection

  • get_aggregations: Get aggregations for STAC items

  • estimate_data_size: Estimate data size for STAC items using lazy loading (XArray + odc.stac)

Search Parameters

The search_items tool supports comprehensive STAC API search parameters:

  • collections: One or more collection IDs to search

  • bbox: Bounding box [west, south, east, north] or GeoJSON geometry

  • datetime: Datetime filter (e.g., "2020-01-01/2020-12-31")

  • limit: Maximum number of items to return

  • query: Query filter for properties

  • fields: List of fields to include/exclude (e.g., ["id", "properties.datetime"])

  • intersects: GeoJSON geometry for spatial intersection queries

  • ids: List of specific item IDs to retrieve (batch fetch)

  • sortby: Sort order (e.g., ["-properties.datetime"] for descending)

  • sign_assets: If True and catalog is Planetary Computer, sign asset URLs for direct access

Pagination Support

Search responses include pagination metadata with cursor-based navigation links:

{
  "type": "item_list",
  "count": 10,
  "items": [...],
  "meta": {
    "catalog_url": "https://example.com/stac",
    "parameters": {...},
    "returned": 10,
    "has_more": true,
    "links": [
      {"rel": "next", "href": "https://example.com/stac/search?token=abc123"},
      {"rel": "prev", "href": "https://example.com/stac/search?token=xyz789"}
    ]
  }
}

Planetary Computer Asset Signing

When working with Microsoft Planetary Computer catalogs, you can enable asset signing to get signed URLs for direct asset access:

{
  "method": "tools/call",
  "params": {
    "name": "search_items",
    "arguments": {
      "collections": ["sentinel-2-l2a"],
      "limit": 5,
      "sign_assets": true
    }
  }
}

Capability Discovery & Aggregations

The new capability tools (ADR 0004) allow adaptive client behavior:

  • Graceful fallbacks: Missing /conformance, /queryables, or aggregation support returns structured JSON with supported:false instead of hard errors.

  • get_conformance falls back to the root document's conformsTo array when the dedicated endpoint is absent.

  • get_queryables returns an empty set with a message if the endpoint is not implemented by the catalog.

  • get_aggregations constructs a STAC Search request with an aggregations object; if unsupported (HTTP 400/404), it returns a descriptive message while preserving original search parameters.

Data Size Estimation

The estimate_data_size tool provides accurate size estimates for geospatial datasets without downloading the actual data:

  • Lazy Loading: Uses odc.stac to load STAC items into xarray datasets without downloading

  • AOI Clipping: Automatically clips to the smallest area when both bbox and AOI GeoJSON are provided

  • Fallback Estimation: Provides size estimates even when odc.stac fails

  • Detailed Metadata: Returns information about data variables, spatial dimensions, and individual assets

  • Batch Support: Retains structured metadata for efficient batch processing

Usage

MCP Protocol / Server Configuration

The server implements the Model Context Protocol (MCP) for standardized communication.

{
  "stac": {
    "command": "uvx",
    "args": [
      "--from",
      "git+https://github.com/wayfinder-foundry/stac-mcp",
      "stac-mcp"
    ],
    "transport": "stdio",
  }
}
Published Image
# With Docker
docker run --rm -i ghcr.io/wayfinder-foundry/stac-mcp:latest

# With Podman
podman run --rm -i ghcr.io/wayfinder-foundry/stac-mcp:latest

Examples

Example: Basic Search

{
  "method": "tools/call",
  "params": {
    "name": "search_items",
    "arguments": {
      "collections": ["landsat-c2l2-sr"],
      "bbox": [-122.5, 37.7, -122.3, 37.8],
      "datetime": "2023-01-01/2023-01-31",
      "limit": 5,
      "output_format": "json"
    }
  }
}

The server responds with a single TextContent whose text is a JSON string like:

{
  "type": "item_list",
  "count": 5,
  "items": [{"id": "..."}],
  "meta": {
    "catalog_url": "https://example.com/stac",
    "parameters": {...},
    "returned": 5,
    "has_more": false,
    "links": []
  }
}

Example: Advanced Search with Sorting and Field Selection

{
  "method": "tools/call",
  "params": {
    "name": "search_items",
    "arguments": {
      "collections": ["sentinel-2-l2a"],
      "intersects": {
        "type": "Point",
        "coordinates": [-122.4194, 37.7749]
      },
      "sortby": ["-properties.datetime"],
      "fields": ["id", "properties.datetime", "properties.eo:cloud_cover"],
      "limit": 10,
      "output_format": "json"
    }
  }
}

Example: Batch Fetch Specific Items

{
  "method": "tools/call",
  "params": {
    "name": "search_items",
    "arguments": {
      "ids": ["item1", "item2", "item3"],
      "output_format": "json"
    }
  }
}

Development

Local Development

git clone https://github.com/wayfinder-foundry/stac-mcp.git
cd stac-mcp
pip install -e ".[dev]"

For local development with containers, you can use VS Code's Remote Containers extension with the provided .devcontainer configuration.

Testing

pytest -v

Test Coverage

The project uses coverage.py (already a dependency was added) for measuring statement and branch coverage.

Quick run (terminal):

coverage run -m pytest -q
coverage report -m

Example output (illustrative):

Name                                Stmts   Miss Branch BrMiss  Cover
---------------------------------------------------------------------
stac_mcp/observability.py             185      4     42      3    96%
stac_mcp/tools/execution.py            68      2     18      1    94%
... (others) ...
---------------------------------------------------------------------
TOTAL                                 620     20    140      9    96%

Generate an HTML report (optional):

coverage html
open htmlcov/index.html  # macOS

Configuration: .coveragerc enforces branch = True and omits tests/* and scripts/version.py. Update omit patterns only when necessary to keep metrics honest.

Recommended workflow before opening a PR:

  1. ruff format stac_mcp/ tests/

  2. ruff check stac_mcp/ tests/ --fix

  3. coverage run -m pytest -q

  4. coverage report -m (ensure no unexpected drops)

Linting

ruff format stac_mcp/ tests/
ruff check stac_mcp/ tests/ --fix --no-cache

Version Management

The project uses semantic versioning (SemVer) with automated version management based on PR labels or branch naming, implemented in .github/workflows/container.yml.

Automatic Versioning

When PRs are merged to main, the workflow determines the version increment using either PR labels or branch prefixes:

PR Labels (Recommended for Automated Tools)

Labels take priority over branch prefixes. Add one of these labels to your PR:

  • bump:patch or bump:hotfix → patch increment (0.1.0 → 0.1.1) for bug fixes

  • bump:minor or bump:feature → minor increment (0.1.0 → 0.2.0) for new features

  • bump:major or bump:release → major increment (0.1.0 → 1.0.0) for breaking changes

Branch Prefixes (For Human Contributors)

If no version bump label is present, the workflow falls back to branch prefix detection:

  • hotfix/, fix/, copilot/fix-, or copilot/hotfix/ branches → patch increment (0.1.0 → 0.1.1) for bug fixes

  • feature/ or copilot/feature/ branches → minor increment (0.1.0 → 0.2.0) for new features

  • release/ or copilot/release/ branches → major increment (0.1.0 → 1.0.0) for breaking changes

See CONTRIBUTING.md for detailed guidelines on version bumping.

Manual Version Management

You can also manually manage versions using the version script (should normally not be needed unless doing a coordinated release):

# Show current version
python scripts/version.py current

# Increment version based on change type
python scripts/version.py patch    # Bug fixes (0.1.0 -> 0.1.1)
python scripts/version.py minor    # New features (0.1.0 -> 0.2.0)  
python scripts/version.py major    # Breaking changes (0.1.0 -> 1.0.0)

# Set specific version
python scripts/version.py set 1.2.3

The version system maintains consistency across:

  • pyproject.toml (project version)

  • stac_mcp/__init__.py (version)

  • stac_mcp/server.py (server_version in MCP initialization)

Container Development

To develop with containers:

# Build development image
docker build -f Containerfile -t stac-mcp:dev .

# Test the container
docker run --rm -i stac-mcp:dev

# Using docker-compose for development
docker-compose up --build

# For debugging, use an interactive shell (requires modifying Containerfile)
# docker run --rm -it --entrypoint=/bin/sh stac-mcp:dev

Current Containerfile (single-stage) notes:

  • Based on python:3.12-slim for broad wheel compatibility (rasterio, shapely, etc.)

  • Installs GDAL/PROJ system libraries needed by rasterio/odc-stac

  • Installs the package with pip install .

  • Entrypoint: python -m stac_mcp.server (stdio MCP transport)

  • Multi-stage/distroless hardening can be reintroduced later (tracked by potential future ADR)

Documentation

FastMCP Guidelines and Architecture

STAC MCP includes comprehensive documentation for FastMCP patterns and agentic geospatial reasoning:

  • FastMCP Documentation: Complete guide to MCP decorators, resources, tools, and prompts for STAC workflows

    • DECORATORS.md: Choosing the right decorator for STAC operations

    • GUIDELINES.md: FastMCP architecture and usage patterns

    • PROMPTS.md: Agentic STAC search reasoning and methodology

    • RESOURCES.md: STAC catalog discovery and metadata patterns

    • CONTEXT.md: Context usage for logging and progress tracking

These documents provide guidance for:

  • AI agents reasoning about STAC catalog searches

  • Developers implementing STAC MCP features

  • Understanding the planned FastMCP integration (issues #69, #78)

Additional Documentation

STAC Resources

License

Apache 2.0 - see LICENSE file for details.

Available Tools

11 tools
estimate_data_sizeC

Estimate the data size for a STAC query.

ParametersJSON Schema
NameRequiredDescriptionDefault
bboxNo
limitNo
queryNo
datetimeNo
aoi_geojsonNo
catalog_urlNo
collectionsYes
output_formatNotext
force_metadata_onlyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only states 'estimate' without saying whether this is a read-only operation, whether it makes network requests, how the estimate is computed, or if it has side effects. This is insufficient for a tool that may execute queries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no fluff and front-loads the main verb. However, it is so brief that it sacrifices necessary detail, but for pure conciseness it earns a high score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no annotations, and an output schema that is not provided in context, the one-sentence description is insufficient. It does not explain return values, output format behavior, or the impact of parameters on the estimate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema description coverage is 0% and the description does not discuss any of the 9 parameters. The phrase 'STAC query' implies query parameters but gives no meaning to individual parameters like bbox, datetime, collections, limit, or output_format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'estimate' and identifies the resource as 'data size for a STAC query'. This clearly distinguishes it from sibling search and retrieval tools, though the term 'data size' could be more explicit (e.g., number of items vs total bytes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives like search_items or get_aggregations. The description does not mention prerequisites, exclusions, or typical scenarios for use.

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

get_aggregationsC

Get aggregations for STAC items.

ParametersJSON Schema
NameRequiredDescriptionDefault
bboxNo
queryNo
datetimeNo
catalog_urlNo
collectionsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It states a get operation but doesn't explain what aggregations are, whether any filtering is applied, performance implications, or that it is read-only. The single sentence provides minimal insight beyond the tool's name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short sentence that is direct and front-loaded. However, it is under-specified, so the conciseness comes at the cost of clarity. The structure is fine, but the content is minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists and may cover return values, the description is incomplete for a tool with 5 parameters and no schema coverage. It does not explain the purpose of aggregations, how they relate to STAC items, or any constraints or edge cases, leaving the agent without critical context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention any parameters. There are 5 parameters (collections, bbox, query, datetime, catalog_url) with no explanation of their roles, formats, or how they affect the aggregations. The description offers no compensatory value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb+resource structure ('Get aggregations for STAC items'), indicating a read operation on aggregated data. It is specific enough to distinguish from sibling tools like get_item or search_items, though it doesn't explicitly point out the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as search_items or get_queryables. There is no mention of typical use cases, prerequisites, or conditions under which aggregations would be preferred.

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

get_capabilitiesA

Return a summary of STAC API capabilities.

Maps conformance classes to human-readable capability names, making it easier for agents to discover what features a catalog supports (e.g., query, sort, fields, aggregations).

ParametersJSON Schema
NameRequiredDescriptionDefault
catalog_urlNoOptional catalog URL override.
output_formatNoOutput format ("text" or "json").text

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the burden of explaining behavior. It discloses that the tool maps conformance classes to human-readable names and provides examples (query, sort, fields, aggregations), but it does not mention any side effects, permissions, or output structure details. This is adequate but not rich, so a score of 3 is appropriate.

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 two sentences, front-loaded with the primary action, and every sentence adds value. The second sentence enriches the first with concrete examples, containing no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has only two optional parameters, an output schema, and a relatively simple purpose. The description provides sufficient overview and context (mapping behavior and examples) to understand when and why to use it. The presence of an output schema lessens the need to describe return values, so a score of 4 is justified.

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?

Input schema coverage is 100%, with clear descriptions for both parameters (catalog_url and output_format). The tool description does not add any additional meaning to these parameters; it only describes the overall capability mapping. Since the schema already fully documents the parameters, the baseline of 3 is warranted.

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 clearly states the tool's purpose: 'Return a summary of STAC API capabilities.' It also adds specificity by explaining the mapping from conformance classes to human-readable capability names, which distinguishes it from the sibling get_conformance tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'making it easier for agents to discover what features a catalog supports' gives clear usage context. It does not explicitly name alternatives, but the contrast with raw conformance listing is implied, which is sufficient for a guidance score of 4.

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

get_collectionB

Fetch a single STAC Collection by id.

ParametersJSON Schema
NameRequiredDescriptionDefault
catalog_urlNo
collection_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'Fetch' implying a read operation, but provides no details on error handling, authentication, or consequences. This is insufficient for a tool with no annotation support.

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 one short sentence, front-loaded with the key information, and contains no filler words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return values are covered, but the description is minimal. It does not explain the catalog_url parameter or provide usage guidance, making it incomplete for a tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate. It clarifies that collection_id is the identifier, but catalog_url is not explained at all. The description adds minimal meaning beyond the parameter names.

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 clearly states the verb 'Fetch', the resource 'single STAC Collection', and the scope 'by id', which distinguishes it from sibling tools like search_collections (plural) and get_item (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a specific collection id is known, but it does not explicitly mention alternatives or exclusions. It lacks guidance on when to choose this tool over search_collections or get_item.

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

get_conformanceC

Return server conformance classes.

ParametersJSON Schema
NameRequiredDescriptionDefault
checkNoOptional list of conformance URIs to check support for. If provided, returns a boolean for each URI indicating support.
catalog_urlNoOptional catalog URL override.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits itself. 'Return server conformance classes' is minimal; it does not describe the effect of the check parameter returning booleans, the catalog_url override, or any side effects/read-only nature. This falls short of full transparency for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded and free of fluff. It is appropriately sized for a simple tool, though it is quite terse; this balances to a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity, 100% schema coverage, and the presence of an output schema, the description provides adequate context for an agent to invoke the tool. However, it lacks any contextual framing about when conformance classes are needed or how they relate to other endpoints, keeping it at a 3.

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%, with both check and catalog_url fully documented in the input schema. The description adds no additional parameter semantics, so per the baseline for high schema coverage, this scores a 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Return server conformance classes' clearly identifies the action (return) and resource (server conformance classes). It does not explicitly differentiate from siblings like get_capabilities, so it earns a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_capabilities. There is no mention of exclusions or preferred scenarios. The only implied usage is from the tool name itself, which does not constitute clear guidance.

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

get_itemA

Get a specific STAC Item by collection and item ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
item_idYesThe item ID.
catalog_urlNoOptional catalog URL override.
sign_assetsNoIf True and catalog is Planetary Computer, sign asset URLs for direct access. Requires planetary-computer package.
collection_idYesThe collection ID.
output_formatNoOutput format ("text" or "json").text

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only says 'Get' without specifying whether it's read-only, what happens if the item is not found, whether it requires authentication, or how the response is formatted (though some is in schema). Minimal transparency beyond the basic operation.

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?

Single concise sentence with no redundant words. Front-loads the action and resource. Perfectly sized for the information it conveys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's relative simplicity, an output schema exists, and parameter descriptions are complete, the description is adequate but not rich. It lacks guidance on when to prefer this over search_items or how optional parameters like sign_assets operate, though schema covers mechanics. Somewhat complete but not fully contextual.

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 documents all 5 parameters. The description adds no extra meaning beyond naming the two required parameters (collection and item ID). Baseline 3 is appropriate; no additional semantic value provided.

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 clearly states the action ('Get'), the resource ('specific STAC Item'), and the key identifiers ('collection and item ID'). It distinguishes from sibling tools like search_items (search) and get_collection (collection-level), making the 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it: when you have a known collection ID and item ID. It doesn't explicitly mention alternatives or exclusions, but the word 'specific' and inclusion of both IDs clearly contextualize direct retrieval versus search. No misleading guidance.

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

get_queryablesA

Get the queryable properties for a specific STAC collection by its ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
catalog_urlNo
collection_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates the basic function and implies a read-only action through 'Get', but it does not mention error behavior, collection existence requirements, the nature of the returned queryables, or how the optional catalog_url is used.

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 a single, compact sentence that gets straight to the point. It has no filler or redundant phrasing, making it easy to parse and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. However, the description omits the optional catalog_url parameter and does not address the array-vs-singular ambiguity in collection_id. For a low-complexity tool this is minimally adequate, but it leaves clear gaps in parameter understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

Schema description coverage is 0%, and the description only partially compensates. It clarifies that collection_id identifies the collection, but the schema declares it as an array of strings while the description says 'specific collection' (singular), creating ambiguity. The optional catalog_url parameter is not mentioned at all, leaving its purpose unexplained.

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 uses a specific verb ('Get') and resource ('queryable properties') scoped to a specific STAC collection by ID. This clearly distinguishes it from sibling tools such as get_collection, search_items, or search_collections, which deal with different resources or operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the context clear: use this tool when you need queryable properties for one named collection. It doesn't explicitly state alternatives or exclusions, but the sibling list and the phrasing provide enough situational guidance for an agent to choose this tool appropriately.

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

get_rootC

Return the STAC root document for a catalog.

ParametersJSON Schema
NameRequiredDescriptionDefault
catalog_urlNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It states 'Return,' implying a read-only operation, but it does not explain how catalog_url is used, what happens when it is null, or any network/error behavior. This minimal disclosure is insufficient for full transparency.

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 a single, focused sentence that immediately communicates the tool's purpose. It contains no filler or redundant content, making it appropriately concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description could still adequately cover usage and parameter semantics. However, it omits any explanation of catalog_url and lacks guidance on when to call this tool relative to siblings. The tool is simple, but the description leaves key gaps, especially regarding the optional parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

The schema has one parameter, catalog_url, with 0% description coverage, and the tool description does not mention this parameter at all. The phrase 'for a catalog' vaguely hints at its purpose, but the description adds no explicit meaning beyond the parameter name and type in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' and the resource 'STAC root document for a catalog,' making the tool's function unambiguous. However, it does not explicitly distinguish itself from sibling tools like get_capabilities, which also return server-level resources, so it earns a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only states the action and resource, with no mention of prerequisites, exclusions, or when it is appropriate to call get_root over other catalog-related tools.

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

get_sensor_registry_infoA

Get information about the STAC sensor registry.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral transparency. It only says 'get information' and does not disclose whether the operation is read-only, what the response structure looks like, or any other behavioral traits beyond the obvious read intent.

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 a single, clear sentence with no filler or redundant information. It is front-loaded and directly states the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple parameterless getter, the description is minimally adequate, but it lacks context about what the STAC sensor registry is and why a user would invoke this tool. The existence of an output schema mitigates some ambiguity, but the description alone offers no additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

This tool takes zero parameters, so schema description coverage is trivially 100%. The baseline score of 4 applies, and the description appropriately avoids discussing parameters that do not exist.

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 clearly states that the tool retrieves information about the STAC sensor registry, using a specific verb and resource. It distinguishes itself from sibling tools such as get_root, get_conformance, and search_collections, which focus on different API aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, without any context about prerequisites, scenarios, or exclusions.

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

search_collectionsC

Return a page of STAC collections.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
catalog_urlNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'Return a page,' which implies read-only and pagination, but does not explain pagination behavior, the role of catalog_url, or any output format. The agent is left guessing about side effects and edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise and front-loaded, but it is under-specified. It earns its place as a purpose statement but omits necessary details, making the description too thin to be fully useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters, no annotations, and an output schema, the description is incomplete. It fails to explain pagination semantics (limit), the effect of catalog_url, or how this tool fits within the broader STAC API workflow, leaving significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema description coverage is 0%, so the description must compensate by explaining the parameters. It mentions neither limit nor catalog_url, forcing the agent to infer their meaning solely from names, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Return') and the resource ('STAC collections'), with a hint at pagination ('a page'). It distinguishes from sibling tools like get_collection (singular) and search_items (items) by focusing on collections as a whole.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For instance, it doesn't clarify when to prefer search_collections over get_collection or search_items, nor mention any prerequisites or context like catalog_url.

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

search_itemsC

Search for STAC items.

ParametersJSON Schema
NameRequiredDescriptionDefault
idsNoList of specific item IDs to retrieve.
bboxNoBounding box [west, south, east, north] or GeoJSON geometry.
limitNoMaximum number of items to return.
queryNoQuery filter for properties.
fieldsNoList of fields to include/exclude (e.g., ["id", "properties.datetime"]). Prefix with "-" to exclude (e.g., ["-properties.eo:cloud_cover"]).
sortbyNoSort order (e.g., ["-properties.datetime"] for descending, ["+properties.datetime"] for ascending).
datetimeNoDatetime filter (e.g., "2020-01-01/2020-12-31").
intersectsNoGeoJSON geometry for spatial intersection query.
catalog_urlNoOptional catalog URL override.
collectionsNoOne or more collection IDs to search.
sign_assetsNoIf True and catalog is Planetary Computer, sign asset URLs for direct access. Requires planetary-computer package.
output_formatNoOutput format ("text" or "json").text

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the tool searches for items, without mentioning return format, pagination, authentication, or effects of parameters like catalog_url and sign_assets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, but for a tool with 12 parameters and rich filtering capabilities, it underuses the opportunity to summarize key features. It is concise but not informative enough.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema and complex parameters, but the description fails to address usage context, alternatives, or behavioral expectations. This is a minimal description for a complex search tool, leaving significant gaps in understanding.

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 already fully documents all 12 parameters. The description adds no additional parameter semantics, but the baseline of 3 applies because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search for STAC items' uses a specific verb and resource, clearly indicating the tool's core function. However, it does not differentiate from sibling tools like search_collections or get_item, which also operate on STAC data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. Sibling tools such as search_collections and get_item exist, but no comparative context or exclusions are mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev6.5.0
    • Changedsearch_items6 fields changed
      • changedInput schema / properties / collections / anyOf
        Previous value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "string"
-  }
-]New value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / collections / default
        Added value: +null
      • addedInput schema / properties / ids
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of specific item IDs to retrieve."
+}
      • addedInput schema / properties / intersects
        Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "GeoJSON geometry for spatial intersection query."
+}
      • addedInput schema / properties / sortby
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Sort order (e.g., [\"-properties.datetime\"] for descending,\n    [\"+properties.datetime\"] for ascending)."
+}
      • removedInput schema / required
        Removed value: -[
-  "collections"
-]
  2. 11 tool updatesv6.3.0
    • Changedestimate_data_size1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_aggregations1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Addedget_capabilities
    • Changedget_collection1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Addedget_conformance
    • Changedget_item6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / catalog_url / description
        Added value: +"Optional catalog URL override."
      • addedInput schema / properties / collection_id / description
        Added value: +"The collection ID."
      • addedInput schema / properties / item_id / description
        Added value: +"The item ID."
      • addedInput schema / properties / output_format / description
        Added value: +"Output format (\"text\" or \"json\")."
      • addedInput schema / properties / sign_assets
        Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": false,
+  "description": "If True and catalog is Planetary Computer, sign asset URLs\n         for direct access. Requires planetary-computer package."
+}
    • Changedget_queryables1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_root1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_sensor_registry_info1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedsearch_collections1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedsearch_items10 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / bbox / description
        Added value: +"Bounding box [west, south, east, north] or GeoJSON geometry."
      • addedInput schema / properties / catalog_url / description
        Added value: +"Optional catalog URL override."
      • addedInput schema / properties / collections / description
        Added value: +"One or more collection IDs to search."
      • addedInput schema / properties / datetime / description
        Added value: +"Datetime filter (e.g., \"2020-01-01/2020-12-31\")."
      • addedInput schema / properties / fields
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "List of fields to include/exclude (e.g., [\"id\", \"properties.datetime\"]).\n    Prefix with \"-\" to exclude (e.g., [\"-properties.eo:cloud_cover\"])."
+}
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of items to return."
      • addedInput schema / properties / output_format / description
        Added value: +"Output format (\"text\" or \"json\")."
      • addedInput schema / properties / query / description
        Added value: +"Query filter for properties."
      • addedInput schema / properties / sign_assets
        Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": false,
+  "description": "If True and catalog is Planetary Computer, sign asset URLs\n         for direct access. Requires planetary-computer package."
+}
  3. 2 tool updatesv2.3.1
    • Removedget_conformance
    • Changedget_root1 field changed
      • addedInput schema / properties / catalog_url
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  4. 10 tool updatesv1.0.0
    • Changedestimate_data_size37 fields changed
      • addedInput schema / properties / aoi_geojson / anyOf
        Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / aoi_geojson / default
        Added value: +null
      • removedInput schema / properties / aoi_geojson / description
        Removed value: -"Area of Interest as GeoJSON geometry for clipping (will use smallest bbox between this and bbox parameter)"
      • removedInput schema / properties / aoi_geojson / type
        Removed value: -"object"
      • addedInput schema / properties / bbox / anyOf
        Added value: +[
+  {
+    "items": {
+      "type": "number"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / bbox / default
        Added value: +null
      • removedInput schema / properties / bbox / description
        Removed value: -"Bounding box [west, south, east, north] in WGS84"
      • removedInput schema / properties / bbox / items
        Removed value: -{
-  "type": "number"
-}
      • removedInput schema / properties / bbox / maxItems
        Removed value: -4
      • removedInput schema / properties / bbox / minItems
        Removed value: -4
      • removedInput schema / properties / bbox / type
        Removed value: -"array"
      • addedInput schema / properties / catalog_url / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / catalog_url / default
        Added value: +null
      • removedInput schema / properties / catalog_url / description
        Removed value: -"STAC catalog URL (optional, defaults to Microsoft Planetary Computer)"
      • removedInput schema / properties / catalog_url / type
        Removed value: -"string"
      • addedInput schema / properties / collections / anyOf
        Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  }
+]
      • removedInput schema / properties / collections / description
        Removed value: -"List of collection IDs to search within"
      • removedInput schema / properties / collections / items
        Removed value: -{
-  "type": "string"
-}
      • removedInput schema / properties / collections / type
        Removed value: -"array"
      • addedInput schema / properties / datetime / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / datetime / default
        Added value: +null
      • removedInput schema / properties / datetime / description
        Removed value: -"Date/time filter (ISO 8601 format, e.g., '2023-01-01/2023-12-31')"
      • removedInput schema / properties / datetime / type
        Removed value: -"string"
      • addedInput schema / properties / force_metadata_only
        Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": false
+}
      • addedInput schema / properties / limit / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • changedInput schema / properties / limit / default
        Previous value: -100New value: +10
      • removedInput schema / properties / limit / description
        Removed value: -"Maximum number of items to analyze for size estimation"
      • removedInput schema / properties / limit / maximum
        Removed value: -500
      • removedInput schema / properties / limit / minimum
        Removed value: -1
      • removedInput schema / properties / limit / type
        Removed value: -"integer"
      • addedInput schema / properties / output_format
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": "text"
+}
      • addedInput schema / properties / query / anyOf
        Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / query / default
        Added value: +null
      • removedInput schema / properties / query / description
        Removed value: -"Additional query parameters for filtering items"
      • removedInput schema / properties / query / type
        Removed value: -"object"
      • addedInput schema / required
        Added value: +[
+  "collections"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedget_aggregations
    • Changedget_collection6 fields changed
      • addedInput schema / properties / catalog_url / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / catalog_url / default
        Added value: +null
      • removedInput schema / properties / catalog_url / description
        Removed value: -"STAC catalog URL (optional, defaults to Microsoft Planetary Computer)"
      • removedInput schema / properties / catalog_url / type
        Removed value: -"string"
      • removedInput schema / properties / collection_id / description
        Removed value: -"ID of the collection to retrieve"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedget_conformance
    • Changedget_item8 fields changed
      • addedInput schema / properties / catalog_url / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / catalog_url / default
        Added value: +null
      • removedInput schema / properties / catalog_url / description
        Removed value: -"STAC catalog URL (optional, defaults to Microsoft Planetary Computer)"
      • removedInput schema / properties / catalog_url / type
        Removed value: -"string"
      • removedInput schema / properties / collection_id / description
        Removed value: -"ID of the collection containing the item"
      • removedInput schema / properties / item_id / description
        Removed value: -"ID of the item to retrieve"
      • addedInput schema / properties / output_format
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": "text"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Addedget_queryables
    • Addedget_root
    • Addedget_sensor_registry_info
    • Changedsearch_collections10 fields changed
      • addedInput schema / properties / catalog_url / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / catalog_url / default
        Added value: +null
      • removedInput schema / properties / catalog_url / description
        Removed value: -"STAC catalog URL (optional, defaults to Microsoft Planetary Computer)"
      • removedInput schema / properties / catalog_url / type
        Removed value: -"string"
      • addedInput schema / properties / limit / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / limit / description
        Removed value: -"Maximum number of collections to return"
      • removedInput schema / properties / limit / maximum
        Removed value: -100
      • removedInput schema / properties / limit / minimum
        Removed value: -1
      • removedInput schema / properties / limit / type
        Removed value: -"integer"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Changedsearch_items31 fields changed
      • addedInput schema / properties / bbox / anyOf
        Added value: +[
+  {
+    "items": {
+      "type": "number"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / bbox / default
        Added value: +null
      • removedInput schema / properties / bbox / description
        Removed value: -"Bounding box [west, south, east, north] in WGS84"
      • removedInput schema / properties / bbox / items
        Removed value: -{
-  "type": "number"
-}
      • removedInput schema / properties / bbox / maxItems
        Removed value: -4
      • removedInput schema / properties / bbox / minItems
        Removed value: -4
      • removedInput schema / properties / bbox / type
        Removed value: -"array"
      • addedInput schema / properties / catalog_url / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / catalog_url / default
        Added value: +null
      • removedInput schema / properties / catalog_url / description
        Removed value: -"STAC catalog URL (optional, defaults to Microsoft Planetary Computer)"
      • removedInput schema / properties / catalog_url / type
        Removed value: -"string"
      • addedInput schema / properties / collections / anyOf
        Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "string"
+  }
+]
      • removedInput schema / properties / collections / description
        Removed value: -"List of collection IDs to search within"
      • removedInput schema / properties / collections / items
        Removed value: -{
-  "type": "string"
-}
      • removedInput schema / properties / collections / type
        Removed value: -"array"
      • addedInput schema / properties / datetime / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / datetime / default
        Added value: +null
      • removedInput schema / properties / datetime / description
        Removed value: -"Date/time filter (ISO 8601 format, e.g., '2023-01-01/2023-12-31')"
      • removedInput schema / properties / datetime / type
        Removed value: -"string"
      • addedInput schema / properties / limit / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedInput schema / properties / limit / description
        Removed value: -"Maximum number of items to return"
      • removedInput schema / properties / limit / maximum
        Removed value: -100
      • removedInput schema / properties / limit / minimum
        Removed value: -1
      • removedInput schema / properties / limit / type
        Removed value: -"integer"
      • addedInput schema / properties / output_format
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": "text"
+}
      • addedInput schema / properties / query / anyOf
        Added value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / query / default
        Added value: +null
      • removedInput schema / properties / query / description
        Removed value: -"Additional query parameters for filtering items"
      • removedInput schema / properties / query / type
        Removed value: -"object"
      • addedInput schema / required
        Added value: +[
+  "collections"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
  5. 5 tool updates
    • First observedestimate_data_size
    • First observedget_collection
    • First observedget_item
    • First observedsearch_collections
    • First observedsearch_items
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation4/5

Most tools target distinct resources, but get_conformance and get_capabilities overlap in purpose (both describe server capabilities), and get_root also provides discovery metadata. This could cause confusion when an agent needs to determine what a server supports.

Naming Consistency4/5

Tool names generally follow a verb_noun pattern, but the pluralization is inconsistent (get_collection vs get_queryables, search_items vs get_item). The use of 'search' for listing collections/items is also slightly misleading, as it implies filtering rather than simple listing.

Tool Count5/5

With 11 tools, the set is well-scoped for a STAC API client. It covers discovery, collections, items, search, and additional metadata endpoints without being bloated or too sparse.

Completeness5/5

The tool set covers the standard read-only STAC API operations: root, conformance, capabilities, collections, items, search, queryables, and aggregations. There are no significant gaps for typical agent workflows, and write operations are not expected for a STAC catalog.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • SkyFi MCP Server

    Davaakhatan
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to interact with SkyFi's geospatial data services for ordering satellite imagery, searching data catalogs, checking pricing and feasibility, and monitoring areas of interest.
    11
    MIT

  • SkyFi MCP Server

    mfuechec
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI agents to search, order, and monitor satellite and geospatial imagery through SkyFi's API, including archive searches, pricing estimates, and order tracking.
    -

  • OpenLandMap MCP Server

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

  • source-coop-mcp

    yharby
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to discover and access 800TB+ of public geospatial data from Source Cooperative, with tools for listing organizations, products, files, and fuzzy search.
    6
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BnJam/stac-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server