Satellite SAR analysis: ship, oil slick, building change, and time-series change detection
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 9 of 9 tools scored.
各分析ツールは明確に異なる検出対象（消失建物、新規建物、油膜、船舶、時系列変化）を持ち、記述も十分に区別されている。ジョブ管理ツール（check_job_status, get_job_result, list_jobs）はそれぞれの責務が明確で、混同の余地がない。open_polygon_drawも補助ツールとして位置づけが明確。
分析ツールは analyze_<対象> の一貫したパターン（analyze_disappearbuilding, analyze_oilslick, analyze_ship 等）を踏襲しており良い。ただし open_polygon_draw と list_jobs は analyze_ 接頭辞のない別パターンだが、ジョブ操作系（check_/get_/list_）は動詞接頭辞で統一されている。全体的に規則的で、わずかに分析系と操作系で接頭辞が異なるのみ。
9ツールはSAR画像解析サーバーとして適切な規模。5つの分析ツール、3つのジョブ管理ツール、1つの補助ツールで構成され、各ツールが一意の役割を持っており過不足ない。
ジョブライフサイクル（投入→ポーリング→結果取得→一覧確認）が一通り揃っており、主要なSAR解析機能（建物消失/新築、油膜、船舶、時系列）をカバーしている。ただしジョブのキャンセルや削除機能がなく、idlefarmがlist_jobsのendpoint_idに存在するのにAnalyzeツールが無い点は小さなギャップとなる。
analyze_disappearbuilding消失建物検出AInspect指定エリア・期間内に消失した建物を検出します。Sentinel-1 SARの前後比較による変化検出。災害前後の家屋被害推定等に利用。 ■ 入力: WKT形式ポリゴン + 日付範囲（YYYY-MM-DD）。satellite_id は sentinel-1 を指定。 ■ 面積制限: 最大30000km²。超える場合はエリアを分割してください。 ■ 処理: 期間内の2シーン（before/after）を比較しGPU推論。所要時間は面積に依存。 ■ 出力: 消失建物のポリゴンを含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。
| Name | Required | Description | Default |
|---|---|---|---|
| polygon | Yes | WKT形式ポリゴン（例: POLYGON((139.7 35.6, 139.8 35.6, 139.8 35.7, 139.7 35.7, 139.7 35.6))）。最大30000km² | |
| date_end | Yes | 解析終了日（YYYY-MM-DD）。災害後期間 | |
| date_start | Yes | 解析開始日（YYYY-MM-DD）。災害前期間 | |
| satellite_id | Yes | 衛星ID。現在 sentinel-1 のみ対応 | |
| orbit_direction | No | 軌道方向（ascending / descending）。省略時は自動判定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds useful behavioral context: it's an asynchronous job (returns job_id requiring polling), the processing involves GPU inference, and processing time depends on area. It doesn't describe cost implications or data freshness, but the async flow and area-dependent runtime are meaningful additions beyond annotations.
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 well-organized with visual sections (■ 入力, ■ 面積制限, ■ 処理, ■ 出力, ■ フロー) that make it scannable. Each section earns its place, covering inputs, limits, processing, output, and workflow. Slightly verbose but each sentence carries functional 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 the schema covers all 5 parameters at 100% and has no output schema, the description compensates well by describing the output format (GeoJSON with polygons), the async job flow (submit → poll → retrieve), and the area constraint. This is reasonably complete for a complex job-based analysis tool. It could mention cost or order-of-magnitude processing time estimates, but the essential workflow is covered.
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 coverage is 100%, and the description adds some value by clarifying date_start corresponds to '災害前' (pre-disaster) and date_end to '災害後' (post-disaster), and specifying satellite_id must be 'sentinel-1'. However, the orbit_direction parameter is only summarized as auto-detection when omitted, which mostly matches the schema. Overall the description adds modest 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?
Description clearly states the tool detects disappeared buildings ('消失した建物を検出') in a specified area and time range using Sentinel-1 SAR before/after comparison. It distinguishes itself from siblings like analyze_newbuilding and analyze_ship by specifying the specific analysis type (building collapse detection).
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 explains when to use this (disaster damage estimation, post-disaster building loss), specifies the area limit of 30000km² with instruction to split the area if exceeded, and describes the flow (submit job, poll with check_job_status, then get_job_result). This is explicit usage context that distinguishes from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_newbuilding新規建物検出AInspect指定エリア・期間内に新しく建設された建物を検出します。Sentinel-1 SARの前後比較による変化検出。 ■ 入力: WKT形式ポリゴン + 日付範囲（YYYY-MM-DD）。satellite_id は sentinel-1 を指定。 ■ 面積制限: 最大30000km²。超える場合はエリアを分割してください。 ■ 処理: 期間内の2シーンを比較しGPU推論。所要時間は面積に依存。 ■ 出力: 新規建物のポリゴンを含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。
| Name | Required | Description | Default |
|---|---|---|---|
| polygon | Yes | WKT形式ポリゴン（例: POLYGON((139.7 35.6, 139.8 35.6, 139.8 35.7, 139.7 35.7, 139.7 35.6))）。最大30000km² | |
| date_end | Yes | 解析終了日（YYYY-MM-DD） | |
| date_start | Yes | 解析開始日（YYYY-MM-DD） | |
| satellite_id | Yes | 衛星ID。現在 sentinel-1 のみ対応 | |
| orbit_direction | No | 軌道方向（ascending / descending）。省略時は自動判定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavior: it's a GPU-inferred change detection between two scenes, processing time depends on area, output is GeoJSON with new-building polygons, and it's an async job flow (returns job_id rather than immediate results). It explains the polling pattern needed. With readOnlyHint=false and destructiveHint=false annotations, the description adds valuable context about the asynchronous processing model and GPU requirements.
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 well-organized with clear section markers (●) for input, area limits, processing, output, and flow. Each section is a single concise line. Front-loaded with the core purpose before details. No wasted words and every sentence adds unique value.
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?
For a moderately complex tool with 5 params, async job flow, and no output schema, the description covers all bases: input format, constraints, processing model, output format, and downstream workflow. It fully compensates for the missing output schema by explaining what get_job_result returns and the polling sequence. Thorough for its complexity level.
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 100%, so the baseline is 3. The description adds the 30000km² area constraint and date format expectations (YYYY-MM-DD) that reinforce schema content. It also mentions orbit_direction as optional with auto-detection, which the schema already covers. The description adds some context (format examples, area limit) but the schema already documents each parameter thoroughly.
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 states a specific verb+resource: detects newly built buildings in a specified area/date range, using Sentinel-1 SAR before/after comparison. It clearly distinguishes this from sibling tools like analyze_disappearbuilding (building disappearance), analyze_oilslick, and analyze_ship by specifying 'newly constructed buildings' as the target.
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 usage context: area limit of 30000km² with instruction to split, requires WKT polygon + date range, specifies satellite_id as sentinel-1, and describes the job flow (job_id → check_job_status → get_job_result). It gives practical instructions on prerequisites and workflow. It doesn't explicitly state when NOT to use this tool versus the disappear/ship/oilslick siblings, but the building-detection focus makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_oilslickオイルスリック検出AInspectSentinel-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 で結果取得。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 基準日（YYYY-MM-DD）。polygon 指定時に必須。この日付に近いシーンを自動選定 | |
| polygon | No | WKT形式ポリゴン（例: 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_id | No | Sentinel-1 GRDのシーンID（例: S1A_IW_GRDH_1SDV_20240101T...）。ASF Search で検索可能。polygon + date を指定する場合は不要 | |
| satellite_id | Yes | 衛星ID。現在 sentinel-1 のみ対応 | |
| date_direction | No | 基準日に対するシーン選択方向（before/after/nearest）。polygon + date 指定時のみ有効。省略時は nearest | |
| orbit_direction | No | 軌道方向（ascending / descending）。polygon + date 指定時のみ有効。省略時は自動判定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that processing uses GPU inference, takes approximately 50 minutes, returns a job_id, and requires asynchronous polling. While annotations declare readOnlyHint=false and destructiveHint=false, confirming it's not a read-only but also not destructive operation, the description adds key context about the async nature, runtime estimate, and output format (GeoJSON polygons). It stops short of describing edge cases or error behavior, but covers the main behavioral expectations well.
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 well-structured with clear section markers (■ 入力, ■ 処理, ■ 出力, ■ フロー) that make it scannable. Each section is concise and purposeful. It's slightly longer than strictly necessary, but the structured format justifies the length given the tool's complexity (6 params, two input modes, async workflow). The URL to ASF Search is genuinely useful context.
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 params, two input modes, async job workflow, 50-minute runtime, GPU dependencies), the description covers the essential aspects comprehensively: input specification, processing details, output format, and the follow-up workflow. No output schema exists, but the description states the output is a GeoJSON with detected oil slick polygons, which addresses the return value question. It could add error scenarios or input validation notes, but is near-complete for an async job-submission 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 100%, providing solid documentation for all 6 parameters. The description adds meaningful value above the schema by explaining the two selection modes (A: scene_id, B: polygon+date), clarifying that date is required for polygon mode, and noting date_direction/orbit_direction only apply with polygon+date. It reinforces the mutual exclusivity of scene_id vs polygon+date, which the schema hints at but the description makes explicit.
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 detects oil slicks from Sentinel-1 SAR GRD imagery. It distinguishes from siblings (analyze_ship, analyze_newbuilding, etc.) by specifying the exact analysis type (oil spill detection) and the specific data source (Sentinel-1 SAR). The verb+resource+scope structure is specific and unambiguous.
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 input selection options (A or B: scene_id vs polygon+date), clear instructions on how to obtain a scene_id (via ASF Search with GRD filter), and a documented workflow flow (job submission → polling via check_job_status → result retrieval via get_job_result). It explicitly names the alternative tools for result checking and polling, providing strong when/how guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_ship船舶検出AInspectSentinel-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推論による物体検出。推定所要時間は約30分。 ■ 出力: 検出された船舶のポリゴンを含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 基準日（YYYY-MM-DD）。polygon 指定時に必須。この日付に近いシーンを自動選定 | |
| polygon | No | WKT形式ポリゴン（例: 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_id | No | Sentinel-1 GRDのシーンID（例: S1A_IW_GRDH_1SDV_20240101T...）。ASF Search で検索可能。polygon + date を指定する場合は不要 | |
| satellite_id | Yes | 衛星ID。現在 sentinel-1 のみ対応 | |
| date_direction | No | 基準日に対するシーン選択方向（before/after/nearest）。polygon + date 指定時のみ有効。省略時は nearest | |
| orbit_direction | No | 軌道方向（ascending / descending）。polygon + date 指定時のみ有効。省略時は自動判定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description honestly discloses that this is a long-running async job (~30 min) that returns a job_id rather than immediate results. It adds the ASF Search URL for scene finding, which is useful context. However, no annotations exist for cost/rate limits, and the description doesn't disclose what happens to submitted jobs on failure or whether it's idempotent—though the ~30min estimate and job_id flow are meaningfully disclosed.
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?
Well-structured with clear section markers (■ 入力, ■ 処理, ■ 出力, ■ フロー), front-loading the core purpose. Organized as a bullet list that's scannable. Slightly longer than strictly necessary—the orbit_direction clarification and search URL could arguably be trimmed—but every line earns its place given the two-input-mode complexity.
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?
For a complex 6-parameter tool with no output schema, this description is thorough. It covers input selection logic, the estimated runtime, output format, and the complete async job flow. The sibling flow tools (check_job_status, get_job_result) are referenced. Minor gaps: no mention of output EPSG/coordinate system, no detail on what the GeoJSON includes beyond ship polygons, and no failure/error behavior specified—but the overall coverage is strong for this complexity.
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 coverage is 100%, so the schema already documents all 6 parameters. The description adds value beyond the schema by providing a concrete WKT polygon example, mapping parameters to the input-mode branches (A vs B), clarifying that date_direction and orbit_direction only apply under mode B, and giving a real scene_id format example (S1A_IW_GRDH_1SDV...). This enhances parameter understanding beyond the raw schema properties.
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 it detects ships from Sentinel-1 SAR GRD imagery, specifying the exact input options (scene_id or polygon+date), processing (GPU inference, ~30 min), and output (GeoJSON with ship polygons). It clearly distinguishes from sibling analyze_* tools which target different features (disappearing buildings, new buildings, oil slicks, time series).
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?
Provides explicit when-to-use guidance distinguishing between two mutually exclusive input modes (A: scene_id, B: polygon+date), with conditional parameter requirements clearly spelled out (date required with polygon, date_direction only valid with polygon+date). Also references the related async flow tools (check_job_status, get_job_result), giving agents a full usage path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_timeseries時系列変化検出AInspect指定エリア・期間のSentinel-1 SAR時系列データから地表面の変化を検出します。 ■ 入力: WKT形式ポリゴン + 日付範囲（YYYY-MM-DD）。satellite_id は sentinel-1 を指定。 ■ 面積制限: 最大5km²。超える場合はエリアを分割してください。timeseries は出力フィーチャー密度が高くGeoJSONが重くなるため、ポリゴン型ツールより上限を厳しく設定している。 ■ 処理: 期間内の複数シーンを時系列解析。所要時間は面積・期間に依存。 ■ 出力: 変化が検出されたエリアのポリゴン・変化指標を含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。
| Name | Required | Description | Default |
|---|---|---|---|
| polygon | Yes | WKT形式ポリゴン（例: POLYGON((139.7 35.6, 139.8 35.6, 139.8 35.7, 139.7 35.7, 139.7 35.6))）。最大5km² | |
| date_end | Yes | 解析終了日（YYYY-MM-DD） | |
| date_start | Yes | 解析開始日（YYYY-MM-DD） | |
| satellite_id | Yes | 衛星ID。現在 sentinel-1 のみ対応 | |
| orbit_direction | No | 軌道方向（ascending / descending）。省略時は自動判定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, which the description aligns with (no contradiction). The description adds valuable context: the area limit is stricter than polygon tools because output feature density is high and GeoJSON gets heavy, processing time depends on area/period, and the async job flow with polling. This adds behavioral insight beyond the annotations.
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 structured with clear section markers (■ 入力, ■ 面積制限, ■ 処理, ■ 出力, ■ フロー) making it scannable. It fronts important operational constraints (area limit) early. It's somewhat long with trailing prose but every section earns its place—input format, constraint, processing behavior, output, and job flow are all actionable details.
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?
Despite no output schema, the description fully explains the output (GeoJSON of changed areas with change indicators). The async job flow is completely documented (job_id → check_job_status → get_job_result). All 5 parameters are covered by the 100% schema coverage plus additional semantics. For a complex async SAR analysis tool, this description is thorough and complete.
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 coverage is 100%, so baseline is 3. The description adds meaning by clarifying the polygon must be in WKT format (with example) and stating satellite_id must be sentinel-1, plus the 5km² limit applies to the polygon. It also mentions orbit_direction can be auto-detected. These provide meaningful semantics beyond the schema, including the important format example and area constraint.
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 detects surface changes from Sentinel-1 SAR time-series data for a specified area and period. It uses a specific verb (検出/detect) + resource (SAR time-series + area/period) and is distinguished from siblings (analyze_newbuilding, analyze_ship, etc.) which target specific feature types; this tool is the general change-detection variant.
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 when-to-use guidance: specify satellite_id=sentinel-1, WKT polygon + date range. It explicitly names the async flow via check_job_status and get_job_result, differentiating from synchronous tools. It also gives a clear area limit (5km²) and directs users to split areas beyond that, contrasting with polygon-type tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_job_statusジョブステータス確認A検出ジョブの現在のステータスを確認します。 ■ ステータス: pending（待機中）→ processing（処理中）→ completed（完了）/ failed（失敗） ■ completed になったら get_job_result で結果を取得してください。 ■ 推論時間目安: 船舶検出 約30分、オイルスリック検出 約50分。長時間かかるためユーザーに待ち時間を伝えること。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | analyze_* で取得したジョブID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description does not contradict (it's a status check, consistent with read-only). The description adds value by disclosing the long inference times, which is behavioral context beyond the annotation. However, it doesn't disclose what the response contains (status field formatting, whether it polls or returns once, why it might fail) — the description leaves return-format details to the schema, which has no output schema. With a readOnlyHint annotation already covering safety profile, 3 is fair.
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 concise but content-dense: it covers status lifecycle, workflow linkage, and wait-time guidance in three short segments. The bullet-style layout with ■ markers aids readability. Slight redundancy between the first line and the status lifecycle line, but overall every sentence earns its place.
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 simple tool (1 param, high schema coverage, readOnly annotation, no output schema), the description covers the essential operational context: status transitions, when to fetch results, and wait-time expectations. It doesn't describe the response shape or error cases, but for a status-polling tool with limited complexity this is reasonable. Slight gap: no guidance on polling interval or how to handle 'failed' status.
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 100%, and the param description ('analyze_* で取得したジョブID') already explains where the job ID comes from. The tool description reiterates this source tool linkage without adding format details or examples. Since the schema fully documents the parameter, the description doesn't need extensive compensation — baseline 3 is appropriate.
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 what the tool does (check current status of a detection job) and specifies the exact resource (検出ジョブ). It distinguishes itself from siblings by explaining the workflow relationship to get_job_result (retrieve results after completed) and the analyze_* tools that create the job. The job ID parameter is clearly sourced from analyze_* tools.
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 workflow guidance: the status lifecycle (pending→processing→completed/failed), when to call get_job_result (after completed), and an explicit expectation to inform the user about wait times due to long inference (船舶検出約30分, オイルスリック約50分). This is strong when/how-to-use guidance beyond a simple definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_resultジョブ結果取得A完了した検出ジョブの結果を GeoJSON 形式で取得します。 ■ ステータスが completed のジョブのみ結果を返します。 ■ 結果には検出オブジェクトのポリゴン座標・プロパティが含まれます。 ■ 重要: 取得した GeoJSON は必ず地図上にプロット・可視化してユーザーに提示してください。座標をテキストで羅列するのではなく、地図コンポーネントで描画すること。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | 結果を取得するジョブID。ステータスが completed であること |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable context: only completed jobs return results, output is GeoJSON format with polygons and properties. Crucially, it adds a behavioral requirement that results must be plotted on a map rather than just listed as text coordinates—useful operational guidance that annotations don't cover.
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?
Description is compact with three bulleted sections: return type, content, and critical usage note. The bullets are clear and front-loaded. The map-visualization requirement is an important addition that earns its place, though the formatting could be tightened slightly (redundant '重要' preamble).
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?
For a single-param tool with 100% schema coverage and readOnly annotation, the description covers the essential aspects: when it applies (completed jobs), what it returns (GeoJSON polygons/properties), and how the result must be presented (map visualization). The map-plotting requirement is especially valuable given the sibling tools suggest a geospatial analysis workflow.
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 100% and the single job_id param is already documented in the schema. The description reinforces that job_id must reference a completed job (matching the schema's 'completed' requirement). With 100% coverage, baseline is 3; the description adds slight value by connecting the param constraint to the tool's overall behavior, though not a major addition.
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+resource: 'get' detection job results in GeoJSON format. It uniquely distinguishes from siblings (check_job_status, list_jobs) by specifying it retrieves completed job results as GeoJSON with polygon coordinates and properties.
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 states when to use it: only for jobs with status 'completed', which establishes clear context for usage. However, it doesn't explicitly name alternative tools or state when-not-to-use it (e.g., vs check_job_status or list_jobs), though the constraints are reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_jobsジョブ一覧A自分の解析ジョブ一覧を最新順に取得します（最大30件）。 ■ status（pending / processing / completed / failed）と endpoint_id（ship / oilslick / newbuilding / disappearbuilding / timeseries / idlefarm）で絞り込み可能。カンマ区切りで複数指定できます。 ■ 「さっきのジョブどうなった？」のように job_id が会話に残っていない場合の確認に使用してください。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数（1〜30、省略時 30） | |
| status | No | ステータス絞り込み（カンマ区切り可。例: processing,completed）。省略時は全件 | |
| endpoint_id | No | 検出種別絞り込み（カンマ区切り可。例: idlefarm）。省略時は全件 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety (read-only), so the bar is lowered. The description adds a useful scoping constraint ('自分の' = own jobs only, max 30) and the status/endpoint options, which go beyond annotation. However it does not state pagination behavior beyond the 30-cap or what happens when more than 30 jobs exist.
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?
Two compact bullet points plus a usage example sentence. Zero filler, front-loaded with the core purpose. Every sentence adds value (purpose, filters, when-to-use example).
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?
For a simple filtered-list tool with full schema coverage and readOnlyHint annotation, the description is quite complete: purpose, filter semantics, enumerated filter values, and when-to-use guidance all present. Minor gap: no mention of what fields each job entry contains in the returned list, but for a list tool with no output schema this is acceptable.
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 coverage is 100%, so the schema already documents all three parameters. The description adds the enumerated endpoint_id values (ship / oilslick / newbuilding / disappearbuilding / timeseries / idlefarm) and clarifies the comma-separated multi-value syntax, which is genuinely additive beyond the schema. Baseline 3 is appropriate.
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?
Clear verb+resource: fetches the user's own analysis job list in latest-first order with a 30-item cap. Notably distinguishes from siblings like check_job_status (single job check) and get_job_result (fetch result), focusing specifically on the list/all-jobs view.
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?
Explicitly says to use when job_id is no longer in conversation ('さっきのジョブどうなった？'), providing a concrete when-to-use scenario. Filtering with status and endpoint_id is documented with enumerated value examples, making alternatives to check_job_status clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_polygon_drawポリゴン描画A地図上でポリゴンを描画し、WKT POLYGON文字列を取得するウィジェットを開きます。 取得したWKTは analyze_ship / analyze_oilslick / analyze_newbuilding / analyze_disappearbuilding / analyze_timeseries の polygon 引数に使用できます。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already indicates this is a safe read operation (no data mutation). The description adds value by clarifying the tool opens a widget and returns WKT data for downstream use. It doesn't describe UI behavior details, but with annotations covering the safety profile, the bar is lowered and the added context about the widget + returned WKT format is sufficient.
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?
Two well-structured sentences with zero wasted words. The first sentence states the purpose and output; the second sentence connects it to downstream usage. Front-loaded and efficient.
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?
For a zero-parameter tool with a readOnlyHint, the description is complete. It explains what the tool does, what it returns, and how to use the result. The only minor gap is not describing whether it's a blocking tool (does the agent need user interaction?) but this is reasonable for a widget-opening 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?
The tool has 0 parameters and schema description coverage is 100%, so there is nothing for the description to document. The description adds context about the output (WKT POLYGON string) which is more valuable than parameter details for a zero-parameter tool.
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 opens a widget to draw a polygon on a map and obtain a WKT POLYGON string. It uses a specific verb-resource combination (draw polygon, get WKT) that distinguishes it from the analysis siblings. However, it doesn't strongly differentiate within the sibling set since siblings are all analysis tools that consume the polygon output.
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 explicitly states how the obtained WKT can be used (as the polygon argument across five named analysis tools), which functions effectively as usage guidance. It implies this tool is a prerequisite/preparatory step before running analyses, giving clear context on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!