space-finder-mcp

Overview Schema Source Related Servers Discussions Admin

copernicus_search

Search ESA Copernicus Sentinel satellite imagery by collection, area, date range, and cloud cover to find scenes for Earth observation analysis.

Instructions

ESA Copernicus（Sentinel ほか）の衛星画像を STAC で検索する（検索は認証不要）。

例:「東京のSentinel-2画像」「関東の最近の衛星画像」

Args: collection: STAC コレクションID（既定 "sentinel-2-l2a"）。copernicus_collections で確認可。 bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"、例東京: "139.6,35.5,139.9,35.8"）。 datetime: 時間範囲（"YYYY-MM-DD" または "start/end"、例 "2026-01-01/2026-03-31"）。省略で最新。 max_cloud_cover: 雲量の上限（%）（Sentinel-2 等 eo:cloud_cover を持つ場合）。 limit: 返す件数（既定 5、最大 10）。

Input Schema

Name	Required	Default
`bbox`	No
`limit`	No
`datetime`	No
`collection`	No	sentinel-2-l2a
`max_cloud_cover`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv0.41.4Oct 23, 2026
- removedInput schema / properties / bbox / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / bbox / default
```
Removed value: -null
```
- removedInput schema / properties / bbox / title
```
Removed value: -"Bbox"
```
- addedInput schema / properties / bbox / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / collection / title
```
Removed value: -"Collection"
```
- removedInput schema / properties / datetime / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / datetime / default
```
Removed value: -null
```
- removedInput schema / properties / datetime / title
```
Removed value: -"Datetime"
```
- addedInput schema / properties / datetime / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / max_cloud_cover / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / max_cloud_cover / default
```
Removed value: -null
```
- removedInput schema / properties / max_cloud_cover / title
```
Removed value: -"Max Cloud Cover"
```
- addedInput schema / properties / max_cloud_cover / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedInput schema / title
```
Removed value: -"copernicus_searchArguments"
```
Addedv0.25.2Sep 12, 2026

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral load; it delivers useful facts — no auth needed, default collection sentinel-2-l2a, limit max 10, datetime omitted means latest. It is silent on the return shape (STAC items/assets), pagination beyond limit, and rate limits, which matters for a search tool with no output schema.

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

Conciseness5/5

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

An opening sentence with scope plus the auth note, then a tight Args block where each line earns its place by supplying format or default. Nothing is repeated from structured fields needlessly and the key constraint (no auth) is front-loaded.

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

Completeness4/5

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

For a five-parameter, output-schema-less search tool, the definition covers input formats, defaults, and the auth profile well. The remaining gap is response description — what a result item contains and how to page past the 10-result cap — which an agent would have to discover empirically.

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

Parameters5/5

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

Schema coverage is 0%, so the description carries the full burden, and it does: every one of the five parameters gets format, defaults, and examples (bbox 'lon_min,lat_min,lon_max,lat_max' with a Tokyo value, datetime single date or start/end range, cloud-cover percentage semantics, limit default 5 / max 10).

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

Purpose5/5

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

States a specific verb and resource (search ESA Copernicus/Sentinel satellite imagery via STAC) and names the concrete provider, which separates it from generic siblings like stac_search or uk_stac_search. The two example queries pin down the request shape immediately.

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

Usage Guidelines4/5

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

Gives when-to-use examples ("Tokyo Sentinel-2 imagery", "recent satellite imagery of Kanto") and notes no authentication is required, plus routes the agent to copernicus_collections for valid collection IDs. It stops short of stating when to prefer stac_search or other agency siblings instead, so no explicit exclusion.

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

Deploy Server

copernicus_search

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools