This MCP server lets you search, inspect, and download Copernicus Sentinel satellite imagery (downloads require authentication).
Search images by region (point, polygon, or bbox), mission, satellite, date range, product type, processing level, and cloud-cover bounds.
Fetch a single image's full metadata and all available download links by ID.
Get mission capabilities and info for Sentinel-1/2/3/5P/6, including all missions at once.
List the most recent images over a region within the last N days.
Analyze temporal image coverage for a region, grouped by day/week/month.
Check whether one or more images are available for download.
Download a single image as a full product or a lightweight quicklook.
Batch-download many images concurrently with a configurable concurrency limit.
Search and download the best-matching image in one step.
Manage downloaded files: list them (filter by type), view download statistics, and clean up old/large files (dry-run by default).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Copernicus Earth Observation MCP Server Find Sentinel-2 images of Paris from last month with less than 10% cloud cover."
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.
An MCP server for Copernicus Sentinel data from the Copernicus Data Space Ecosystem (CDSE): search products and Sentinel-1 SLC bursts, inspect metadata, and download data with background jobs.
Missions: Sentinel-1, -2, -3, -5P, -6
Python: 3.13+
Auth: token-first (refresh token or access token), password grant as fallback
Search & discovery
Search by point / bounding box / polygon (GeoJSON or WKT), date range, and mission-specific filters (product type, processing level, satellite, cloud cover, orbit direction, relative orbit, Sentinel-2 tile, S1 mode/swath/ polarisation, or any catalogue attribute)
Real server-side filtering (cloud cover and attributes are filtered by the API, not silently dropped)
Recent products, temporal coverage analysis, full product metadata with checksums and quicklook URLs
Sentinel-1 SLC bursts
Search bursts by parent product, burst/absolute burst id, subswath, polarisation, mode, orbit, datatake, or area + time
Download bursts as zip via the CDSE on-demand extraction service (background job)
Downloads
Background download jobs (products, S1 native archives, quicklooks, bursts) with status, progress, speed, and cancellation — no more MCP tool timeouts on multi-GB products
Resumable downloads (HTTP Range), MD5 checksum verification
Quicklooks download synchronously (small, fast previews)
File management
List / statistics / cleanup of downloaded files, all confined to the configured download root (dry-run by default)
Related MCP server: GeoCroissant MCP Server
git clone <repository-url>
cd copernicus-mcp
uv venv -p 3.13 # or 3.14
uv pip install -e ".[dev]"A free account is required for downloads: https://dataspace.copernicus.eu/
Token-based authentication is primary. Configure one of:
Priority | Environment variable | Notes |
1 |
| Static bearer token, used as-is |
2 |
| Recommended. Access tokens are minted and renewed automatically |
3 |
| Password grant (legacy fallback) |
Search works without authentication; downloads require a token.
copernicus-mcp # stdio transport (default)
python -m copernicus_mcp # equivalent
copernicus-mcp --transport http --host 127.0.0.1 --port 8000
copernicus-mcp --log-level DEBUG --version{
"mcpServers": {
"copernicus": {
"command": "copernicus-mcp",
"env": {
"COPERNICUS_REFRESH_TOKEN": "<your-refresh-token>"
}
}
}
}Tool | Purpose |
| Search Sentinel products (geometry, dates, mission filters, attributes) |
| Full metadata, checksums, assets and download URLs for one product (by UUID or name) |
| Most recent products for an area |
| Temporal coverage analysis (counts per day/week/month/year) |
| Mission capabilities and supported filters |
Tool | Purpose |
| Search bursts (parent product, burst ids, swath, polarisation, orbit, area, time) |
| Burst raster metadata (Lines, SamplesPerBurst, ByteOffset, S3Path) |
| Start background on-demand burst extraction (zip) |
Tool | Purpose |
| Start a background job: |
| Synchronous quicklook download (small preview image) |
| Job status, progress %, bytes, speed, output path |
| All jobs, newest first |
| Cancel a queued/running job (partial data kept for resume) |
Tool | Purpose |
| List files in the download root |
| Totals and breakdowns by type / mission / month |
| Delete old or excess files (dry-run by default) |
1. search_products(geometry=[2.29, 48.85, 2.30, 48.86], mission="sentinel-2",
start_date="2024-06-01", end_date="2024-06-30",
max_cloud_cover=20)
2. get_product_details(image_id="<uuid from results>")
3. download_quicklook(image_id="<uuid>") # fast preview
4. start_download(image_id="<uuid>", kind="product") # background job
5. get_download_status(job_id="<job_id>")Variable | Default | Purpose |
|
| Download root (all file access is confined to it) |
|
| Parallel background downloads |
|
| Catalogue request timeout (seconds) |
|
| Download timeout (seconds) |
| CDSE catalogue | Override for testing |
copernicus_mcp/
├── server.py # FastMCP wiring + CLI
├── app.py # service container (built once per process)
├── config.py # settings from environment
├── auth.py # token manager (refresh/access token, password)
├── errors.py # exception hierarchy
├── odata/
│ ├── query.py # pure query builders (dates, geometry, filters)
│ ├── models.py # Product / Burst / Asset / Checksum models
│ └── client.py # async OData client (paging, retries)
├── downloads/
│ ├── manager.py # streaming, resume, checksums, path confinement
│ ├── jobs.py # background job manager
│ └── service.py # executes download jobs
└── tools/ # MCP tool implementationsNotes:
Queries follow the official CDSE OData syntax; see
docs/odata-quickref.md and the documentation
snapshots in docs/reference/.
Background jobs are in-memory: they do not survive a server restart (partial files stay on disk and are resumed on retry).
uv pip install -e ".[dev]"
pytest # unit + tool tests (no network; httpx.MockTransport)
ruff check copernicus_mcp testsdocker build -t copernicus-mcp .
docker run -i --rm -e COPERNICUS_REFRESH_TOKEN=<token> copernicus-mcp # stdio
docker run --rm -e COPERNICUS_REFRESH_TOKEN=<token> \
-v $PWD/downloads:/data/downloads -e COPERNICUS_DOWNLOAD_DIR=/data/downloads \
copernicus-mcp --transport http --host 0.0.0.0 --port 8000Scope: Sentinel collections only (SENTINEL-1/2/3/5P/6). Other CDSE collections (CCM, CLMS, COP-DEM, Landsat, ...) exist in the catalogue but are not exposed here.
Native archives (compressed): Sentinel-1 RAW/GRD/SLC, one month after
publication only.
Burst downloads use the CDSE on-demand extraction service and may take a
while; if the service is unavailable, get_burst_details provides the
S3Path/ByteOffset/Lines/SamplesPerBurst values needed for GDAL-based
extraction (see the Sentinel-1 SLC Bursts documentation).
Full products can be several GB — prefer quicklooks for previews.
LGPL-3.0-or-later (see LICENSE).
ESA and the Copernicus programme
The Copernicus Data Space Ecosystem for API access
Download multiple Copernicus satellite images concurrently. Requires authentication. WARNING: Full product batch downloads can take HOURS. Use download_type='quicklook' for testing.
| Name | Required | Description | Default |
|---|---|---|---|
| image_ids | Yes | ||
| mission | No | sentinel-2 | |
| download_type | No | full | |
| output_dir | No | ||
| max_concurrent | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and adds valuable behavioral context: it discloses authentication requirements, warns about long execution times for full downloads, and suggests a testing mode. However, it doesn't mention error handling, rate limits, or output specifics, leaving some gaps.
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?
Three sentences with zero waste: first states purpose, second covers authentication and critical warning, third provides usage tip. Each sentence earns its place, and information is front-loaded appropriately.
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 5 parameters with 0% schema coverage and no annotations, the description does well by covering authentication, timing, and a key parameter. With an output schema present, return values needn't be explained, but more parameter guidance would improve completeness for this complex tool.
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%, so the description must compensate. It explains 'download_type' with examples ('full' vs 'quicklook'), adding meaning beyond the schema. However, it doesn't clarify other parameters like 'mission' defaults or 'max_concurrent' limits, partially compensating for the coverage gap.
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 specific action ('Download multiple Copernicus satellite images concurrently'), resource ('images'), and scope ('concurrently'), distinguishing it from sibling tools like 'download_image' (singular) and 'search_and_download' (search-focused).
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?
Explicit guidance is provided: 'Use download_type='quicklook' for testing' indicates when to use a specific parameter value, and the warning about full downloads taking hours helps users decide when to use this tool versus alternatives like 'download_image' for single downloads or 'check_download_availability' for verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check satellite image coverage for a region over time
| Name | Required | Description | Default |
|---|---|---|---|
| geometry | Yes | ||
| start_date | Yes | ||
| end_date | Yes | ||
| geometry_type | No | polygon | |
| mission | No | sentinel-2 | |
| group_by | No | month |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states what the tool does but doesn't describe how it behaves—such as whether it's a read-only operation, what the output looks like, any rate limits, or authentication requirements. This is inadequate for a tool with 6 parameters and no annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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's complexity (6 parameters, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain parameter semantics or behavioral traits, though the output schema might cover return values. This leaves significant gaps for the agent to understand how to use the tool effectively.
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 description adds no meaning beyond the input schema, which has 0% description coverage. With 6 parameters (3 required) and no explanation in the description of what 'geometry', 'mission', or 'group_by' mean, the agent lacks crucial context for proper tool invocation.
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's purpose as checking satellite image coverage for a region over time, specifying the resource (satellite images) and action (check coverage). However, it doesn't differentiate from sibling tools like 'check_download_availability' or 'search_copernicus_images', which might have overlapping functionality.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'check_download_availability' and 'search_copernicus_images', there's no indication of when this coverage check is preferred, what prerequisites exist, 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.
Check if Copernicus satellite images are available for download
| Name | Required | Description | Default |
|---|---|---|---|
| image_ids | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the tool checks availability but does not describe what 'available' means (e.g., ready for immediate download, pending processing), potential rate limits, authentication needs, or the response format. This is a significant gap for a tool with no annotation coverage, making it inadequate for informed use.
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 a single, clear sentence with no wasted words. It is front-loaded with the core purpose and appropriately sized for the tool's apparent simplicity, making it easy to parse and understand quickly.
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's low complexity (1 parameter, no annotations, but has an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for detailed output explanation in the description. However, the lack of parameter details and behavioral context leaves gaps that could hinder effective tool selection and invocation.
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 1 parameter with 0% description coverage, and the tool description does not mention any parameters. It fails to explain what 'image_ids' are (e.g., format, source, or constraints), leaving the agent with no semantic understanding beyond the schema's structure. This is insufficient given the low schema coverage.
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's purpose: 'Check if Copernicus satellite images are available for download'. It specifies the verb ('check'), resource ('Copernicus satellite images'), and outcome ('available for download'). However, it does not explicitly differentiate from siblings like 'check_coverage' or 'get_download_statistics', which might involve similar checking operations, so it misses the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing specific image IDs, or suggest when to choose this over siblings like 'check_coverage' or 'get_download_statistics'. This lack of context leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean up downloaded files based on criteria
| Name | Required | Description | Default |
|---|---|---|---|
| download_dir | No | ||
| older_than_days | No | ||
| max_size_mb | No | ||
| file_type | No | ||
| dry_run | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'clean up' but doesn't disclose behavioral traits like whether files are permanently deleted, if it requires specific permissions, rate limits, or what the output includes. This is a significant gap for a tool that likely performs destructive operations.
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 a single, efficient sentence that is front-loaded and wastes no words. It's appropriately sized for conveying the basic purpose without unnecessary elaboration.
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 complexity of a cleanup tool with 5 parameters, no annotations, and an output schema (which might help but isn't described), the description is incomplete. It doesn't address key aspects like safety (e.g., dry-run default), behavioral outcomes, or parameter usage, making it inadequate for informed tool selection.
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?
With 0% schema description coverage for 5 parameters, the description adds no meaning beyond the schema. It mentions 'criteria' but doesn't explain what parameters like 'download_dir', 'older_than_days', or 'dry_run' do or how they interact. The description fails to compensate for the low schema coverage.
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 'Clean up downloaded files based on criteria' states the action (clean up) and resource (downloaded files), but it's vague about what 'clean up' entails (e.g., delete, move, archive) and doesn't differentiate from siblings like 'list_downloaded_files'. It's not tautological but lacks specificity.
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?
The description provides no guidance on when to use this tool versus alternatives, such as how it compares to 'list_downloaded_files' or other download-related tools. There's no mention of prerequisites, exclusions, or specific contexts for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a Copernicus satellite image by ID. Requires COPERNICUS_USERNAME and COPERNICUS_PASSWORD environment variables. WARNING: Full product downloads can take hours. Use download_type='quicklook' for testing.
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes | ||
| mission | No | sentinel-2 | |
| download_type | No | full | |
| output_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds significant behavioral context: it discloses authentication requirements (environment variables), performance characteristics ('can take hours'), and a testing recommendation. It does not cover aspects like error handling or output format, but provides more than minimal disclosure.
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 front-loaded with the core purpose, followed by critical prerequisites and warnings. Every sentence adds value: the first states the action, the second covers authentication, and the third provides usage guidance. No wasted words, and structure prioritizes essential information.
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 4 parameters with 0% schema coverage and no annotations, the description does well by covering authentication, performance, and key parameter usage. With an output schema present, return values need not be explained. It could improve by mentioning 'mission' or 'output_dir', but it's largely complete for a download tool.
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%, so the description must compensate. It explains the purpose of 'download_type' (with values 'full' and 'quicklook') and implies 'image_id' is required, adding meaning beyond the bare schema. It does not detail 'mission' or 'output_dir', but provides enough context for core functionality.
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 specific action ('Download') and resource ('Copernicus satellite image by ID'), distinguishing it from siblings like 'get_image_details' (metadata) or 'search_and_download' (search-based). It directly answers what the tool does without ambiguity.
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?
The description provides explicit context for when to use this tool: for downloading by ID, with a warning about time and a suggestion for testing. However, it does not explicitly state when to use alternatives like 'batch_download_images' for multiple images or 'search_and_download' for search-based downloads, leaving some sibling differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about downloaded Copernicus satellite images
| Name | Required | Description | Default |
|---|---|---|---|
| download_dir | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves statistics but doesn't disclose behavioral traits such as what data is included (e.g., counts, sizes, timestamps), whether it's read-only or has side effects, or any rate limits. This leaves significant gaps for a tool with potential complexity.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and one parameter, the description is minimal—it states what the tool does but lacks details on behavior, usage, or parameters. This is adequate for a simple tool but leaves room for improvement.
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%, so the description must compensate. It mentions 'downloaded Copernicus satellite images', which implies a context for the 'download_dir' parameter, but doesn't explain its purpose, format, or default behavior. Since there's only one optional parameter, the baseline is 4, but the lack of any parameter details in the description reduces it to 3.
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 action ('Get statistics') and resource ('downloaded Copernicus satellite images'), making the purpose understandable. However, it doesn't differentiate from siblings like 'list_downloaded_files' or 'get_recent_images' that might also provide related information, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_downloaded_files' and 'get_recent_images' that might overlap, there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive metadata for a specific satellite image including download URL
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes | ||
| mission | No | sentinel-2 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'comprehensive metadata' and 'download URL', but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. The description is minimal and lacks behavioral context beyond the basic output.
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 a single, efficient sentence that is front-loaded with the core purpose. There is no wasted language, and it directly communicates the tool's function without unnecessary elaboration, making it highly concise and well-structured.
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 complexity (a metadata retrieval tool with 2 parameters), no annotations, and an output schema (which likely covers return values), the description is partially complete. It states the purpose and key output but lacks parameter details and behavioral context. The output schema reduces the need to explain return values, but the description doesn't fully compensate for missing annotations and low schema coverage.
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 schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't explain the 'image_id' parameter (e.g., format or source) or the 'mission' parameter (e.g., purpose or valid values like 'sentinel-2'). The description adds no meaning beyond what the bare schema provides, failing to address the coverage gap.
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 action ('Get comprehensive metadata') and resource ('for a specific satellite image'), including the key output ('download URL'). It doesn't explicitly differentiate from siblings like 'get_mission_info' or 'get_product_download_links', but the focus on 'comprehensive metadata' for a single image is reasonably specific.
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 alternatives. For example, it doesn't mention when to choose 'get_image_details' over 'get_product_download_links' or 'get_recent_images', nor does it specify prerequisites like needing an image ID from another tool. The description implies usage for a 'specific satellite image' but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about Copernicus satellite missions
| Name | Required | Description | Default |
|---|---|---|---|
| mission | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the tool gets 'detailed information' but doesn't specify what that includes, whether it's read-only, if it requires authentication, or any rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and one parameter, the description is minimal—it states the purpose but lacks details on usage, parameters, and behavior, making it incomplete for effective agent use.
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%, and the description doesn't mention the 'mission' parameter at all. It fails to add any meaning beyond the schema, such as explaining what the parameter does, possible values, or default behavior when null. This is inadequate given the low schema coverage.
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 verb ('Get') and resource ('detailed information about Copernicus satellite missions'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'get_image_details' or 'get_product_download_links', which also retrieve information about Copernicus data, so it misses full sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_image_details' and 'get_product_download_links' that might retrieve overlapping information, there's no indication of context, exclusions, or prerequisites for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available download links for a Copernicus satellite image
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what happens if the image_id is invalid. This leaves significant gaps for a tool that likely interacts with external services.
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 a single, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded and efficiently communicates the core purpose, making it easy for an agent to parse quickly.
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 (which likely describes the download links), the description doesn't need to explain return values. However, with no annotations and low schema coverage for the single parameter, the description provides minimal context about behavior and usage, making it adequate but incomplete for safe and effective tool invocation.
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 description mentions 'a Copernicus satellite image', which implies the 'image_id' parameter should correspond to such an image, adding some context beyond the schema's 0% coverage. However, it doesn't specify the format or source of the image_id, leaving ambiguity. With low schema coverage, this partial compensation earns a baseline score.
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 verb ('Get') and resource ('download links for a Copernicus satellite image'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'check_download_availability' or 'download_image', which could provide similar functionality, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives such as 'check_download_availability' or 'download_image'. It lacks context on prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent satellite images for a region
| Name | Required | Description | Default |
|---|---|---|---|
| geometry | Yes | ||
| geometry_type | No | point | |
| mission | No | sentinel-2 | |
| days_back | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'most recent' but doesn't disclose behavioral traits like whether results are paginated, if there are rate limits, authentication requirements, or what the output contains. For a tool with 5 parameters and no annotations, this is a significant gap.
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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the core functionality without unnecessary elaboration.
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 5 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks parameter explanations, usage context, and behavioral details. The output schema mitigates some gaps, but overall it's minimally adequate with clear deficiencies.
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%, so the description must compensate. It only mentions 'region' which loosely maps to 'geometry', but doesn't explain the 5 parameters (geometry, geometry_type, mission, days_back, max_results) or their purposes. The description adds minimal value beyond the 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 action ('Get') and resource ('most recent satellite images for a region'), making the purpose understandable. It distinguishes from siblings like 'download_image' or 'get_image_details' by focusing on recent images, but doesn't explicitly contrast with similar tools like 'search_copernicus_images'.
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 alternatives. With siblings like 'search_copernicus_images' and 'check_coverage', the description doesn't indicate whether this is for quick recent image retrieval versus more comprehensive searches or coverage checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List downloaded Copernicus satellite image files
| Name | Required | Description | Default |
|---|---|---|---|
| download_dir | No | ||
| file_type | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists files, implying a read-only operation, but doesn't specify critical behaviors such as whether it requires specific permissions, how it handles large directories (e.g., pagination via the 'limit' parameter), what the output format is (though an output schema exists), or if it's safe for concurrent use. The description adds minimal value beyond the basic action.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It avoids redundancy and wastes no space, making it easy to parse quickly. Every part of the sentence directly contributes to understanding the tool's function.
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's moderate complexity (3 parameters, no annotations, but with an output schema), the description is incomplete. It adequately states the purpose but lacks usage guidelines, parameter explanations, and behavioral details. The presence of an output schema mitigates the need to describe return values, but other gaps remain significant. This is a minimal viable description with clear room for improvement.
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%, meaning parameters are undocumented in the schema. The description does not mention any parameters, failing to compensate for this gap. It doesn't explain what 'download_dir', 'file_type', or 'limit' do, their expected formats (e.g., directory paths, file extensions like 'JPEG'), or default behaviors. This leaves the agent guessing about parameter usage.
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 action ('List') and the resource ('downloaded Copernicus satellite image files'), making the purpose immediately understandable. It distinguishes from siblings like 'get_download_statistics' or 'get_image_details' by focusing on listing files rather than metadata or statistics. However, it doesn't explicitly differentiate from 'get_recent_images' or 'search_copernicus_images' in terms of scope (downloaded vs. available).
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., files must be downloaded first), exclusions (e.g., not for searching available images), or comparisons to siblings like 'get_recent_images' (which might list recent images regardless of download status) or 'cleanup_downloads' (which manages files). This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Copernicus satellite images and download the best match. WARNING: Full product downloads can take HOURS. Use download_type='quicklook' for testing.
| Name | Required | Description | Default |
|---|---|---|---|
| geometry | Yes | ||
| geometry_type | No | point | |
| mission | No | sentinel-2 | |
| start_date | No | ||
| end_date | No | ||
| max_cloud_cover | No | ||
| download_type | No | quicklook | |
| output_dir | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing critical behavioral traits: the warning about 'HOURS' for full downloads and the recommendation for 'quicklook' testing. It doesn't cover all potential behaviors like error handling or authentication needs, but adds significant value beyond basic purpose.
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 perfectly front-loaded with the core purpose in the first sentence, followed by a critical warning and practical tip in the second. Every sentence earns its place with no wasted words, making it highly efficient and well-structured.
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's complexity (9 parameters, no annotations, but with an output schema), the description is partially complete. It covers the core purpose and critical behavioral warnings well, but the lack of parameter explanations and sibling tool differentiation leaves gaps that could hinder effective use despite the output schema handling return values.
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?
With 0% schema description coverage for 9 parameters, the description only mentions 'download_type' explicitly and implies 'geometry' through context. It doesn't explain the meaning or usage of other parameters like 'mission', 'max_cloud_cover', or 'output_dir', failing to compensate for the schema's lack of descriptions.
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's purpose with specific verbs ('search' and 'download') and resources ('Copernicus satellite images'), and distinguishes it from siblings by mentioning it finds and downloads 'the best match' rather than just searching or downloading separately.
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?
The description provides clear context on when to use the tool (for searching and downloading images) and includes a warning about long download times with a recommendation to use 'quicklook' for testing, but it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Copernicus satellite images for a given region
| Name | Required | Description | Default |
|---|---|---|---|
| geometry | Yes | Geometry as polygon coordinates [[lon, lat], ...] or GeoJSON polygon [[[lon, lat], ...]] or point [lon, lat] or bbox [min_lon, min_lat, max_lon, max_lat] | |
| geometry_type | No | Type of geometry: 'point', 'polygon', or 'bbox' | polygon |
| mission | No | Mission name: 'sentinel-1', 'sentinel-2', 'sentinel-3', 'sentinel-5p', 'sentinel-6' | sentinel-2 |
| processing_level | No | Processing level (e.g., 'L2A' for Sentinel-2, 'GRD' for Sentinel-1) | |
| product_type | No | Product type (e.g., 'MSI' for Sentinel-2, 'IW' for Sentinel-1) | |
| satellite | No | Specific satellite (e.g., 'Sentinel-2A', 'Sentinel-1A') | |
| start_date | No | Start date (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS) | |
| end_date | No | End date (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS) | |
| min_cloud_cover | No | Minimum cloud cover percentage (for optical missions) | |
| max_cloud_cover | No | Maximum cloud cover percentage (for optical missions) | |
| max_results | No | Maximum number of results to return |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states the tool searches but doesn't describe key behaviors like whether it returns metadata or actual images, pagination handling, rate limits, authentication needs, or error conditions. For a search tool with 11 parameters, this lack of behavioral context is a significant gap.
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 a single, clear sentence with zero waste: 'Search for Copernicus satellite images for a given region.' It's front-loaded with the core purpose and appropriately sized for its function, making it easy to parse quickly.
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 complexity (11 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose but lacks behavioral details and usage guidelines. The output schema likely covers return values, reducing the need for that in the description, but the absence of annotations means more behavioral context would be beneficial for a tool of this scope.
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 schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying a 'region' search (which aligns with the 'geometry' parameter). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose: 'Search for Copernicus satellite images for a given region.' It specifies the action ('Search') and resource ('Copernicus satellite images') with a scope ('for a given region'). However, it doesn't explicitly differentiate from siblings like 'search_and_download' or 'get_recent_images', which would require mentioning it only searches without downloading or filtering by recency.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'search_and_download' (which might combine search with download) or 'get_recent_images' (which might focus on recent data without custom search parameters). Without such context, an agent might struggle to choose between similar tools.
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.
v0.1.0batch_download_imagescheck_coveragecheck_download_availabilitycleanup_downloadsdownload_imageget_download_statisticsget_image_detailsget_mission_infoget_product_download_linksget_recent_imageslist_downloaded_filessearch_and_downloadsearch_copernicus_imagesScored across 13 tools
Most tools have distinct purposes, but there is significant overlap between search_copernicus_images and search_and_download, and between download_image and batch_download_images, which could cause confusion. However, descriptions clarify differences like batch vs. single downloads.
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., check_coverage, download_image, get_image_details). There are no deviations in naming conventions.
With 13 tools, the count is well-scoped for an Earth observation server, covering search, download, metadata, and file management without being overwhelming. Each tool serves a specific role in the workflow.
The toolset provides comprehensive coverage for satellite image workflows, including search, download, metadata retrieval, and file management. Minor gaps might include advanced filtering or real-time monitoring, but core operations are well-covered.
European Sentinel and Copernicus Contributing Mission archive from the EU's Copernicus Data Space…
Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
Sentinel and Landsat imagery catalogue from Element 84's Earth Search over the AWS Open Data…
Earth-observation imagery catalogue from Microsoft's Planetary Computer — search its open…