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.
A comprehensive Model Context Protocol (MCP) server for accessing Copernicus Earth Observation data from the Copernicus Data Space ecosystem. This server provides a complete suite of tools for searching, downloading, and managing satellite imagery from all Copernicus Sentinel missions.
Multi-Mission Support: Access data from Sentinel-1, Sentinel-2, Sentinel-3, Sentinel-5P, and Sentinel-6 missions
Advanced Search: Search by location (point, polygon, bounding box), date range, cloud cover, and mission-specific parameters
Coverage Analysis: Analyze temporal coverage and availability of satellite data for specific regions
Recent Images: Get the most recent satellite images for monitoring and change detection
Comprehensive Metadata: Retrieve detailed image metadata including acquisition details, processing levels, and technical specifications
Related MCP server: STAC MCP Server
Image Download: Download full products, quicklook previews, and compressed versions of satellite images
Batch Operations: Download multiple images concurrently with configurable concurrency limits
Intelligent Selection: Automatic best-image selection based on recency, cloud cover, and processing level
Availability Checking: Verify download availability and get file size information before downloading
Download Links: Get all available download URLs for any satellite image
File Listing: List and analyze downloaded files with filtering by type, size, and date
Statistics: Get comprehensive statistics about downloaded files (by mission, file type, time period)
Automated Cleanup: Clean up old or large downloads with age-based and size-based strategies
Dry Run Mode: Safety-first approach with preview of cleanup actions before execution
Mission | Type | Primary Applications | Resolution | Revisit Time |
Sentinel-1 | Synthetic Aperture Radar (SAR) | Disaster monitoring, sea ice tracking, land subsidence | 5-40m | 6-12 days |
Sentinel-2 | Multispectral Imaging | Agriculture, vegetation monitoring, urban planning | 10-60m | 5 days |
Sentinel-3 | Ocean & Land Monitoring | Ocean color, sea surface temperature, fire detection | 300-1200m | <2 days |
Sentinel-5P | Atmospheric Monitoring | Air quality, ozone layer, greenhouse gas tracking | 7.5Ć3.5km | Daily |
Sentinel-6 | Ocean Topography | Sea level rise, ocean circulation, climate research | 300m | 10 days |
Python 3.11 or higher
pip package manager
Copernicus Data Space account (free registration required)
Clone the repository:
git clone <repository-url>
cd copernicus-mcpInstall dependencies:
pip install -r requirements.txtInstall in development mode:
pip install -e .Set up authentication:
# Linux/Mac
export COPERNICUS_USERNAME="your-email@example.com"
export COPERNICUS_PASSWORD="your-password"
# Windows (Command Prompt)
set COPERNICUS_USERNAME=your-email@example.com
set COPERNICUS_PASSWORD=your-password
# Windows (PowerShell)
$env:COPERNICUS_USERNAME="your-email@example.com"
$env:COPERNICUS_PASSWORD="your-password"or in MCP Client...
{
"mcpServers": {
"copernicus": {
"command": "copernicus-mcp",
"env": {
"COPERNICUS_USERNAME": "your-email@example.com",
"COPERNICUS_PASSWORD": "your-password"
}
}
}
}Register for free at: https://dataspace.copernicus.eu/
Verify your credentials work:
python -c "
import asyncio
import os
from copernicus_mcp.server import get_auth_token
async def test():
result = await get_auth_token()
if isinstance(result, dict) and 'access_token' in result:
print('ā
Authentication successful!')
print(f'Token length: {len(result[\"access_token\"])} characters')
else:
print(f'ā Authentication failed: {result.get(\"error\", \"Unknown error\")}')
asyncio.run(test())
"# Run the MCP server
python -m copernicus_mcp
# Or using the module directly
python -m copernicus_mcp.server# Show version
python -m copernicus_mcp --version
# Show help
python -m copernicus_mcp --helpVariable | Description | Required For |
| Copernicus Data Space email | Download operations |
| Copernicus Data Space password | Download operations |
| Enable authentication debugging | Debugging |
| Enable real download tests | Testing |
Downloads: downloads/ (individual downloads)
Batch Downloads: batch_downloads/ (batch operations)
Search Results: search_downloads/ (search_and_download)
Max Concurrent Downloads: 3 (configurable in batch_download_images)
API Timeout: 60 seconds
Download Chunk Size: 8KB
Token Cache: 4 minutes (with 1-minute buffer)
copernicus-mcp/
āāā copernicus_mcp/ # Main package
ā āāā server.py # Complete server implementation
ā āāā __init__.py # Package exports
ā āāā server_corrupted_backup.py # Backup
āāā examples/ # Usage examples
ā āāā example_download_usage.py
āāā requirements.txt # Python dependencies
āāā pyproject.toml # Project configuration
āāā README.md # This file
āāā mcp_config.json # MCP client configuration
āāā INSTALL.md # Installation guideAuthentication Manager: Handles token acquisition, caching, and refresh
Search Engine: Advanced query builder for Copernicus Data Space API
Download Manager: Concurrent downloads with progress tracking
File Manager: Disk space management and cleanup
MCP Interface: FastMCP-based tool registration and protocol handling
search_copernicus_imagesSearch for satellite images from Copernicus missions.
Parameters:
geometry: GeoJSON polygon coordinates, point [lon, lat], or bbox [min_lon, min_lat, max_lon, max_lat]
geometry_type: 'point', 'polygon', or 'bbox'
mission: Mission name ('sentinel-1', 'sentinel-2', 'sentinel-3', 'sentinel-5p', 'sentinel-6')
start_date, end_date: Date range (YYYY-MM-DD)
max_cloud_cover: Maximum cloud cover percentage (0-100, optical missions only)
max_results: Maximum number of results (1-1000)
Example:
# Search for Sentinel-2 images over Paris
search_copernicus_images(
geometry=[[2.2945, 48.8584], [2.2945, 48.8604], [2.2965, 48.8604], [2.2965, 48.8584]],
geometry_type="polygon",
mission="sentinel-2",
start_date="2024-01-01",
end_date="2024-01-31",
max_cloud_cover=20,
max_results=10
)get_image_detailsGet comprehensive metadata for a specific satellite image.
Parameters:
image_id: Satellite image ID (from search results)
mission: Optional mission name
Returns: Detailed metadata including download URLs, processing level, cloud cover, footprint, and authentication guidance.
get_mission_infoGet detailed information about Copernicus satellite missions.
Parameters:
mission: Optional specific mission name
Returns: Mission capabilities, sensors, applications, resolution, and revisit time.
get_recent_imagesGet the most recent satellite images for a region.
Parameters:
geometry: Location coordinates
geometry_type: 'point', 'polygon', or 'bbox'
mission: Mission name
days_back: Number of days to look back (default: 7)
max_results: Maximum results (default: 10)
check_coverageAnalyze satellite image coverage for a region over time.
Parameters:
geometry: Location coordinates
geometry_type: 'point', 'polygon', or 'bbox'
mission: Mission name
start_date, end_date: Analysis period
group_by: Group results by 'day', 'week', 'month', or 'year'
download_imageDownload a Copernicus satellite image by ID.
Parameters:
image_id: Image ID from search results (required)
mission: Mission name (default: 'sentinel-2')
download_type: 'full', 'quicklook', or 'compressed' (default: 'full')
output_dir: Custom output directory (default: 'downloads')
Example:
# Download a quicklook preview
download_image(
image_id="S2B_MSIL2A_20240115T105629_N0510_R094_T31UCS_20240115T130259",
mission="sentinel-2",
download_type="quicklook"
)
# Download full product
download_image(
image_id="S2B_MSIL2A_20240115T105629_N0510_R094_T31UCS_20240115T130259",
mission="sentinel-2",
download_type="full"
)batch_download_imagesDownload multiple images concurrently.
Parameters:
image_ids: List of image IDs to download
mission: Mission name (default: 'sentinel-2')
download_type: 'full', 'quicklook', or 'compressed' (default: 'full')
output_dir: Output directory (default: 'batch_downloads')
max_concurrent: Maximum concurrent downloads (default: 3)
Example:
batch_download_images(
image_ids=["id1", "id2", "id3"],
mission="sentinel-2",
download_type="quicklook",
max_concurrent=2
)search_and_downloadSearch for images and automatically download the best match.
Parameters:
geometry: Location coordinates
geometry_type: 'point', 'polygon', or 'bbox' (default: 'point')
mission: Mission name (default: 'sentinel-2')
start_date, end_date: Search date range
max_cloud_cover: Maximum cloud cover percentage
download_type: 'full', 'quicklook', or 'compressed' (default: 'quicklook')
output_dir: Output directory
limit: Maximum search results to consider (default: 5)
Example:
# Search and download best image
search_and_download(
geometry=[-122.4194, 37.7749], # San Francisco
geometry_type="point",
mission="sentinel-2",
start_date="2024-01-01",
end_date="2024-01-31",
download_type="quicklook"
)check_download_availabilityCheck if images are available for download.
Parameters:
image_ids: List of image IDs to check
Returns: Availability status, file sizes, and quicklook availability for each image.
get_product_download_linksGet all available download links for an image.
Parameters:
image_id: Image ID
Returns: All download URLs (full, compressed, quicklooks) with metadata.
list_downloaded_filesList downloaded satellite image files.
Parameters:
download_dir: Directory to scan (default: 'downloads')
file_type: Filter by 'full', 'quicklook', 'compressed', or None for all
limit: Maximum files to return (default: 50)
Example:
list_downloaded_files(
download_dir="my_downloads",
file_type="quicklook",
limit=10
)cleanup_downloadsClean up downloaded files based on criteria.
Parameters:
download_dir: Directory to clean (default: 'downloads')
older_than_days: Remove files older than X days
max_size_mb: Keep total size under X MB (removes oldest first)
file_type: Filter by file type
dry_run: Only show what would be deleted (default: True)
Example:
# Dry run - see what would be deleted
cleanup_downloads(
download_dir="downloads",
older_than_days=30,
dry_run=True
)
# Actually delete files older than 30 days
cleanup_downloads(
download_dir="downloads",
older_than_days=30,
dry_run=False
)
# Keep total size under 10GB
cleanup_downloads(
download_dir="downloads",
max_size_mb=10240,
dry_run=False
)get_download_statisticsGet statistics about downloaded files.
Parameters:
download_dir: Directory to analyze (default: 'downloads')
Returns: Comprehensive statistics including total files, size, breakdown by mission/file type/month, and oldest/newest files.
# 1. Search for images
search_results = search_copernicus_images(
geometry=[-122.4194, 37.7749], # San Francisco
geometry_type="point",
mission="sentinel-2",
start_date="2024-01-01",
end_date="2024-01-31",
max_cloud_cover=30,
max_results=5
)
# 2. Extract image IDs
image_ids = [img["Id"] for img in search_results.get("products", [])]
# 3. Check availability
availability = check_download_availability(image_ids[:2])
# 4. Download quicklooks for available images
for image_id in image_ids[:2]:
download_image(
image_id=image_id,
mission="sentinel-2",
download_type="quicklook"
)
# 5. List downloaded files
files = list_downloaded_files(
download_dir="downloads",
file_type="quicklook"
)
# 6. Get statistics
stats = get_download_statistics()Mission information
Basic search operations
Metadata retrieval
Image downloads (full, quicklook, compressed)
Batch downloads
Availability checks
Download link retrieval
Automatic token acquisition from Copernicus Identity Service
Token caching with expiration handling
Graceful error handling for invalid credentials
Support for both environment variables and parameter-based authentication
The server includes comprehensive error handling for:
Missing credentials
Invalid credentials
Token expiration
Rate limiting
Invalid image IDs
Unavailable products
Network timeouts
API quota exceeded
Insufficient disk space
Permission denied
Invalid file paths
Corrupted downloads
Invalid geometry formats
Unsupported mission parameters
Date range errors
Invalid download types
Progress Reporting: Updates every 10 seconds or 100MB
Extended Timeouts: Up to 2 hours for large downloads
Chunk Size: 1MB chunks for optimal throughput
Concurrent Downloads: Configurable (default: 3 concurrent)
The server uses appropriate timeouts for different operations:
Small files (quicklooks): 2 minutes
Medium files (compressed): 1 hour
Large files (full products): 2 hours
API requests: 1 minute
All progress sent to stderr with regular flushing
Clients must monitor stderr for progress updates
Connection kept alive through periodic output
Quicklooks: 100KB - 1MB (recommended for testing)
Compressed Products: 100MB - 1GB
Full Products: 1GB - 10GB+ (varies by mission)
Start with quicklook downloads for testing
Use max_concurrent to control bandwidth usage
Monitor disk space for large downloads
Never hardcode credentials in code
Use environment variables or secure credential stores
Tokens are automatically refreshed and never stored permanently
All authentication errors are logged without exposing sensitive information
All API calls use HTTPS with proper certificate validation
Timeout settings prevent hanging connections
Downloaded files use standard file permissions
No automatic execution of downloaded content
Cleanup operations require explicit confirmation (dry-run mode by default)
# Test timeout fixes
python test_download_timeout.py
# Test with example downloads
python example_download_usage.py# Check if credentials are set
echo $COPERNICUS_USERNAME
echo $COPERNICUS_PASSWORD
# Test authentication directly
python -c "
import asyncio
from copernicus_mcp.server import get_auth_token
async def test():
result = await get_auth_token()
print('Result:', result)
asyncio.run(test())
"Check disk space: Ensure you have sufficient space for downloads
Verify image ID: Use valid IDs from search results
Try quicklook first: Test with smaller files before downloading full products
Check network: Ensure stable internet connection
Date range: Use reasonable date ranges (e.g., last 30 days)
Geometry size: Keep search areas manageable
Cloud cover: Adjust cloud cover filters for optical missions
Enable debug logging for detailed information:
export COPERNICUS_DEBUG_AUTH=true
python -m copernicus_mcpCheck application logs for detailed error messages
Monitor download progress in real-time
Review cleanup operations before execution
Zed IDE (and other MCP clients) expect MCP tools to complete quickly (typically within 30-60 seconds). However, full satellite image downloads might take hours to complete. This mismatch causes Zed to kill download processes prematurely. you can increase MCP Tool timeout in Zed settings.
European Space Agency (ESA) for the Copernicus program
Copernicus Data Space Ecosystem for providing API access
European Commission for funding and support
FastMCP framework for MCP server implementation
httpx for async HTTP client functionality
pydantic for data validation and serialization
shapely for geometric operations
Complete workflow examples in example_download_usage.py
Configuration examples in mcp_config.json
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.
Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
Search dynamical.org's open STAC catalog of weather & climate datasets (GFS, ECMWF, HRRR).
Geospatial AI MCP server ā satellite imagery, embeddings, weather, GNS governance
Find recent or archived satellite imagery for any place on Earth by location and date.
