Loading ToolBench
Transform JAXA satellite data into VRChat worlds! Generate 3D terrain from Earth observation data for Blender/Unity/VRChat. Provides satellite data search, retrieval, processing, and 3D terrain generation via MCP tools.
The server has 13 tools with significant structural gaps. Most tool descriptions exist but are either generic, overly long (violating the 10-1024 char guideline), or written in Japanese with unclear English translations. Parameter schemas are inconsistently defined, some tools have detailed schemas (show_images, export_heightmap), while others (search_collections_id, list_available_collections) have empty input objects. Tool naming follows verb_noun patterns reasonably well (search_*, list_*, get_*, etc.), but descriptions lack the specificity required for reliable LLM tool selection. Several tools expose implementation details (GeoJSON file paths, temporary directories) that should be abstracted. Error handling is absent, there are try/catch blocks in the source code but error responses do not classify errors or guide recovery. Output schemas are either undocumented (most tools) or return raw API responses without field descriptions. No tool declares what it modifies or whether it is idempotent, making it unsafe for agent retry loops.
空間統計を計算します。
処理タスクの計画を作成します。
高度マップをBlender/Unity用にエクスポートします。
衛星データから高度マップを生成します。
日付、解像度、範囲、バンドを指定して地球観測画像を取得します。
処理タスクの計画状態を取得します。
利用可能なコレクション一覧を取得します。
GeoJSONファイルを処理します。
Empty input schemas for discovery tools (search_collections_id, list_available_collections). Both declare Input: {} with no parameter definitions, violating the requirement that all tools have documented parameters.
Descriptions lack LLM-optimized specificity. search_collections_id (335 chars in Japanese, unclear English); list_available_collections (40 chars, too brief); calc_spatial_stats (35 chars). No guidance on WHEN to use each tool instead of similar ones (e.g., why call calc_spatial_stats vs show_spatial_stats?). Violates pattern:tool-description baseline of 10-1024 chars with actionable intent.
No output schema documentation. Tools return Dict[str, Any] or List[Image] with no field descriptions. Agents cannot plan downstream tool calls or extract required IDs. Example: show_images returns List[Image] but no documentation of what fields Image contains or how to chain it to another tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
コレクション名とバンドをキーワードで検索します。
JAXA Earth APIで利用可能なデータセットの詳細情報を返します。ユーザーのリクエストに基づいて、適切なデータセットIDとバンドを選択して応答してください。返されるテキストは、JAXA Earth APIを通じて利用可能なすべてのデータセットのリストです。各パラメータは以下のように記述されています：id、title、description、bands、keywords、startDate、endDate、bbox、epsg。
ユーザー入力に基づいてJAXA Earth APIを使用して衛星画像を表示します。
ユーザー入力に基づいてJAXA Earth APIを使用して衛星データの空間統計結果画像を表示します。
処理タスクの計画状態を更新します。
Destructive and write operations (create_plan, update_plan_status, generate_heightmap, export_heightmap) have no confirmation, dry-run, or idempotency guarantees. Agents retrying a failed call may accidentally create duplicate plans or re-export heightmaps unnecessarily.
Parameters expose file paths and implementation details (geojson_path in get_earth_images, process_geojson, generate_heightmap; heightmap_path in export_heightmap). Users do not know file paths, these should be abstracted to resource URIs or handles, not raw filesystem paths. Violates chat-data-model.
Error handling absent from tool definitions. No error_message field documented, no guidance on retryability, and no classification (user-fixable vs fatal). Source code has try/catch blocks but returns raw exception strings (e.g., 'Error: {str(e)}\n{traceback.format_exc()}'), which do not guide agent recovery.
Parameters with no type constraints. date_range, bounds, dlim are arrays but lack minItems, maxItems, or item type validation in schemas. target_format enum is present in export_heightmap but missing in other format-selection contexts. polygon_limit and texture_size have no min/max bounds.
create_plan has unclear composition. It takes objectives and steps arrays but the relationship to subsequent update_plan_status tool is opaque. Can an agent update a plan created by another agent? What is plan_id and how is it generated? These are not answered in the descriptions.
Overlapping tool responsibilities. Both get_earth_images and show_images fetch satellite imagery with nearly identical parameters (collection, band, bounds, date_range/dlim). No clear guidance on which to call first or when to choose one over the other. Violates single-responsibility principle.
Parameter naming inconsistency. Some tools use 'collection' (string), others use 'collection_name' or 'collection_id'. date_range vs dlim, agents cannot reliably infer which parameter name to use. Violates mxe:response-field-naming where tools consuming a field must use the same name as tools producing it.
Large result sets not paginated. search_collections_id returns the entire JAXA API catalog (potentially thousands of records) as a single text response. No mention of pagination, limit, or truncation. Violates pattern:paginated-result baseline of offering limit and offset/cursor.