space-finder-mcp

Overview Schema Source Related Servers Discussions Admin

dlr_search

Search German Earth observation data (DLR) via STAC by collection, bounding box, date range, and cloud cover without authentication.

Instructions

DLR（ドイツ）の地球観測データを STAC で検索する（認証不要）。

例:「ドイツのSentinel-2画像」「ベルリン周辺のEnMAPデータ」「TROPOMIの二酸化窒素」

Args: collection: STAC コレクションID（既定 "S2_L2A_MAJA"）。dlr_collections で確認可。 bbox: 空間範囲（"lon_min,lat_min,lon_max,lat_max"）。 datetime: 時間範囲（"YYYY-MM-DD" または "start/end"）。⚠️ DLR の API は sortby を無視する（実測: sortby=-datetime を送っても並びが変わらない）ため、新しい順に得たい場合は datetime で期間を指定してください。 max_cloud_cover: 雲量上限（%）。⚠️ DLR の API はサーバー側フィルタ未対応（実測 400）のため、取得後にクライアント側で絞り込む（雲量情報の無いアイテムは除外し、件数を返す）。 limit: 返す件数（既定 5、最大 10）。

Input Schema

Name	Required	Default
`bbox`	No
`limit`	No
`datetime`	No
`collection`	No	S2_L2A_MAJA
`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: -"dlr_searchArguments"
```
Addedv0.39.0Oct 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations the description carries the full burden and delivers: no authentication required, the empirically verified fact that the DLR API ignores sortby so ordering must be controlled via datetime, and that max_cloud_cover is not server-side supported (400 observed) so filtering happens client-side with cloudy-unknown items dropped and a count returned. These are exactly the surprises an agent would otherwise trip over.

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?

Purpose sentence first, then examples, then a compact Args block; the two warnings are attached to the exact parameters they affect rather than dumped in a preamble. Every line conveys information an agent could act on, with no repeated boilerplate.

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 read tool with no annotations and no output schema, the description covers auth, defaults, formats, hard limits and two API quirks. The remaining gap is the return shape (what a result item looks like, and whether bbox/datetime combine as an intersection), which the agent must infer.

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 description coverage is 0%, so the description must compensate, and it does: it documents all five parameters including the default collection (S2_L2A_MAJA) with a discovery path, bbox as 'lon_min,lat_min,lon_max,lat_max', datetime as 'YYYY-MM-DD' or 'start/end', the percentage unit for max_cloud_cover, and limit's default 5 with a hard maximum of 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 (STAC で検索する) plus resource (DLR（ドイツ）の地球観測データ) and scope (認証不要), which cleanly separates it from copernicus_search, uk_stac_search and stac_search siblings. The three concrete example queries remove any ambiguity about what kinds of searches are in scope.

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

Usage Guidelines4/5

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

The example queries ('ドイツのSentinel-2画像', 'ベルリン周辺のEnMAPデータ', 'TROPOMIの二酸化窒素') and the pointer to dlr_collections for valid collection IDs give clear usage context. However, it never states when to prefer this over the other STAC/provider search siblings (copernicus_search, uk_stac_search, stac_search), so no explicit exclusion is offered.

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

Deploy Server

dlr_search

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools