Skip to main content
Glama

オイルスリック検出

analyze_oilslick

Sentinel-1 SAR画像(GRD)からオイルスリック(油膜)を検出します。 ■ 入力: 以下のどちらかで解析対象を指定。 (A) scene_id(Sentinel-1 GRDのシーンID)。ASF Search(https://search.asf.alaska.edu/#/)でFile TypeをGRDに絞って検索可能。 (B) polygon(WKT)+ date(基準日 YYYY-MM-DD)。該当範囲・基準日に近い1シーンを自動選定。date_direction で選択方向を指定可能。 ■ 処理: GPU推論による油膜検出。推定所要時間は約50分。 ■ 出力: 検出された油膜のポリゴンを含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。 ■ 実行前に preview_analysis で解析範囲と消費クレジットを確認し、ユーザーの承認を得てください。ジョブは投入後にキャンセルできません。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo基準日(YYYY-MM-DD)。polygon 指定時に必須。この日付に近いシーンを自動選定
polygonNoWKT形式ポリゴン(例: POLYGON((139.7 35.6, 139.8 35.6, 139.8 35.7, 139.7 35.7, 139.7 35.6)))。date とセットで指定すると該当範囲の1シーンを自動選定。scene_id 指定時は不要
scene_idNoSentinel-1 GRDのシーンID(例: S1A_IW_GRDH_1SDV_20240101T...)。ASF Search で検索可能。polygon + date を指定する場合は不要
satellite_idYes衛星ID。現在 sentinel-1 のみ対応
date_directionNo基準日に対するシーン選択方向(before/after/nearest)。polygon + date 指定時のみ有効。省略時は nearest
orbit_directionNo軌道方向(ascending / descending)。polygon + date 指定時のみ有効。省略時は自動判定

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false), the description discloses critical behavioral traits: GPU inference, ~50 min processing time, returns a job_id, requires polling, job cannot be canceled after submission, and requires user approval before execution. This adds significant context not found in annotations.

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?

Well-structured with clear section markers (■) for input, processing, output, flow, and notes. Every sentence carries information, and the most important scoping constraints (input modes, non-cancelable job) are prominently placed. Information-dense but not verbose.

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

Completeness5/5

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

The description is complete for a complex 6-parameter tool with no output schema. It covers input selection logic, runtime estimate, output type (GeoJSON), asynchronous flow, required prerequisites (preview_analysis approval), and a critical limitation (no cancellation). The mention of sibling tools like check_job_status and get_job_result completes the operational context.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameters are already well-documented in the schema. The description provides a high-level overview of input options (A/B) and clarifies relationships between parameters, but does not add new semantic details beyond what the schema already states.

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?

The description clearly states the tool detects oil slicks from Sentinel-1 SAR GRD imagery, using the specific verb '検出' and a specific resource. It is easily distinguished from sibling tools like analyze_ship or analyze_newbuilding.

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?

Provides explicit context for when to use this tool: analyzing oil slicks, with two input modes (scene_id or polygon+date). It also tells the agent to use preview_analysis first, then check_job_status and get_job_result in the flow. However, it does not explicitly state when to prefer an alternative analysis tool over this one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each analysis tool targets a distinct detection type (buildings disappearing, new buildings, oil slick, ships, surface changes), and job management tools have clear separate roles (status, result, list). The polygon drawing and preview tools are also uniquely scoped.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: analyze_* for detections, check_job_status / get_job_result / list_jobs for job operations, and open_polygon_draw / preview_analysis for supporting actions. No mixed conventions or vague verbs.

Tool Count5/5

Ten tools cover the full workflow without redundancy: five analysis types, three job management utilities, one drawing helper, and one preview gate. This is well-scoped for a satellite analysis server.

Completeness5/5

The workflow is complete: preview to approve, submit analysis, poll status, retrieve results, list past jobs, and draw polygons. The domain covers the major SAR-based detection needs and includes explicit guidance for handling long-running jobs.

Resources