Claude Desktop용 MCP 서버로, 선택한 영역에 대해 실제 ICESat-2 ATL03 광자와 ICESat/GLAS GLAH06 샷을 가져와 3D 포인트 클라우드(deck.gl)로 렌더링하고, 토글 시 pyproj로 ITRF2014 + 에포크 공동 정합(판 운동, ITRF2014-PMM / NOAM)을 적용하여 동일 위치의 Δh 통계를 갱신합니다. 전체 설계와 근거를 담은 docs/cross-mission-altimetry-mcp-spec.md에서 시작되었습니다.
공동 정합은 에포크 사이의 판 운동을 제거합니다. 빙류, GIA, 지오이드/조석, 펀 압밀, 수직 기준면은 제거하지 않으며, 위젯은 모든 답변에서 이를 명시합니다. GLAS 높이는 제품의 d_deltaEllip을 사용해 TOPEX/Poseidon → WGS84 타원체로 변환되고, 포화 보정 d_satElevCorr이 적용됩니다. 이는 모든 comparability 블록에 기록됩니다.
uv sync # Python 3.13
uv run pytest # offline unit testsEarthdata Login: bearer 토큰은 ~/.edl/token.prod에서 읽습니다(AICESAT_EDL_FILE로 재정의하거나 EARTHDATA_TOKEN을 설정). 서버는 stdout에 절대 쓰지 않습니다(stdio MCP 전송). 로그는 stderr로 나갑니다.
Related MCP server: mcp-opentopography
~/Library/Application Support/Claude/claude_desktop_config.json에 체크아웃한 경로의 절대 경로를 사용하여 추가하세요:
{
"mcpServers": {
"aicesat": {
"command": "/opt/homebrew/bin/uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/aicesat", "run", "aicesat-server"]
}
}
}Claude Desktop을 다시 시작하세요. 통합 UI는 MCP App으로 인라인 렌더링되며, 서버는 브라우저에서 사용할 수 있도록 http://127.0.0.1:8765/에서도 제공합니다(포트는 AICESAT_PORT).
도구: open_ui, list_regions, list_scenes, check_coverage, show_photons (region, bbox 또는 polygon), add_glas, coregister, lake_status, lake_load_cells, job_status.
하나의 자체 포함된 페이지(scripts/build_ui.py가 src/aicesat/ui/* 및 번들된 deck.gl / h3-js로 순수 Python으로 빌드하고, 소스가 변경되면 서버는 시작 시 이를 다시 빌드)로서 Claude Desktop 안에 인라인으로, 그리고 /에서 제공됩니다:
Explore — 3D 지구본(Natural Earth 베이스맵, 평면 투영 없음). 어디든 탐색하고, 상자 또는 다각형을 그리고, 적용 범위를 확인하고, 백그라운드 작업으로 장면을 빌드할 수 있습니다. 장면 풋프린트와 로드된 H3 셀이 지구본에 표시됩니다.
Lake — H3 그리드로 표시되는 영구 Parquet 레이크: 호버 시 셀별 통계, 가장 오래 사용되지 않은 셀을 자동으로 축출하는 저장 한도, 선택한 셀의 백그라운드 로딩 또는 축출.
Scene — 3D 뷰어: DEM 위에 드레이프된 ICESat-2 및 GLAS 포인트, 보정 토글이 있는 Adjustments 패널, 동일 위치의 Δh 히스토그램. 실제 판 운동 변위는 장면 축척에서 서브픽셀이므로 점 구름은 눈에 보이게 움직이지 않습니다. 효과는 과장된 시각 효과가 아니라 Δh 패널에서 읽힙니다. 패널은 접고 닫을 수 있습니다.
UI는 전송 중립적 API(api.py)와 통신하며 두 가지 방식으로 노출됩니다: 브라우저용 localhost /api/* 라우트와 인라인 앱을 위해 호스트가 프록시하는 visibility:["app"] MCP 도구입니다. scripts/e2e_apps.py는 MCP-App 연결을 확인합니다.
ATL03 경로는 쿼리 시점에 HDF5를 열지 않습니다. 각 granule에 대해 인덱스 빌드(index.py)는 각 청크의 바이트 범위, 필터 파이프라인, 그리고 그 청크가 걸치는 H3 셀을 기록합니다. 쿼리는 bbox/폴리곤을 셀로 해석하고, HTTPS 범위 요청(EDL 베어러 토큰 → 사전 서명된 URL)으로 필요한 청크만 가져온 뒤 HDF5 라이브러리 없이 디코딩하여 광자를 hive 파티셔닝된 Parquet 레이크(lake.py)에 행별 출처 및 공동 정합 좌표와 함께 구체화합니다. DuckDB는 레이크에 대한 쿼리에 응답하며(api.py), coverage 테이블은 무엇이 구체화되었는지 기록하므로 반복 쿼리는 아무것도 가져오지 않습니다. 이전의 earthaccess.open + h5py 경로는 비교를 위해 atl03.extract_legacy로 유지됩니다. scripts/bench_access.py는 접근 방식을 비교합니다. 접근 방식은 스펙(부록 C)을 참조하세요.
장면 지오메트리는 위도를 인식합니다(scene.frame_crs): 극지방 부근에서는 polar-stereographic, 그 외 지역에서는 장면별 azimuthal-equidistant 투영을 사용하므로 장면은 지구 어디에서나 렌더링됩니다.
장면 표면은 지역별로 선택된 실제 DEM이며, 항상 WGS84 타원체 높이(ATL03과 동일한 수직 기준)를 사용합니다. /vsicurl/을 통해 창 단위로 읽고 캐시됩니다: ArcticDEM v4.1(북극, EPSG:3413) 및 REMA v2.0(남극, EPSG:3031) — 둘 다 이미 타원체 기준이고 — 그 외 지역에서는 Copernicus GLO-30이며, EGM2008 정표고 높이는 NGA egm08 지오이드 파고를 더하여 타원체 높이로 변환됩니다(h = H + N). 광자 보간 폴백은 없습니다: 장면은 DEM이 덮는 곳에서만 DEM을 표시합니다. 장면 이미지는 Sentinel-2 cloudless(EOX, CC BY-NC-SA 4.0)이며 표면에 드레이프됩니다. Explore/Lake 지구본 베이스맵은 Natural Earth 50m 육지(퍼블릭 도메인)입니다. 출처 표시가 화면에 나타납니다.
uv run scripts/check_coverage.py --region egig_west_flank # granule counts by month / laser campaign
uv run scripts/ingest.py egig_west_flank # index + byte-range ingest + lake query
uv run scripts/build_index.py --region egig_west_flank # offline index pre-build (amortized off the query path)
uv run scripts/make_scene.py egig_west_flank --glas --coreg # full pipeline for a region
uv run scripts/serve.py # widget server only, for local testing
uv run scripts/bench_access.py # access-method comparison데이터(data/)는 gitignore에 포함됩니다. 삭제하면 다시 가져오기를 강제합니다.
각 GLAS 샷에 대해, 풋프린트 중심의 ICESat-2 표면 높이는 동일 위치 반경 내 신호 광자들의 국지적 트랙 방향(along-track) 선형 피트에서 얻습니다. 디스크 중앙값은 순서 통계량이므로 서브cm 경사 효과를 분해할 수 없지만, 피트는 위치에 따라 연속적이므로 분해할 수 있습니다. 판 운동 변위의 빔 방향 성분만 단일 빔에서 관측할 수 있으며, 쌍별 아티팩트 패널은 프레임 스텝의 mm 수준 수직 성분을 경사 효과와 분리합니다. 모든 답변은 unresolved 목록을 포함하고 "plate motion applied"라고 명시하며, 절대 "the missions agree"라고 하지 않습니다.
Slice 2: add ICESat/GLAS GLAH06 40 Hz shots (2003-2009 campaigns) to an existing scene, in native coordinates (ITRF2008; heights converted TOPEX/Poseidon -> WGS84 ellipsoid). Returns provenance by campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_id | Yes | ||
| time_window | No | ||
| max_granules | 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 adds useful details: coordinate frame (ITRF2008), height conversion (TOPEX/Poseidon to WGS84 ellipsoid), temporal range (2003-2009), and provenance return. However, it does not disclose side effects such as whether the scene is mutated persistently or whether existing shots are replaced.
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 dense, with useful details packed into one sentence. The 'Slice 2:' prefix is slightly cryptic but does not seriously hurt clarity. Every other clause adds meaningful 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?
The tool has no annotations, no output schema, and 0% schema coverage, so the description must provide a complete picture. It gives coordinate and provenance context but leaves parameter meanings and side-effect behavior unexplained, making it incomplete for safe 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 0%, so the description must compensate for the three parameters. It only indirectly hints at scene_id via 'existing scene' and provides no meaning for time_window or max_granules. This is a significant gap for correct invocation.
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 a specific verb ('add') and resource ('ICESat/GLAS GLAH06 40 Hz shots') applied to an existing scene, which is easy to understand. It does not explicitly contrast with sibling tools like show_photons, but the operation and resource are specific enough to avoid confusion.
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 no guidance on when to use this tool versus alternatives such as show_photons or coregister. It says 'Slice 2' but does not explain the workflow context or list any exclusions or preferred alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many ATL03 (ICESat-2) and GLAH06 (ICESat/GLAS) granules touch a region, by month / laser campaign. Give either a region name (see list_regions) or an explicit bbox [W, S, E, N]. No data is fetched.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| region | No | ||
| glas_window | No | ||
| atl03_window | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully states 'No data is fetched', indicating a read-only operation, but it does not explain how 'touch' is determined or what the return format is. This is some transparency, but not comprehensive.
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 two tight sentences: the purpose is front-loaded, followed by input options and a key behavioral note ('No data is fetched'). Every clause earns its place with no repetition or 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 4-parameter tool with no annotations and no output schema, the description is incomplete. It explains region/bbox but omits the window parameters entirely, and gives no hint of return structure or error conditions, making it insufficient for fully 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%, so the description must compensate. It explains region and bbox adequately, including the [W, S, E, N] format, but it does not mention glas_window or atl03_window, leaving half the parameters semantically undocumented.
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 counts ATL03 and GLAH06 granules touching a region, grouped by month/laser campaign. It is specific about the resource and action, but it does not explicitly name or differentiate any sibling tool, so it falls just short of a 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?
The description gives practical input guidance: use either a region name (referencing list_regions) or an explicit bbox [W, S, E, N]. However, it does not state when to prefer this tool over siblings or when not to use it, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slice 3: run the ITRF2014 + epoch co-registration (plate motion, ITRF2014-PMM NOAM) on both missions in a scene, co-locate GLAS shots with ICESat-2 photons, and compute delta-h statistics in native and co-registered coordinates. Live pyproj on first call, cached after. Returns the comparability block. exaggeration <= 0 picks a display exaggeration automatically (~3% of scene span); it is always labelled on screen.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_id | Yes | ||
| common_epoch | No | ||
| exaggeration | No | ||
| colocation_radius_m | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does disclose useful runtime behavior: live pyproj on first call with caching afterward, automatic exaggeration selection when exaggeration <= 0, screen labeling, and the returned comparability block. However, it does not state whether the tool mutates scene state, requires specific data to already be loaded, or has side effects beyond computing/displaying results.
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 dense but front-loaded: the core operation appears first, then runtime behavior, then display behavior. It is three sentences with no filler. The parenthetical technical details add specificity, though they could be trimmed without losing the main message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex four-parameter tool with no annotations and no output schema, the description is incomplete. It does not define the comparability block, explain the role of common_epoch or colocation_radius_m, describe prerequisites, or mention side effects. An agent would need additional inference to call this tool confidently.
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 for the four parameters. It gives some indirect context for scene_id ('in a scene'), common_epoch ('epoch co-registration'), and colocation_radius_m ('co-locate GLAS shots'), and it explicitly explains exaggeration behavior. But it does not explain common_epoch units, how colocation_radius_m is used, or what values are sensible, leaving significant ambiguity.
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 names a specific operation (ITRF2014 + epoch co-registration), the exact resource (both missions in a scene), and the expected output (delta-h statistics and the comparability block). This clearly distinguishes it from siblings like show_photons, add_glas, and ui_coregister. The 'Slice 3' prefix adds pipeline context and does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but gives no explicit guidance about when to use it versus alternatives. It does not mention that ui_coregister is the UI counterpart, when add_glas might be needed first, or any conditions under which coregister is or is not appropriate. 'Slice 3' weakly implies a pipeline order, but that is not enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and log of a background build job (scene or cell load).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of disclosing behavior. 'Status and log' implies a read-only lookup, but the description does not say whether calling it is non-mutating, whether it blocks while the job is pending, or whether it returns partial or final logs.
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 a single sentence with no filler and front-loads the core resource. It loses a point for being slightly underspecified and lacking a verb, but it is appropriately brief.
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 status tool, this is minimally viable: it names the target and the output categories (status and log). However, with no output schema and no annotations, the absence of return format and polling behavior leaves an agent guessing.
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 never mentions job_id. The phrase 'background build job' makes the parameter's role vaguely inferable, but no format, meaning, or usage details are added beyond the bare schema field name.
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 the resource ('background build job') and that the tool returns its status and log. The parenthetical '(scene or cell load)' narrows the scope and helps distinguish it from sibling tools like lake_status, but the description uses a noun phrase rather than an explicit verb such as 'get' or 'read'.
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?
No guidance is provided on when to use this tool versus alternatives like ui_jobs or lake_status. There are no exclusions, prerequisites, or conditions that would help an agent select it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Materialize H3 (res 6) cells into the lake in the background (cell ids as decimal strings); returns a job id.
| Name | Required | Description | Default |
|---|---|---|---|
| cells | Yes | ||
| time_window | No | ||
| max_granules | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It does disclose that execution is backgrounded and that the return value is a job id, which are meaningful traits. However, it does not explain side effects, whether the operation is long-running or cancellable, or how to monitor or retrieve the eventual results.
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 a single, compact sentence that includes the core action, key parameter detail, execution mode, and return value. There is no filler or redundancy; it is appropriately sized and front-loaded.
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 background job tool with no annotations, no output schema, and undocumented parameters, the description is too sparse. It omits context around the time_window and max_granules semantics, does not explain how the job id should be used, and lacks any statement about follow-up via job_status or lake_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only clarifies the main parameter ('cells' as decimal-string H3 ids). It does not explain 'time_window' or 'max_granules', leaving two parameters without meaningful guidance beyond their raw 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 uses a specific verb ('Materialize') and a clear resource ('H3 (res 6) cells into the lake'), and adds useful context about background execution and returning a job id. It is clearly understandable on its own, though it does not explicitly differentiate itself from related siblings like ui_lake_load or lake_status.
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?
No usage guidance is provided: the description does not say when to prefer this tool over siblings such as ui_lake_load, how this relates to ui_lake_evict, or how to follow up using lake_status or job_status. The asynchronous nature is implied by 'in the background' but no explicit conditions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parquet lake summary: cells, files, rows, bytes, storage limit and usage, recent evictions.
| 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 burden, but the word 'summary' communicates a read-only status operation and the metric list, including 'recent evictions', gives useful context about what state is reported. It does not spell out auth or rate-limit details, but those are not obviously needed for a zero-parameter status call.
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 single, front-loaded sentence with a colon-separated list. Every term adds information and there is no filler or repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is largely sufficient: it names all key returned categories and makes invocation unambiguous. It could be more explicit about the exact return structure, but that is a minor gap given the tool's simplicity.
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 has zero parameters and schema description coverage is 100%, so the description has no parameter burden to carry. The baseline for a 0-parameter tool is met; the description's output-oriented detail complements the empty 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 identifies the resource ('Parquet lake') and the nature of the result ('summary'), and lists specific metrics returned: cells, files, rows, bytes, storage limit/usage, and recent evictions. It lacks an explicit verb like 'get' or 'retrieve', and it does not explicitly differentiate itself from sibling ui_lake_summary, so it stops short of a 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?
There is no guidance on when to use this tool versus alternatives such as ui_lake_summary, lake_load_cells, or job_status. No exclusions, preconditions, or selection criteria are provided; the only implied context is the word 'summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Named candidate Greenland demo regions (bbox = west, south, east, north) with validation notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, mention side effects or ordering, or describe any limitations. The tool name implies listing, but the description itself only details the output content.
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?
One compact sentence with no filler words. All the essential information — named regions, Greenland demo scope, bbox order, validation notes — is packed efficiently and front-loaded.
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, no-output-schema listing tool, the description sets expectations adequately: the agent knows it returns named candidate regions with bbox and validation notes. It does not explain the role of the tool relative to the UI siblings, but that gap is modest for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is effectively 100%, so the baseline is 4. The description adds useful context by specifying that the bbox field order is west, south, east, north, even though this describes return data rather than parameters.
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 identifies the resource (regions), scope (Greenland demo), and the data it provides (named candidates with bbox and validation notes). The verb is only in the tool name, not the description, but the resource type clearly distinguishes it from siblings like list_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?
No guidance is given about when to use this tool versus alternatives such as ui_regions or list_scenes. The description is purely declarative and does not mention any prerequisites, exclusions, or routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scenes built so far (newest first) with status ready | loading | error, area, series present, and widget URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does a good job: it discloses newest-first ordering, the possible status values (ready | loading | error), and the included fields. It does not discuss side effects or access requirements, but the list-style name and 'built so far' phrasing strongly imply a read-only status operation.
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 a single compact sentence that front-loads the core purpose and packs ordering, status values, and returned fields into minimal words. Every element 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 zero-parameter listing tool with an output schema present, the description is sufficiently complete. It tells the agent what the list contains, how it is ordered, and what statuses to expect, leaving little ambiguity about how to invoke or interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there is no parameter meaning to explain. The baseline of 4 applies because no semantic gaps exist for an agent to resolve.
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 identifies the tool as a listing operation for scenes, and specifies the meaningful fields returned (status, area, series, widget URL). It does not explicitly distinguish itself from sibling tools, but the phrasing 'Scenes built so far' and the field list are specific enough to communicate what the tool does.
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 implies this tool is used to check which scenes have been built and their current status, but it does not explicitly state when to choose it over siblings like ui_scenes or list_regions. There are no exclusions or alternatives mentioned, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
URL of the unified UI: Explore (imagery map, draw a box or polygon on Sentinel-2 imagery, coverage check, build scenes, open the 3-D viewer) and Lake (H3 grid with per-cell stats, storage limit, background loading, eviction).
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | explore |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates the output is a URL and is therefore non-mutating, but it does not disclose whether the tool opens a browser, returns a string, requires authentication, or what happens with the optional view parameter.
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 one-sentence description is dense but well organized, front-loading the core resource and grouping features under Explore and Lake. Some feature enumeration is arguably extra, but it is useful for disambiguation and not 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 simple zero-required-parameter tool, the description gives a useful overview of the target UI and implies the output is a URL. It is incomplete on the allowed values of the view parameter and does not specify the return format, but the minimal surface area limits the damage.
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's view parameter has 0% description coverage, but the description names two UI areas, Explore and Lake, which are the likely values. It never explicitly maps view='explore' or view='lake' to the parameter, so the agent must infer the mapping.
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 identifies the tool's resource as the unified UI URL and enumerates the two major views, Explore and Lake, which separates it from the sibling ui_* tools that target single pages. However, it uses a noun phrase ('URL of...') rather than an explicit action verb, so the exact tool behavior is slightly implied by the name.
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?
No statement tells an agent when to choose open_ui over sibling tools such as ui_scenes or ui_lake_summary. The term 'unified UI' weakly implies an all-in-one entry point, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slice 1: extract real ICESat-2 ATL03 land-ice signal photons (strong beams, medium+high confidence) over an area and create a 3D scene with an imagery base layer. Area = region name, bbox [W,S,E,N], or polygon [[lon,lat],...]. Uses the H3 chunk index + byte-range reads + Parquet lake: first touch of an area fetches only the chunks it needs, later calls hit the lake. Returns the widget URL to open plus extraction/access provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| region | No | ||
| polygon | No | ||
| question | No | ||
| time_window | No | ||
| max_granules | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden well. It discloses significant behavior: H3 chunk indexing, byte-range reads, Parquet lake caching ('first touch... later calls hit the lake'), and the return of a widget URL plus provenance. It does not address side effects, permissions, or prerequisites, so not a 5.
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 tightly scoped sentences front-load the purpose, then explain area formats, then describe caching and return behavior. No filler or redundancy; the 'Slice 1' prefix is minor and does not hurt clarity.
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?
Covers the core workflow, area selection, data access strategy, and return values, which is strong given no annotations and no output schema. Still incomplete for three parameters and for how this relates to sibling UI tools, keeping it from 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?
With 0% schema description coverage, the description compensates partially by defining region, bbox, and polygon formats. However, question, time_window, and max_granules are left entirely to inference, and their expected formats/behavior are not explained.
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: 'extract real ICESat-2 ATL03 land-ice signal photons' and 'create a 3D scene with an imagery base layer.' Also includes concrete filters (strong beams, medium+high confidence) and area scope, making it clearly distinguishable from generic sibling UI/scene 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?
Provides clear context on when to use it: to extract and visualize ICESat-2 photon data over a region, bbox, or polygon. It does not explicitly name alternatives or state when not to use this tool, so it falls 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| scene_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| polygon | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | ||
| polygon | No | ||
| question | No | ||
| with_glas | No | ||
| with_coreg | No | ||
| max_granules | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| stats | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cells | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| cells | Yes | ||
| max_granules | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| max_bytes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | meta | |
| chunk | No | ||
| stride | No | ||
| scene_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.1.0add_glascheck_coveragecoregisterjob_statuslake_load_cellslake_statuslist_regionslist_scenesopen_uishow_photonsui_benchui_coregisterui_coverageui_extractui_jobui_jobsui_lake_cellsui_lake_evictui_lake_loadui_lake_settingsui_lake_summaryui_regionsui_scene_partui_scenesScored across 24 tools
The substantive tools are distinct, but the large block of ui_* tools have empty descriptions and overlapping names such as ui_job vs ui_jobs, ui_coverage vs check_coverage, and ui_lake_cells vs ui_lake_summary. An agent cannot reliably distinguish UI shortcuts from actual data operations, so several tool boundaries are unclear.
All names use lower_snake_case and are readable, but conventions vary between verb-first names like show_photons and check_coverage, noun-style names like lake_status and job_status, and the large ui_* prefix group. The ui_* group is internally consistent but the overall set lacks a single predictable naming pattern.
With 24 tools, the server sits at the heavy end of the acceptable range. Many ui_* tools are simple navigation shortcuts that could plausibly be consolidated, while the real operational core is closer to 10 tools, making the overall surface feel larger than its actual scope.
The core scientific workflow is covered: coverage checking, scene creation, adding GLAS data, co-registration, scene listing, lake loading, and job status. However, there are notable gaps such as no scene deletion or update, no job listing/cancellation, and no programmatic lake eviction, with the ui_* links only partially compensating for those missing operations.
Look up elevation worldwide, profile route ascent/descent, grid areas, check terrain line of sight.
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
SibFly — satellite-measured ground motion (subsidence / uplift) for any US address.
Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
