Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Planetary Computer MCP Server show me sentinel-2 imagery of San Francisco"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python implementation of the Planetary Computer MCP server, providing unified access to satellite and geospatial data through natural language queries.
Related MCP server: Google Earth Engine MCP Server
Unified Interface: Single download_data tool that automatically detects datasets from natural language queries
Natural Language Geocoding: Automatically converts place names (e.g., "San Francisco", "the Alps", "Amazon rainforest") to geospatial bounding box coordinates using the Nominatim geocoding service—no need to manually specify coordinates
Multi-format Support: Raster (GeoTIFF), Vector (GeoParquet), and Zarr data
Automatic Visualization: Generate RGB/JPEG previews for LLM analysis
Fast Downloads: Uses odc-stac for efficient COG access
uv syncpython -m planetary_computer_mcp.serverfrom planetary_computer_mcp.tools.download_data import download_data
# Download Sentinel-2 data for San Francisco
result = download_data(
query="sentinel-2 imagery",
aoi="San Francisco",
time_range="2024-01-01/2024-01-31"
)
print(f"Raw data: {result['raw']}")
print(f"Visualization: {result['visualization']}")Unified tool for raster, DEM, land cover, and climate data.
Parameters:
query: Natural language query (e.g., "sentinel-2", "elevation data")
aoi: Bounding box [W,S,E,N] or place name
time_range: ISO8601 datetime range
max_cloud_cover: Maximum cloud cover (optical data)
Returns:
Raw GeoTIFF/Zarr/Parquet file
RGB/JPEG visualization
Metadata
Tool for vector/building data.
Parameters:
collection: Collection ID (e.g., "ms-buildings")
aoi: Bounding box or place name
limit: Maximum features
Returns:
GeoParquet file
Map visualization
Feature count
See collections.md for the complete list of supported datasets.
uv sync --devuv run pytestuv run pre-commit run --all-filessrc/
├── core/ # Core utilities
│ ├── stac_client.py # STAC search wrapper
│ ├── geocoding.py # Place name → bbox
│ ├── collections.py # Dataset metadata
│ ├── raster_utils.py # odc-stac helpers
│ ├── vector_utils.py # DuckDB helpers
│ ├── visualization.py # Matplotlib viz
│ └── zarr_utils.py # Xarray Zarr helpers
├── tools/ # MCP tools
│ ├── download_data.py
│ └── download_geometries.py
└── server.py # MCP server entry pointApache 2.0 License
Download satellite/raster data from Microsoft Planetary Computer.
Automatically detects collection from natural language queries, handles geocoding for place names, downloads and crops data, generates RGB visualizations.
query : str Natural language query describing the data you want. Examples: "sentinel-2 imagery", "landsat", "naip aerial photos", "elevation data", "land cover" aoi : str or list[float] Required. Area of interest as either: - Place name string: "Seattle, WA", "Paris, France", "Central Park, NY" - Bounding box list: [west, south, east, north] in degrees Example: [-122.4, 47.5, -122.3, 47.6] time_range : str or None, optional ISO8601 datetime range. Defaults to last 7 days if not provided. Examples: "2024-01-01/2024-01-31", "2024-06-01/2024-06-30" output_dir : str, optional Directory to save outputs. Defaults to current directory. max_cloud_cover : int, optional Maximum cloud cover percentage for optical data (0-100). Default: 20
list[TextContent] File paths and metadata
Download recent Sentinel-2 imagery of Paris: query="sentinel-2 imagery", aoi="Paris, France"
Download Landsat for a specific bbox and time: query="landsat", aoi=[-122.4, 47.5, -122.3, 47.6], time_range="2024-06-01/2024-06-30"
Download NAIP aerial imagery: query="naip aerial photos", aoi="Central Park, NY"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| aoi | Yes | ||
| time_range | No | ||
| output_dir | No | . | |
| max_cloud_cover | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: automatic collection detection, geocoding, cropping, and RGB visualization. It also mentions the output directory default. However, it omits important traits such as overwrite behavior, disk usage, network requirements, and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for general description, parameters, returns, and examples. It is front-loaded with the core purpose. While detailed, it avoids repetition and unnecessary content; minor improvements could tighten the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (mentioned in context) and 5 parameters, the description covers the main functionality but lacks operational context such as rate limits, data size restrictions, internet requirements, and error handling. More completeness would benefit an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates. Each parameter is explained with types, defaults, and concrete examples (e.g., aoi accepts place names or bboxes, time_range format). This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads satellite/raster data from Microsoft Planetary Computer and mentions automatic collection detection, geocoding, and visualization. However, it does not explicitly contrast with the sibling tool (download_geometries_tool), which would strengthen purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling or alternatives. There is no mention of prerequisites, constraints, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download vector geometries from Planetary Computer.
collection : str Collection ID (e.g., "ms-buildings") aoi : list[float] or str Bounding box [W,S,E,N] or place name string output_dir : str, optional Directory to save outputs
list[TextContent] File paths and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | ||
| aoi | Yes | ||
| output_dir | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Download vector geometries' without disclosing side effects (e.g., file creation, overwrite behavior), authentication needs, or idempotency. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise docstring format with clear sections (description, parameters, returns). Purpose is front-loaded. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters and returns, but lacks details such as output file format (GeoJSON, Shapefile?), behavior for missing directories, and how it compares to sibling tool. Adequate but incomplete for a download operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds significant meaning: gives example for collection ('ms-buildings'), clarifies aoi as bbox or place name, and documents output_dir default. Greatly enhances schema bare data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Download vector geometries from Planetary Computer' with specific verb and resource. Distinguishes from sibling download_data_tool by specifying vector geometries, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter details but no guidance on when to use this tool versus the sibling download_data_tool, nor any prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.3download_data_tooldownload_geometries_toolBoth tools have clearly distinct purposes: one for raster satellite data with natural language querying, and one for vector geometries with a collection ID. No overlap in functionality.
Both tools follow a consistent download_<type>_tool pattern using snake_case, making the naming predictable and clear.
With only 2 tools, the server feels very thin for the broad scope of Microsoft Planetary Computer. Even a minimal interface would benefit from additional tools like listing collections or searching items.
The server covers raster and vector data downloads but lacks critical supporting operations such as querying available collections, filtering items, or exploring data metadata. Users must know collection IDs or rely on natural language detection without discovery tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
Geospatial MCP server for earthquake, tsunami, volcano, disaster, and FX data queries.
GibsonAI MCP server: manage your databases with natural language
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/isaaccorley/planetary-computer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
