AI エージェントが ISRO の Bhoonidhi Browse & Order ポータル（NRSC）の衛星シーンを自然言語で検索・保存・ダウンロード・カート追加できるようにする MCP サーバーです。エージェントは「先月のシロン周辺の Sentinel-2」のような文を、ライブポータルに対する実際の検索に変え、ダウンロード可能なものを正直に確認し、検索を保存して後で再利用し、ダウンロードで何が取得されるかをプレビューし、ログイン後はオープンアクセスのシーンをダウンロードしたりカートに追加したりできます。
これは bhoonidhi-downloader SDK（bhd CLI が使うのと同じクライアント）の薄いアダプターであるため、ポータルロジックの重複はありません。
ログインなしで検索と保存、ログインありでダウンロードとカート。 ツールは41の衛星ミッションと79のセンサーからなる全アーカイブに到達し、ライブポータルを検索し、検索を再利用可能なスラッグに保存します。これらはすべて認証なしで行えます。オープンアクセスシーンのダウンロードと Bhoonidhi カートへの追加にはログインが必要で、bhd auth login で帯域外に行います（サーバーはそのセッションを再利用します）。
Related MCP server: Google Earth Engine MCP Server
ツール | 説明 | ログイン |
| ポータルがサポートする衛星・センサー・検索トークンの語彙を、Bhoonidhi からライブで取得します。 | 不要 |
| 地名（"Loktak Lake"）を重心点とバウンディングボックスに変換します。地名でない入力は拒否します。 | 不要 |
| エリアと日付範囲に対する自然言語でのシーン検索です。カジュアルな衛星名を正確なトークンに解決し、各シーンの利用可否（Ready / Archived / OnOrder / Priced）を報告します。ステートレスで、何も保存しません。 | 不要 |
| ドライランです。ダウンロード前に、結果のダウンロードで取得されるものとスキップされるものを表示します。 | 不要 |
| 検索（ | 不要 |
| 保存済みクエリを、スラッグ、名前、日付範囲、衛星、エリア、利用可否のコンパクトな要約として一覧表示します。 | 不要 |
| スラッグで指定した保存済みクエリを、そのシーンとともに返します。 | 不要 |
| スラッグで指定した保存済みクエリを削除します。 | 不要 |
| ログインが設定されているかどうかを報告します。パスワードやトークンを扱うことはありません。 | 不要 |
| 保存済みクエリのオープンアクセスシーンを、サーバー設定の固定ルートにバックグラウンドでダウンロードします。すぐに | 必要 |
|
| 不要 |
| ダウンロードが完了するまで（または上限タイムアウトまで）ブロックしてから報告します。バックグラウンドウォッチャーがループする効率的なプリミティブです。 | 不要 |
| 保存済みクエリのシーンをカートに追加します（それぞれを ready / on-order / priced に振り分けます）。 | 必要 |
| 現在カートに追加されているシーンを一覧表示します。 | 必要 |
| カートからシーンを削除します。 | 必要 |
可用性は重要です。OpenData シーンが必ずしもダウンロード用にステージングされているとは限りません。search_scenes と preview_download は、Ready（今すぐ取得）と Archived（オープンデータだが、最初にポータルでのリクエストが必要な場合がある）を区別するため、エージェントが過剰に約束することはありません。
ダウンロードは会話とは独立してバックグラウンドで実行されます。download_query はすぐに job_id を返し、転送は自動的に進行します。download_status で進行状況を一度確認できます（ダウンロード済みバイト数、転送レート、サイズが判明している場合はパーセントを報告）。または、download_wait でジョブの完了を待つこともできます。これは、完了するまで（または上限タイムアウトまで）ブロックするため、エージェントはスリープループする代わりにバックグラウンドウォッチャーに委任して会話を続行できます。ジョブはサーバープロセスが存在する間だけ有効です。そのため、ダウンロードが大きくなった場合、ステータスは、代わりにスタンドアロンの bhd query download <slug> コマンドを実行することを推奨します。
サーバーはコンソールエントリポイント bhoonidhi-mcp を持つ Python パッケージです。uv を使用してソースからインストールします。
git clone https://github.com/geovicco-dev/bhoonidhi-mcp
cd bhoonidhi-mcp
uv syncこれにより、bhoonidhi-mcp コマンドが .venv/bin/bhoonidhi-mcp に公開されます。サーバーは stdio を話し、MCP クライアントによって起動されます。クライアントをそのコマンドに向けます。
すべての MCP クライアントが必要とするものは同じです。起動するコマンドです。エントリポイントへの絶対パスを使用してください（GUI クライアントと CLI クライアントの両方で最も信頼性が高いです）。
/path/to/bhoonidhi-mcp/.venv/bin/bhoonidhi-mcpclaude_desktop_config.json（または claude mcp add）:
{
"mcpServers": {
"bhoonidhi": {
"command": "/path/to/bhoonidhi-mcp/.venv/bin/bhoonidhi-mcp",
"args": []
}
}
}~/.config/opencode/opencode.json:
{
"mcp": {
"bhoonidhi": {
"type": "local",
"command": ["/path/to/bhoonidhi-mcp/.venv/bin/bhoonidhi-mcp"],
"enabled": true
}
}
}npx @modelcontextprotocol/inspector /path/to/bhoonidhi-mcp/.venv/bin/bhoonidhi-mcpエージェントに平易な言葉で尋ねます。
「2024年1月のシロン周辺の Sentinel-2 シーンは何件あり、実際にダウンロードできるのは何件ですか？」
エージェントは resolve_location をシロンに対して呼び出し、次に search_scenes を呼び出して、結果から回答します。たとえば、すべてのシーンが Archived（オープンデータだが、ダウンロード前にポータルでのリクエストが必要な場合がある）であると、すべて準備完了であると主張するのではなく報告します。
接続されているエージェントにコピーして、何ができるかを確認してください。
アーカイブを調べる
「Bhoonidhi にはどのような衛星とセンサーがありますか？」
「ResourceSat-2A にはどのセンサーが搭載され、解像度はどれくらいですか？」
「Bhoonidhi にレーダー衛星はありますか？」
シーンを検索する
「2024年1月のシロン周辺の Sentinel-2 シーンを探してください。」
「2024年上半期のベンガルールから20km以内の Cartosat 画像を表示してください。」
「2024年3月のシュンダルバン周辺の Sentinel-1 シーンはありますか？」
「昨年の冬にカジランガ国立公園をカバーする Landsat-8 画像はどれですか？」
「2023年12月のカッチ大湿原周辺の MODIS シーンを探してください。」
ダウンロード可能なものを確認する
「それらの Sentinel-2 シーンのうち、今すぐ実際にダウンロードできるのは何件ですか？」
「これらのうち、注文または有料が必要なものはどれですか？」
ダウンロードをプレビューする
「それらのシーンをダウンロードすると何が取得されるかプレビューしてください。」
再利用する検索を保存する
「後でダウンロードできるように、その Sentinel-2 検索を保存してください。」
「保存した検索を一覧表示してください。」
「 として保存した検索の内容を表示してください。」
「保存した検索 を削除してください。」
ダウンロードとカート（ログインが必要です。下記参照）
「Bhoonidhi にログインしていますか？」
「保存した検索 からオープンデータのシーンをダウンロードしてください。」
「そのダウンロードはどうなっていますか？」
「 をダウンロードして、完了したら知らせてください。作業を続けます。」
「 の有料シーンをカートに追加してください。」
「今週のカートの中身は何ですか？」
検索、保存済みクエリ、プレビューには認証情報は必要ありません。シーンのダウンロードとカートへの追加には必要です。帯域外で一度ログインしてください。サーバーは bhd CLI が書き込むのと同じセッションを再利用します。
bhd auth loginMCP サーバーはツールの引数としてユーザー名やパスワードを受け取ることはなく、auth_status がトークンを返すこともありません。対話的なログインがないヘッドレスセットアップの場合は、代わりにサーバーの環境変数 BHOONIDHI_USERNAME / BHOONIDHI_PASSWORD を設定できます。サーバーはセッションを確立するためだけにこれらを読み取ります。
環境変数として設定します（すべてオプションです）。
変数 | デフォルト | 目的 |
|
| Nominatim に送信する User-Agent です（利用規約で説明的なものを求められています）。 |
|
| 衛星名の一致が確信を持てるためにクリアすべきスコア（0〜100）です。これを下回る場合は、エージェントが確認するための候補が返されます。 |
|
|
|
|
| すべてのダウンロードの書き込み先となる許可リスト化されたルートで、 |
|
| 並列ダウンロードのワーカー数です。 |
|
| ダウンロードのライブバイト合計（または既知のサイズ）がこれを超えると、ステータスはそれを大規模とフラグし、エージェントに引き継ぎまたはスタンドアロンコマンドの実行を促します。 |
| (未設定) | オプションのヘッドレスログインです。 |
uv sync
uv run pytest # test suite
uv run ruff check . # lintMIT — LICENSE を参照してください。
Report whether a Bhoonidhi login is configured for downloads and cart.
Never asks for or returns a password or token. If credentials are set in the server's environment (BHOONIDHI_USERNAME / BHOONIDHI_PASSWORD) it establishes the session so the answer matches what a download or cart action would find. Returns authenticated=True with the username when a usable session exists, or authenticated=False with guidance to log in ('bhd auth login' out of band, or set those environment variables). Call this before download or cart actions to tell the user if a login is needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It states that the tool never asks for or returns passwords or tokens, may establish a session using environment credentials, and returns specific shapes (authenticated=True with username, or authenticated=False with guidance). This is rich, honest behavioral context.
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 longer than a single sentence, but every line earns its place: purpose, security guarantee, credential source, session behavior, return values, and usage timing. It is front-loaded with the core purpose and structured in readable short paragraphs.
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 status tool with no output schema, the description fully specifies return values, the conditions that produce them, and the follow-up guidance the agent should convey. There are no missing required behaviors.
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?
There are zero parameters and schema coverage is 100%, so there is no parameter behavior for the description to clarify. The baseline of 4 applies because nothing further is needed.
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—report—and a clear resource: whether a Bhoonidhi login is configured for downloads and cart. It distinguishes itself from sibling tools like download_status and cart_list by focusing on authentication readiness, and the closing instruction 'Call this before download or cart actions' makes the tool's role unmistakable.
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 says to call this before download or cart actions to tell the user if a login is needed, and it gives concrete fallback authentication methods ('bhd auth login' or environment variables). It does not enumerate exclusions or explicitly compare against sibling alternatives, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stage a saved query's scenes to the Bhoonidhi cart.
Give the slug from save_query or list_queries. Each scene is routed to the cart its access type needs (ready / on-order / priced); select narrows to specific scenes (1-based indices or scene IDs). Needs a login (see auth_status). Use this for on-order and priced scenes; priced ones still need purchasing on the portal afterwards. Returns counts of what was staged and what failed.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| select | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden and meets it: it discloses the auth requirement, the routing behavior by access type (ready/on-order/priced), the non-obvious limitation that priced scenes still require purchasing on the portal afterward, and the return shape (counts of staged and failed). None of this could be inferred from the name or bare schema.
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?
Five short sentences, each carrying distinct information: purpose, slug provenance, routing and select mechanics, login prerequisite, usage guidance with limitation, and return value. The purpose is front-loaded and no sentence is filler.
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 moderate-complexity tool with no annotations and no output schema, the description covers everything needed to call it correctly: what it does, where the required slug comes from, selection semantics, required auth, workflow caveats, and return format. The only minor ambiguity, whether ready scenes should also be added here, does not block correct invocation.
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 0%, and the description fully compensates: slug is explained as coming from save_query or list_queries, and select is clarified as narrowing to specific scenes via 1-based indices or scene IDs. The bare schema provides only the titles 'Slug' and 'Select', so the description is the sole source of semantic meaning.
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?
Opens with a specific verb-resource-destination statement: 'Stage a saved query's scenes to the Bhoonidhi cart,' which names the action, the input resource, and the target. It is immediately distinguishable from siblings like cart_remove, cart_list, and save_query by referencing saved-query scenes and the staging-to-cart behavior.
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?
Gives explicit when-to-use context ('Use this for on-order and priced scenes'), a prerequisite ('Needs a login (see auth_status)'), and an input source ('Give the slug from save_query or list_queries'). It stops short of a 5 because it never names alternative tools for exclusion, e.g., what to use for ready scenes or for completing purchases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scenes currently staged in the Bhoonidhi cart.
Cart items are filed by the date they were added; with no window this shows today only, so pass since/until (ISO dates, e.g. "2026-08-10") or last (e.g. "1 week") to widen it. filter_by limits to a state: ready, archived, onorder, or priced. Needs a login (see auth_status).
| Name | Required | Description | Default |
|---|---|---|---|
| last | No | ||
| since | No | ||
| until | No | ||
| filter_by | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that no window means today only, that filtering is by state, and that authentication is required. It does not describe output format or failure behavior, but for a basic listing tool this is adequate.
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 with the core purpose. Each additional sentence earns its place by explaining a parameter behavior, a default, or an auth prerequisite. No filler or repetition.
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 covers all optional parameters, the default date window, filter states, and authentication. There is no output schema, so return details are not specified, but 'List scenes' conveys the primary result. Minor gaps around ordering or pagination prevent a 5.
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 0%, and the description fully compensates by explaining since/until with ISO date examples, last with a relative example, and filter_by with explicit allowed values. Every parameter is given meaningful semantic context beyond the bare 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 states a specific verb and resource: 'List scenes currently staged in the Bhoonidhi cart.' This clearly identifies the tool's function. It does not explicitly contrast itself with siblings like list_archive, but the name and wording are sufficiently distinct.
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: default to today only, how to widen with since/until/last, filter_by allowed states, and the login requirement. It does not explicitly mention when to prefer this over search_scenes or list_archive, but the guidance is otherwise solid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove scenes from the Bhoonidhi cart.
Two ways to address rows: pass slug to index a saved query's scenes, or omit it and let select index the merged cart itself (the same row numbers cart_list shows under the same since/until/last/filter_by window). Needs a login (see auth_status).
| Name | Required | Description | Default |
|---|---|---|---|
| last | No | ||
| slug | No | ||
| since | No | ||
| until | No | ||
| select | No | ||
| filter_by | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the login requirement and the subtle row-indexing semantics for select, which is useful. However, it is silent on whether slug-mode mutates the saved query, whether removal is reversible, and what happens on invalid select/slug input.
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, front-loaded with the core purpose, and then adds the necessary mode/auth context. Every sentence contributes meaningful guidance with no filler.
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 sufficient for understanding the two addressing modes and the auth dependency. However, with no output schema and no mention of return values, errors, or slug-mode effects on the saved query, an agent may still be uncertain about observable outcomes.
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 0%, so the description must compensate. It explains the key parameters: slug switches indexing to a saved query's scenes, while select indexes the merged cart when slug is omitted. It also ties since/until/last/filter_by to the cart_list window, though individual formats and allowed values are not specified.
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 first line states a specific action ('Remove scenes') and resource ('Bhoonidhi cart'), so the core purpose is clear. It does not explicitly distinguish itself from sibling remove_query beyond the word 'scenes' versus 'query,' which prevents a perfect 5.
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 gives clear operational guidance for the two addressing modes: pass slug to reference a saved query's scenes, or omit it and use select on the merged cart under the same cart_list window. It also notes the login prerequisite, but does not explicitly state when to prefer remove_query or what preconditions each mode requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a saved query's open-access scenes in the background.
Give the slug from save_query or list_queries. Downloads run to a fixed, server-configured root (BHOONIDHI_MCP_DOWNLOAD_ROOT, default ~/Downloads), under a per-slug folder — you cannot choose an arbitrary path. select narrows to specific scenes (1-based indices or full scene IDs); omit it for the whole query. force re-downloads files already present.
Needs a login (see auth_status). Priced and on-order scenes are skipped — stage those with cart_add instead. Returns immediately with a job_id: the download runs on its own and does NOT depend on this conversation, so never block by sleeping and re-polling. To follow it hands-free, delegate a background watcher that loops download_wait on the job_id and reports back, keeping you free to keep talking; the result's 'handoff' note says so. File sizes are unknown until each transfer starts (the portal reveals them only then); once a download proves large, download_status/download_wait flag it and 'large_download' offers a standalone command that outlives this session. Interrupted downloads restart from scratch (no resume support).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| force | No | ||
| select | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and discharges it thoroughly. It discloses that the tool returns immediately with a job_id, runs independently of the conversation, writes to a fixed server-configured root the user cannot override, restarts interrupted downloads from scratch with no resume support, and hides file sizes until a transfer begins. These are exactly the operational surprises an agent needs to know before calling.
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 long (~250 words) but front-loaded with the core purpose and heavily information-dense; nearly every sentence adds operational value, including the async watcher pattern and the large_download handoff. A few parentheticals ('the portal reveals them only then') are slightly redundant, so it is not perfectly tight, but the length is largely justified by the tool's 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?
Given no output schema and no annotations, this description is remarkably complete for a complex async tool. It covers prerequisites, parameter semantics, return value (job_id), the asynchronous lifecycle, failure behavior, exclusions, and alternatives — including the non-obvious advice to delegate a background watcher via download_wait. Nothing an agent needs to invoke and supervise this tool correctly is left unspecified.
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 0%, so the description must fully compensate, and it does. slug is grounded ('Give the slug from save_query or list_queries'), force is explained ('re-downloads files already present'), and select gets richer semantics than the bare schema: '1-based indices or full scene IDs; omit it for the whole query.' Every parameter is given meaning the schema alone cannot convey.
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 opening sentence, 'Download a saved query's open-access scenes in the background,' states a specific verb (download), a precise resource (a saved query's open-access scenes), and the execution mode (background). It differentiates clearly from siblings: preview_download (previews rather than downloads), download_status/download_wait (monitor rather than initiate), and search_scenes (searches rather than downloads).
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 is explicit about when to use this tool: it tells the agent where to get the slug ('from save_query or list_queries'), names a prerequisite ('Needs a login (see auth_status)'), and gives specific exclusions with alternatives ('Priced and on-order scenes are skipped — stage those with cart_add instead'). It also instructs how NOT to use it (never block by sleeping and re-polling) and directs to the watcher/download_wait pattern and large_download for oversized transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a background download started by download_query (one-off).
Give the job_id from download_query. Returns the live state: running (with bytes_downloaded, mb_downloaded, rate_mb_s, percent when the total size is known, and per-scene detail), completed (with per-scene outcomes), or failed (with the error). Use this for a single progress check. To follow a job to completion without tying up the conversation, use download_wait from a delegated watcher instead. Jobs exist only while the server runs; an unknown id returns status="not_found".
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does this well by describing the possible states (running, completed, failed, not_found), key progress fields, and the job lifecycle caveat that jobs exist only while the server runs. It stops short of stating explicit non-mutating behavior, but the status-check semantics make that reasonably clear.
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 yet information-dense. The main purpose is front-loaded in the first sentence, and every subsequent sentence contributes meaningful detail about states, usage, alternatives, or lifecycle. No filler or repetition.
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?
There is no output schema, so the description correctly takes on the job of explaining return shapes: running fields, completed outcomes, failed error, and not_found. For a simple one-parameter status tool, this covers everything an agent needs to invoke it correctly and interpret its result.
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 only provides a bare 'job_id' property with no description (0% coverage), so the description must compensate. It does so directly: 'Give the job_id from download_query' tells the agent exactly where the value comes from, and the not_found behavior clarifies what happens with an invalid 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?
Description opens with a specific action and resource: 'Check a background download started by download_query'. It clearly identifies this as a one-off status check, and the contrast with download_wait distinguishes it from the most similar sibling.
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 tells the agent when to use this tool: 'Use this for a single progress check.' It also names the alternative, download_wait, and the condition for choosing it: following a job to completion without tying up the conversation via a delegated watcher. It even explains how to obtain the required job_id from download_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a background download to finish, then report — for a watcher.
Give the job_id from download_query. Blocks inside the server and returns as soon as the download completes or fails, or after timeout_s (capped at 120s) with the latest progress if still running. This is the efficient way to follow a job: a delegated background watcher calls it in a loop and stops when status is "completed" or "failed", so the main conversation is never blocked on sleeps. Prefer this over repeated sleep+download_status. An unknown id returns status="not_found".
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses that the tool blocks server-side, returns on completion/failure/timeout, caps timeout_s at 120s, returns progress when still running, and returns status='not_found' for unknown ids.
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 front-loaded with a one-sentence summary, then expands with precise behavioral details and usage guidance. Every sentence adds value, and there is no filler or 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?
Despite lacking an output schema and annotations, the description covers all needed operational aspects: blocking behavior, timeout semantics, status values, unknown-id handling, and the recommended loop pattern. An agent can call this tool correctly with the information provided.
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 0%, but the description compensates strongly. It identifies job_id as coming from download_query and explains the behavior and cap for timeout_s. This gives the agent meaningful semantics beyond the bare 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 states a specific verb and resource: wait for a background download to finish and report. It also distinguishes itself from sibling tools by referencing download_query for job_id and positioning itself against repeated sleep+download_status calls.
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 when to use this tool: in a watcher loop to follow a job efficiently. It also names the alternative pattern it replaces (repeated sleep+download_status) and explains the stopping condition based on status values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every satellite and sensor the Bhoonidhi portal supports.
Returns the vocabulary of valid satellites, sensors, and exact search tokens, with each product's resolution and date coverage. Call this to discover what can be searched. Set refresh=True to bypass the local cache.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does well by revealing the tool returns vocabulary data with resolution and date coverage, and that results are locally cached unless refresh=True is set. It does not mention authentication requirements or rate limits, but for a simple read-only listing tool this is reasonably transparent.
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 three short sentences with no filler. It front-loads the action and resource, then adds return-value details and parameter behavior. Every sentence contributes necessary 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?
For a simple read-only tool with one optional parameter and no output schema, the description is largely complete: it explains what is returned and how to refresh cached data. It could also state whether authentication is required or what the default cache behavior means in practice, but these are minor omissions for this 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 schema provides only a title and default for the refresh parameter, with 0% description coverage. The description compensates by giving the exact semantic: 'Set refresh=True to bypass the local cache.' This tells the agent how the parameter affects behavior, which is the key information needed.
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: 'List every satellite and sensor the Bhoonidhi portal supports.' It further clarifies the return value as the vocabulary of valid satellites, sensors, exact search tokens, resolution, and date coverage. This clearly distinguishes it from sibling tools like search_scenes or cart operations.
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 when to call the tool: 'Call this to discover what can be searched.' It also explains when to set refresh=True to bypass the local cache. However, it does not explicitly contrast this with alternatives or mention when not to use it, though the sibling list makes the distinction fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every saved query as compact summaries.
Returns each saved query's slug, name, date range, satellites, area of interest, scene count, and a plain-English availability summary — but not the full scene lists (call show_query for one query's scenes). Use this to find the slug for a query the user saved earlier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses exactly what fields are returned, that results are compact summaries, that full scene lists are omitted, and that availability is summarized in plain English. It does not discuss authentication, pagination, or error behavior, but for a zero-parameter list tool the core behavior is transparent.
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 front-loaded with the core purpose, then lists return fields, then states the key exclusion and points to the alternative. Every sentence adds value and none are redundant.
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 no-input list operation with no output schema, the description is complete: it says what is returned, what is not returned, how to get the fuller data, and what the intended use case is. There are no gaps that would prevent an agent from invoking the tool correctly.
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 takes no parameters, so there are no parameter semantics to clarify. The description appropriately focuses on the output shape rather than inputs, satisfying the baseline expected 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 starts with a precise verb and resource: 'List every saved query as compact summaries.' It clearly distinguishes itself from show_query by stating it returns summaries, not full scene lists, and explicitly routes to show_query for scenes.
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 when to use the tool: 'Use this to find the slug for a query the user saved earlier.' It also names the alternative, show_query, for full scene lists, giving an agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run a download for a search: show what would be fetched, no login.
Takes the same arguments as search_scenes, plus out_dir (where files would go) and force (preview re-downloading files already present). It runs the search and predicts, per scene, what a real download would do: would_download (staged, ready), may_404 (open data but archived — attempted but may fail until requested on the portal), already_here / already_elsewhere (a matching file exists), or skipped_on_order / skipped_priced (needs the portal).
Use this before telling a user to download, so they know how many scenes are actually fetchable. Nothing is downloaded and no login is used. File sizes are not known until a download starts (the portal exposes them only in the download response headers), and interrupted downloads cannot be resumed — both are stated in the result's disclaimers.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| maxx | No | ||
| maxy | No | ||
| minx | No | ||
| miny | No | ||
| force | No | ||
| sensor | No | ||
| out_dir | No | ./downloads | |
| product | No | ||
| end_date | Yes | ||
| radius_km | No | ||
| satellite | Yes | ||
| start_date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: no login is used, nothing is downloaded, per-scene prediction statuses are enumerated, and important limitations are surfaced (file sizes unknown until download starts, interrupted downloads cannot be resumed). This goes well beyond the minimum expected.
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 front-loaded with the core purpose and stays organized: scope, argument relationship, status categories, usage recommendation, and caveats. Every sentence contributes meaningful information without 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?
Despite having no output schema, the description explains the prediction statuses and disclaimers sufficiently for an agent to know what the tool returns and what limitations apply. It also covers login behavior, download behavior, and how this tool fits into the download workflow, making it complete for a 14-parameter 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 0%, so the description must compensate. It explicitly explains out_dir and force, and references 'same arguments as search_scenes' for the rest, which adds semantic meaning beyond the raw schema. However, individual search parameters like lat, minx, sensor, and product are not described here, relying on the sibling tool's definition.
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 clear verb and resource: 'Dry-run a download for a search,' which immediately distinguishes it from the actual download tools. It also clarifies it shares arguments with search_scenes, further disambiguating it from siblings like download_query or search_scenes.
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 explicitly states when to use it: 'Use this before telling a user to download, so they know how many scenes are actually fetchable.' It also contrasts itself with a real download by noting 'Nothing is downloaded and no login is used,' and references search_scenes for argument compatibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a saved query by slug.
Give the slug from save_query or list_queries. Removes the saved query from disk; the scenes themselves are unaffected. Returns status="not_found" if no query has that slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It states that the query is removed from disk, that scenes remain unaffected, and that a not_found status is returned for unknown slugs. This is strong behavioral coverage for a one-parameter destructive 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?
Three tight sentences, no filler. The primary action is front-loaded, followed by necessary sourcing and side-effect details. 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?
For a simple tool with one required parameter and no output schema, the description covers the action, the slug source, the side effect, and the error case. Nothing essential is missing for an agent to invoke it correctly.
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 0%, so the description must add meaning. It does so by explaining that slug comes from save_query or list_queries and that an unmatched slug produces not_found. This gives the parameter semantic context beyond its bare string type.
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: 'Delete a saved query by slug.' This clearly differentiates it from sibling tools like save_query, list_queries, and show_query, leaving no ambiguity about the operation.
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 explicitly tells the agent where to obtain the required slug: 'Give the slug from save_query or list_queries.' It also clarifies a non-effect (scenes unaffected), which helps set correct expectations. It does not list explicit when-not-to-use cases, but no sibling tool performs the same deletion role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a place name to a centroid and bounding box.
Turns a place like "Shillong" or "Loktak Lake" into latitude/longitude and a bounding box (minx, miny, maxx, maxy) that search_scenes can use as its area of interest. Returns found=False when the place can't be resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the output shape (centroid plus bounding box) and the failure mode (found=False when the place cannot be resolved). It omits potential ambiguity or coordinate system details, but this is adequate for a simple lookup 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?
The description is compact and well-structured, leading with the core purpose, then adding an illustrative example, the concrete output format, downstream use, and the failure case. Every sentence adds 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 single-parameter tool with no output schema, this description is complete: it tells the agent what to pass, what will come back, what the failure signal is, and how the result connects to a sibling tool. No critical context 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 schema provides only a 'name' string with no description, so the description must compensate. It clarifies that 'name' is a natural-language place name and provides concrete examples. It does not over-specify format, which is appropriate for free-form place names.
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: resolving a place name to a centroid and bounding box. It gives concrete examples ('Shillong', 'Loktak Lake') and clearly distinguishes this geocoding-style tool from sibling data-management/search 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?
It clearly states the intended downstream usage: the bounding box can be used as the area of interest for search_scenes. This gives an agent strong contextual guidance, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a search as a saved query and return a reusable slug.
Takes the same arguments as search_scenes, plus an optional name and description. Unlike search_scenes (which is stateless and leaves nothing behind), this saves the search on the portal so it can be acted on later: the returned slug is what downloading and cart staging key off. Call this once the user has confirmed a search returns the scenes they want, then hand the slug to the bhd CLI (download / cart) until those actions land in-server.
Returns status="ok" with the slug and the shaped saved query. If the satellite is ambiguous or the request is invalid, returns the same status="ambiguous_satellite" / "invalid_request" shapes as search_scenes, and saves nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| maxx | No | ||
| maxy | No | ||
| minx | No | ||
| miny | No | ||
| name | No | ||
| sensor | No | ||
| product | No | ||
| end_date | Yes | ||
| radius_km | No | ||
| satellite | Yes | ||
| start_date | Yes | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses the stateful persistence side effect, that nothing is saved on error, and the exact status shapes returned. This is strong behavioral disclosure for a stateful 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?
The description is longer than a minimal one, but each section adds distinct value: purpose, sibling contrast, invocation timing, return shapes, and error behavior. The core purpose is front-loaded, though some wording around 'shaped saved query' and the bhd CLI could be tightened.
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 14-parameter stateful tool with no annotations and no output schema, the description covers the key operational facts: what is created, what is returned, how the slug is used, and what happens on error. The main gap is that authentication requirements and the exact structure of the 'shaped saved query' are not specified.
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?
At 0% schema coverage, the description compensates partially by saying it takes the same arguments as search_scenes plus optional name and description. This is a useful semantic anchor, but it delegates most parameter meaning to another tool and does not explain formats or the roles of satellite, dates, or geometry fields.
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: 'Persist a search as a saved query and return a reusable slug.' It clearly distinguishes this from the stateless search_scenes sibling by saying what save_query does that search_scenes does not.
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 explicit when-to-use guidance: call it once the user has confirmed the search returns the desired scenes, then use the slug with download/cart. It also contrasts it against search_scenes, which is stateless and leaves nothing behind, making the alternative condition clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Bhoonidhi scenes for a satellite over an area and date range.
The satellite may be a casual name ("Sentinel-2", "cartosat"); it is matched to the portal's exact tokens, and a constellation expands to all its platforms. Dates are ISO (YYYY-MM-DD). Give the area either as a bounding box (minx/maxx/miny/maxy) or a point with radius (lat/lon/radius_km) — typically from resolve_location. sensor narrows to one sensor on the matched satellite(s) (e.g. "SSAR", "LISS3"); product further narrows to one product under that sensor (e.g. "GCOV", "L2C-Chlorophyll") — see list_archive for the exact sensor/product names each satellite carries. The search is stateless and needs no login.
If the satellite name is ambiguous, returns status="ambiguous_satellite" with candidate names instead of guessing.
Each scene carries an "availability": Ready (downloadable now), Archived (open data but may need a portal request first), OnOrder (must be requested), or Priced (must be purchased). The result includes a plain-English "summary" of these counts and a "how_to_act" block. Tell the user clearly when scenes are Archived, OnOrder, or Priced and what each needs. This search is stateless: to act on these scenes, call save_query with the same arguments to persist them and get a , then download_query (open data) or cart_add (on-order / priced) on that slug — both need a login (see auth_status). Downloads cannot be resumed if interrupted (the portal has no range support).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lon | No | ||
| maxx | No | ||
| maxy | No | ||
| minx | No | ||
| miny | No | ||
| sensor | No | ||
| product | No | ||
| end_date | Yes | ||
| radius_km | No | ||
| satellite | Yes | ||
| start_date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses statelessness, no-login requirement, ambiguous-satellite behavior, availability categories (Ready/Archived/OnOrder/Priced), and the non-resumable download limitation. This is far beyond what the schema alone would communicate.
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 and front-loaded with the core purpose, then details. It is dense but justifiably so for a 12-parameter tool. Minor redundancy exists: 'stateless' is stated twice and the download-resume note is tangential to searching, so it loses a point.
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 no output schema and no annotations, this description covers all essential context: what the tool does, how to specify each kind of input, what the response classes mean, how to handle ambiguity, and exactly which sibling tools to call next. Very little is left for an agent to guess.
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 0%, but the description compensates thoroughly: it explains satellite name matching, ISO date format, the bbox vs. point-with-radius area alternatives, and how sensor/product narrow results. It meaningfully clarifies nearly every parameter group in 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: 'Search Bhoonidhi scenes for a satellite over an area and date range.' It clearly describes the scope and outputs, and distinguishes itself from downstream persistence/action siblings by explicitly framing the search as stateless.
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 strong routing guidance: use resolve_location for area input, list_archive for exact sensor/product names, and save_query/download_query/cart_add for acting on results. It also clarifies that search needs no login while downstream actions do, so an agent knows when this tool is the right entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one saved query by slug, with its scenes.
Give the slug from save_query or list_queries. Returns the full saved query: its selections, area of interest, date range, and shaped scenes with availability. Returns status="not_found" if no query has that slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because no annotations are provided, the description carries the full behavioral burden. It discloses the return payload—selections, area of interest, date range, shaped scenes with availability—and the not_found status for missing slugs. It doesn't explicitly state read-only semantics or auth prerequisites, but for a retrieval tool this is solid coverage.
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 in the first line, input source in the second, then return details. Every sentence adds useful information with no filler.
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 one-parameter read tool with no output schema and no annotations, the description covers purpose, parameter provenance, return shape, and an error case. An agent can confidently call it and interpret the response correctly.
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 0% and the schema only defines slug as a string. The description compensates by explaining that the slug comes from save_query or list_queries and that an unknown slug returns status='not_found', adding meaning beyond the bare 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: 'Return one saved query by slug, with its scenes.' This clearly identifies the tool as single-query retrieval, distinct from list_queries which lists queries, and from remove_query which deletes 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?
It gives concrete guidance on where the slug comes from: 'Give the slug from save_query or list_queries.' This helps the agent know this tool is for already-saved queries and how to obtain valid input, though it does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0auth_statuscart_addcart_listcart_removedownload_querydownload_statusdownload_waitlist_archivelist_queriespreview_downloadremove_queryresolve_locationsave_querysearch_scenesshow_queryScored across 15 tools
Each tool targets a distinct action or resource: search is separated from preview, save, download, and cart operations, and download_status vs download_wait are clearly one-off vs watcher. Even where arguments overlap, the descriptions draw explicit boundaries.
Most query tools follow verb_noun (remove_query, search_scenes, list_queries), but cart_* uses noun-verb order (cart_add, cart_list) and auth_status/download_status/download_wait are noun-phrase style. Everything is snake_case and readable, but the naming pattern is mixed rather than uniform.
15 tools is within the ideal range, and each tool covers a distinct stage of the archive-to-download/cart workflow. There is no apparent redundancy or padding.
The set covers discovery, geocoding, search, dry-run preview, saved-query lifecycle, auth status, download execution/monitoring, and cart management. Minor gaps like no in-server edit of saved queries, no active-download listing, and no direct archival request action are workarounds via the portal or CLI.
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
