Satellite SAR analysis: ship, oil slick, building change, and time-series change detection
指定エリア・期間内に消失した建物を検出します。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 で結果取得。 ■ 実行前に preview_analysis で解析範囲と消費クレジットを確認し、ユーザーの承認を得てください。ジョブは投入後にキャンセルできません。
| 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?
Beyond annotations, it discloses the asynchronous job model (job_id returned, polling required), non-cancellable jobs, GPU inference, area-dependent runtime, and GeoJSON output. These are non-obvious behavioral details that materially affect how an agent should use the tool.
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-organized with labeled bullet sections for input, area limits, processing, output, and lifecycle. Every section carries operational value and the structure makes the flow easy to follow despite the length.
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 an asynchronous job tool with no output schema, the description covers input requirements, area constraints, processing behavior, output type, job lifecycle, and prerequisite preview/approval step. Nothing critical for correct invocation is missing.
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 schema already documents each parameter including WKT format, date range, and sentinel-1 constraint. The description reinforces these constraints but does not add meaningfully new parameter semantics beyond the schema, so the baseline 3 applies.
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?
States a specific verb (検出) and resource (消失建物), and the method (Sentinel-1 SAR前後比較) makes the tool distinct. It is clearly differentiated from siblings like analyze_newbuilding and analyze_oilslick by domain and processing approach.
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 strong operational guidance: use preview_analysis before execution, poll check_job_status, get results via get_job_result, and split areas over 30000 km². It does not explicitly name sibling alternatives for when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定エリア・期間内に新しく建設された建物を検出します。Sentinel-1 SARの前後比較による変化検出。 ■ 入力: WKT形式ポリゴン + 日付範囲（YYYY-MM-DD）。satellite_id は sentinel-1 を指定。 ■ 面積制限: 最大30000km²。超える場合はエリアを分割してください。 ■ 処理: 期間内の2シーンを比較しGPU推論。所要時間は面積に依存。 ■ 出力: 新規建物のポリゴンを含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。 ■ 実行前に preview_analysis で解析範囲と消費クレジットを確認し、ユーザーの承認を得てください。ジョブは投入後にキャンセルできません。
| 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 (readOnlyHint=false, destructiveHint=false) indicate a non-read-only operation that does not destroy data. The description adds valuable behavioral context: it states GPU inference, time dependent on area, returns GeoJSON, and the job-polling lifecycle including non-cancellation after submission. It does not contradict the annotations and goes well beyond the basic flags.
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 labeled sections (input, area limit, processing, output, flow, and pre-action). Each section carries unique useful information without redundancy. It is slightly long but information-dense; there is minimal fluff. It could be marginally tighter but is already 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?
Given the tool involves GPU inference, job creation, and polling, the description satisfactorily covers all steps: how to specify inputs, what the result is, how to retrieve it (via check_job_status and get_job_result), and the requirement to use preview_analysis beforehand. It lacks only minor details such as error handling or timeouts, but these are not essential for initial selection.
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%, but the description complements it by specifying that 'satellite_id' must be 'sentinel-1', and reinforces area limit (max 30000 km²) with instruction to split otherwise. It also provides a WKT format example and indicates 'orbit_direction' is optional. This adds practical constraints not fully captured in the schema's property stubs.
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 newly constructed buildings within a specified area and date range using Sentinel-1 SAR change detection. It specifies the verb ('detect'), resource ('buildings'), and scope, and the sibling tools (e.g., 'analyze_disappearbuilding') clearly differ in intent, so an agent can easily distinguish them.
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: it instructs to run 'preview_analysis' beforehand for scope and credit confirmation, obtains user approval, and notes that jobs cannot be canceled after submission. It also mentions area limits and suggests splitting large areas. While it doesn't explicitly contrast with sibling analysis tools, the purpose is self-evident, and file format and process flow are clearly documented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 で解析範囲と消費クレジットを確認し、ユーザーの承認を得てください。ジョブは投入後にキャンセルできません。
| 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?
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.
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.
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.
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.
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.
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.
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推論による物体検出。推定所要時間は約30分。 ■ 出力: 検出された船舶のポリゴンを含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。 ■ 実行前に preview_analysis で解析範囲と消費クレジットを確認し、ユーザーの承認を得てください。ジョブは投入後にキャンセルできません。
| 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只表达非只读、非破坏性的基础上，描述补充了大量关键行为：GPU推理、约30分钟耗时、返回job_id的异步模式、输出GeoJSON、作业提交后不可取消、执行前需用户批准。这些信息远超结构化标注的承载量，充分披露了工具的副作用和时间成本。
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?
采用■分段结构将输入、处理、输出、流程、前置条件拆分为独立模块，信息密度高且无冗余。对异步作业型工具而言，每一条内容（输入A/B、耗时、取消限制、批准要求）都是调用决策所需的最小必要信息，长度与复杂度匹配。
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?
工具涉及6个参数、异步作业、需事先批准、结果需二次获取，复杂度高。描述涵盖了输入二选一约束、处理时长、输出格式、后续轮询与取结果步骤、取消限制和前置批准要求，各环节闭环。虽然缺少输出schema，但描述已声明返回的是含船舶多边形的GeoJSON，对智能体正确调用和结果预期无缺口。
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的6个参数覆盖率100%，但描述额外传达了schema无法直接表达的语义——scene_id与polygon+date的互斥分组关系（A/B模式）、参数之间的依赖条件（polygon需与date成对、date_direction仅在polygon+date模式下生效）。还提供了ASF Search检索入口辅助查找scene_id，增强了参数的实用语义。
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?
描述以特定动词「検出」明确了从Sentinel-1 SAR画像（GRD）检测船舶的功能，资源、数据源和处理方式都清晰无歧义。与兄弟工具analyze_oilslick、analyze_newbuilding等在分析主题上天然区分，工具边界明确。
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?
描述明确给出了两种输入方式（scene_id路径与polygon+date路径）的适用场景，并指定了何时必须搭配date、何时省略。还显式说明了执行顺序——先用preview_analysis获取用户批准，再提交作业，用check_job_status轮询、get_job_result取结果，以及与兄弟工具的调用衔接关系完整。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定エリア・期間のSentinel-1 SAR時系列データから地表面の変化を検出します。 ■ 入力: WKT形式ポリゴン + 日付範囲（YYYY-MM-DD）。satellite_id は sentinel-1 を指定。 ■ 面積制限: 最大5km²。超える場合はエリアを分割してください。timeseries は出力フィーチャー密度が高くGeoJSONが重くなるため、ポリゴン型ツールより上限を厳しく設定している。 ■ 処理: 期間内の複数シーンを時系列解析。所要時間は面積・期間に依存。 ■ 出力: 変化が検出されたエリアのポリゴン・変化指標を含むGeoJSON。 ■ フロー: ジョブ投入後 job_id が返される。check_job_status でポーリングし、completed 後に get_job_result で結果取得。 ■ 実行前に preview_analysis で解析範囲と消費クレジットを確認し、ユーザーの承認を得てください。ジョブは投入後にキャンセルできません。
| 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 only say readOnly=false and destructive=false, so the description carries the behavioral burden and succeeds: it reveals the async job flow (job_id, check_job_status, get_job_result), explains why the area cap is stricter (dense GeoJSON output), and warns the job cannot be canceled once submitted.
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 neatly divided into input, area limit, processing, output, flow, and pre-flight confirmation sections. Every bullet carries actionable information, and the most important scoping constraint is front-loaded near the beginning.
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 an asynchronous, high-cost analysis tool with no output schema, the description is unusually complete: it specifies required parameters, constraints, expected output format, polling/result retrieval, and the required preview/approval step. No critical call-time information is missing.
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 baseline applies; the description largely mirrors schema details such as WKT format, date format, and sentinel-1 satellite_id. It adds a small amount of contextual meaning (max 5km² and area-splitting guidance), but no new parameter semantics 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?
The description opens with a specific verb and resource: detects surface changes from Sentinel-1 SAR time-series data in a given area/period. The input/output sections make the scope concrete, and the time-series aspect distinguishes it from sibling object-specific analyzers like analyze_newbuilding and analyze_ship.
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 tool gives clear operating context: WKT polygon plus date range, a strict 5km² area cap with a split instruction, and a mandatory preview_analysis step with user approval before job submission. It does not explicitly name sibling analyzers to select instead, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
検出ジョブの現在のステータスを確認します。 ■ ステータス: 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?
The annotations already provide readOnlyHint=true, so the description doesn't need to restate that the tool is read-only. Adding value beyond the annotation, the description reveals the job state machine and expected durations, which helps the agent set user expectations and avoid leaving the operation hanging. It does not fully disclose details like typical response latency or pagination, but for a status-check tool, the added context is solid.
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 very concise: three short bullet-style sentences covering the state flow, the next step after completion, and the estimated time. It front-loads the core purpose and status values, then adds actionable guidance. Nothing is wasted, and the structure is easy to read even for an AI agent.
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 tool with one parameter and a read-only annotation, the description is fully sufficient. It tells the agent what the tool does, what the possible statuses are, what to do when the status is completed, and how long the operation might take. No returning schema or nested objects exist, so there is nothing missing in that regard. This is enough for correct invocation and follow-up action.
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 input schema fully covers the single parameter job_id with a clear description ('analyze_* で取得したジョブID'). Since schema description coverage is 100%, the description does not need to add parameter semantics. It does not provide any extra syntax or examples, but that is not necessary here — the baseline of 3 is appropriate given the high schema coverage.
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?
Title and description both clearly identify the tool's purpose: checking the current status of a detection job. The description explicitly enumerates possible status values (pending → processing → completed/failed), which makes the tool's scope unambiguous. It also contrasts well with its siblings (get_job_result fetches results, list_jobs lists jobs), helping an agent distinguish when to use this one.
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 guidance: once the job reaches completed, the agent should call get_job_result instead. It also documents estimated processing times (about 30 minutes for ship detection, about 50 minutes for oil slick detection) and instructs the agent to inform the user about the wait time. This is actionable, context-rich usage guidance that tells the agent when and how to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
完了した検出ジョブの結果を 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 already declare readOnlyHint=true, and the description adds behavioral context: it returns GeoJSON with polygon coordinates and properties, and mandates that results must be visualized on a map rather than presented as raw text. This goes beyond the annotation and is operationally valuable.
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 compact and well-structured: a clear opening sentence followed by bullet-pointed key constraints and an important usage directive. Every sentence earns its place, with no redundancy.
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 read-only tool with one well-documented parameter, the description covers the essential aspects: what the tool returns, the precondition (completed status), and the required post-processing (map visualization). No critical information is missing.
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 input schema fully documents job_id (including the requirement that status must be completed), and the description reiterates this condition without adding new semantic detail. With 100% schema coverage, the baseline of 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 explicitly states the tool's purpose: retrieving completed detection job results in GeoJSON format ('完了した検出ジョブの結果を GeoJSON 形式で取得します'). It clearly identifies the resource and action, distinguishing it from sibling tools like check_job_status (status checking) and list_jobs (listing jobs).
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 context: only jobs with status 'completed' will return results, so an agent knows this tool should be used after job completion. It lacks an explicit alternative for non-completed jobs, but the condition itself sets a clear boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
自分の解析ジョブ一覧を最新順に取得します（最大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 is already set, and the description adds context: it returns at most 30 items and supports comma-separated multiple filters. This source is useful because it clarifies the pagination/limit behavior and the flexibility of filtering, which is not fully evident from the annotation alone. No contradiction detected.
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 compact and front-loaded: the core action and limit appear first, then filtering semantics, then a practical use case. Every sentence adds meaningful guidance without filler, making it easy for an agent to quickly understand when and how to call the tool.
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?
The description is complete enough for a straightforward list tool with no output schema. It covers the main behaviors (latest order, max, filtering) and the intended use case. It does not explain the return structure, but that is not critical given the simple list nature and the derived usage context.
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?
Although the schema already covers 100% of parameters, the description explicitly lists the allowed status values (pending / processing / completed / failed) and endpoint_id values (.ship / oilslick / newbuild / .disappear) which are not defined as enums. This adds practical semantics that an agent can use without opening 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?
The description clearly states the action (fetch a list) and the resource (analysis jobs), and adds key constraints: latest order, max 30 items, and filterable by status and endpoint_id. It distinguishes itself from siblings like check_job_status (single-job status) and get_job_result (specific result) by emphasizing the batch listing and the use-case of recovering jobs not tied to a job_id.
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 gives a concrete usage scenario: "さっきのジョブどうなった？" (what happened to my last job) when the job_id is no longer in the conversation, which is clear guidance for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
地図上でポリゴンを描画し、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 annotation readOnlyHint=true is consistent with the description, which describes an opening of a widget (a read-like UI action). The description adds context about the WKT being usable in other tools, but does not disclose details such as user interaction requirements or result delivery (e.g., whether the WKT appears in the UI or is returned). Given annotations cover the safety profile, a 3 is appropriate.
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 concise sentences: first states what the tool does, second explains its downstream use. No fluff, efficient and complete for the purpose.
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 UI-opening tool with a readOnlyHint annotation, the description adequately explains its function and relevance to sibling analysis tools. It does not specify return value or UI behavior, but these are not critical for an agent to invoke the tool correctly given its simple nature.
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 zero parameters and the schema coverage is 100% (empty schema). Per calibration, 0 params earns a baseline of 4. The description adds no parameter details because none exist, which 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 states a specific verb ('開きます' - opens) and resource ('ポリゴンを描画し、WKT POLYGON文字列を取得するウィジェット'), clearly distinguishing this from all sibling analysis tools. It explains what the tool does and what output it provides.
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 context by listing sibling analysis tools that can consume the WKT output, indicating when this tool is useful as a prerequisite. However, it does not explicitly state when not to use it or mention alternatives, as there are no direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
解析を投入する前に、どの範囲が解析されるかと消費クレジットを確認します。ジョブは作成されず、クレジットも消費しません。 ■ 指定した範囲と実際に解析される範囲は一致しません（シーンが範囲全体を覆っていない場合があります）。 ■ analyze_* を実行する前に必ずこれを呼び、結果をユーザーに提示して承認を得てください。 ■ 引数は analyze_* と同じものをそのまま渡せます。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 基準日（ship / oilslick、YYYY-MM-DD） | |
| polygon | No | WKT形式ポリゴン | |
| date_end | No | 解析終了日（YYYY-MM-DD） | |
| scene_id | No | シーンID（ship / oilslick） | |
| date_start | No | 解析開始日（YYYY-MM-DD） | |
| endpoint_id | Yes | 解析の種別 | |
| satellite_id | Yes | 衛星ID。現在 sentinel-1 のみ対応 | |
| date_direction | No | 基準日に対する選択方向 | |
| orbit_direction | No | 軌道方向（ascending / descending） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, it discloses that the call is side-effect free (no job, no credits), that the analyzed range may not match the requested range because scenes may not cover it, and that user approval is required. This is exactly the kind of non-obvious behavior an agent needs.
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 compact and front-loaded: purpose, side-effect guarantee, caveat, and required workflow are each covered in a short sentence or bullet. No redundant text.
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 read-only preflight tool, it covers what is needed to invoke it correctly and what to do with the result, including the approval step and the range-mismatch caveat. Since the return is conceptually just the analyzed range and credit estimate, no output schema is needed for correct use.
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 a useful cross-tool note that parameters are identical to analyze_*, but it does not explain individual parameter semantics 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?
The description uses a specific verb (確認) and resource (解析範囲と消費クレジット), and explicitly contrasts itself with analyze_* by stating no job is created and no credits are consumed. This makes it easy for an agent to distinguish it from the analyze_* siblings.
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?
It provides a direct mandatory usage rule: 'analyze_* を実行する前に必ずこれを呼び、結果をユーザーに提示して承認を得てください'. It also tells the agent that the same arguments as analyze_* can be passed as-is, removing ambiguity about parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
From first signal to satellite evidence: live world-event intelligence and collection planning.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
Pay-per-call shipping evidence: canal queues, tanker flows, container and carbon exceptions.
Measured ground motion per US address (NASA InSAR). Self-register, $0.40/report, misses free.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
