This server is an MCP-powered cross-mission altimetry toolkit for exploring, extracting, viewing, and co-registering ICESat-2 ATL03 and GLAS GLAH06 data as 3D scenes.
Explore and visualize data: open an interactive 3D globe/map UI, draw boxes or polygons, check coverage, and build scenes with ICESat-2 photon clouds and optional GLAS shots draped on DEM/imagery.
Extract real satellite altimetry: fetch ATL03 land-ice signal photons and GLAH06 shots by region, bbox, polygon, or time window, using efficient H3-indexed chunk access and a persistent Parquet lake.
Co-register missions: apply ITRF2014 + epoch plate-motion correction, co-locate GLAS shots with ICESat-2 photons, and compute Δh statistics with configurable common epoch, colocation radius, and display exaggeration.
Manage the Parquet lake: inspect lake status, load or evict H3 cells in the background, adjust storage limits, and see per-cell statistics.
Monitor background jobs: check job status and logs for scene builds and cell loads.
List regions and scenes: discover named demo regions and previously built scenes with status and widget URLs.
Use from Claude Desktop or browser: the unified UI is served inline as an MCP app and over localhost HTTP/API routes.
Provides access to NASA Earthdata altimetry: fetches ICESat-2 ATL03 photons and ICESat/GLAS GLAH06 shots, checks coverage, builds 3D scenes, and computes co-registered Δh statistics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aicesat Show ICESat-2 photons over the Juneau Icefield and add GLAS shots"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Claude Desktop that pulls real ICESat-2 ATL03 photons and ICESat/GLAS GLAH06 shots over a
chosen area, renders them as a 3D point cloud (deck.gl), and — on a toggle — applies an ITRF2014 + epoch
co-registration (plate motion, ITRF2014-PMM / NOAM) with pyproj, updating the co-located Δh statistics. Started from
docs/cross-mission-altimetry-mcp-spec.md, which carries the full design and rationale.
The co-registration removes plate motion between epochs. It does not remove ice flow, GIA, geoid/tide, firn
compaction, or the vertical datum, and the widget says so on every answer. GLAS heights are converted
TOPEX/Poseidon → WGS84 ellipsoid using the product's d_deltaEllip, with the saturation correction d_satElevCorr
applied; that is recorded in every comparability block.
uv sync # Python 3.13
uv run pytest # offline unit testsEarthdata Login: fetching NASA data needs a token; browsing the existing lake does not. The server resolves a
token in this order: EARTHDATA_TOKEN (env) → a token file at ~/.edl/token.prod (override the path with
AICESAT_EDL_FILE) → ~/.netrc. Generate a token at https://urs.earthdata.nasa.gov (User Profile → Generate
Token). The server never writes to stdout (stdio MCP transport); logs go to stderr.
Related MCP server: pointcloud-mcp
Add to ~/Library/Application Support/Claude/claude_desktop_config.json, using the absolute path to your checkout.
Put your Earthdata token in the env block — this is machine-independent (no token file needed) and the
recommended way for a new user to configure the server:
{
"mcpServers": {
"aicesat": {
"command": "/opt/homebrew/bin/uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/aicesat", "run", "aicesat-server"],
"env": { "EARTHDATA_TOKEN": "<your Earthdata Login token>" }
}
}
}If you keep your token in a file instead, drop the EARTHDATA_TOKEN line and either place it at ~/.edl/token.prod
or add "AICESAT_EDL_FILE": "/path/to/your/token" to env. Restart Claude Desktop. The unified UI renders inline as an MCP App; the server also serves it at
http://127.0.0.1:8765/ (port via AICESAT_PORT) for use in a browser.
Create a free Earthdata Login account if you don't have one: https://urs.earthdata.nasa.gov → Register.
Sign in, then open your profile (top-right) → the Generate Token tab → Generate Token. Copy the long
token string (a JWT that starts with eyJ…). Tokens last ~60 days — regenerate when one stops working.
Paste it into the Claude Desktop config shown above, as the value of EARTHDATA_TOKEN in the server's env
block. The config file is at ~/Library/Application Support/Claude/claude_desktop_config.json (in Claude Desktop:
Settings → Developer → Edit Config).
Restart Claude Desktop. The Lake view works without a token; building a scene / checking coverage will now authenticate. If it can't, the UI shows an error banner naming what to fix.
A ~/.netrc with your Earthdata username/password also works, but a token in env is the most reliable and is what
we recommend for sharing the server with a colleague.
Tools: open_ui, list_regions, list_scenes, check_coverage, show_photons (region, bbox, or polygon),
add_glas, coregister, find_timeseries_candidates, show_timeseries, lake_status, lake_load_cells,
job_status.
find_timeseries_candidates ranks the places in an already-built scene where an elevation time series can actually
be measured, and show_timeseries shows one of them. Both open the Time series view inline.
The search bins every mission's points into H3 cells and fixed time windows, keeps cells seen in three or more
windows, and fits one local reference plane per cell so surface slope is removed rather than mistaken for change.
Each cell gets a deterministic 0–1 confidence dominated by within-cell roughness — the real failure mode, where two
missions sample different sub-cell relief and fake a trend. why names the top two limiters in plain language.
The candidate list is summarised for the caller (no per-cell series, no geometry) and reports n_candidates_total
alongside what it returned, so a truncated answer still says how much it left behind; the view shows every cell.
trend_cm_yr is the least-squares rate through the window medians and is uncorrected for inter-campaign /
inter-sensor bias and for GIA — quote it with that caveat, as params.notes states on every answer.
One self-contained page (built from src/aicesat/ui/* + vendored deck.gl / h3-js by scripts/build_ui.py, pure
Python; the server rebuilds it on start when sources change), served both inline in Claude Desktop and at /:
Explore — a 3-D globe (Natural Earth basemap, no flat projection). Navigate anywhere, draw a box or polygon, check coverage, and build a scene as a background job; scene footprints and the loaded H3 cells are shown on the globe.
Lake — the persistent Parquet lake as an H3 grid: per-cell stats on hover, a storage limit that auto-evicts the least-recently-used cells, and background loading or eviction of selected cells.
Scene — the 3-D viewer: ICESat-2 and GLAS points draped on a DEM, an Adjustments panel of correction toggles, and the co-located Δh histograms. The true plate-motion shift is sub-pixel at scene scale, so the clouds do not visibly move — the effect is read from the Δh panel, not an exaggerated visual. Panels collapse and close.
Time series (#ts/<scene_id>) — the same candidate list and chart the Scene panel carries, given the whole
page and no 3-D. It needs only the scene metadata and one search call, so unlike the Scene view it renders
completely inside Claude Desktop, where the point cloud's push stream cannot follow (tools/call is
request/response). Selecting a different cell is a local redraw: the view already holds every candidate's series.
The UI talks to a transport-neutral API (api.py) exposed two ways: the localhost /api/* routes for the browser,
and visibility:["app"] MCP tools the host proxies for the inline app. scripts/e2e_apps.py checks the MCP-App wiring.
The ATL03 path does not open HDF5 at query time. Per granule, an index build (index.py) records each chunk's byte
range, filter pipeline, and the H3 cells it touches. Queries resolve a bbox/polygon to cells, fetch only the needed
chunks by HTTPS range request (EDL bearer token → presigned URL), decode them without an HDF5 library, and materialize
photons into a hive-partitioned Parquet lake (lake.py) with per-row provenance and co-registered coordinates. DuckDB
answers over the lake (api.py); a coverage table records what is materialized so repeat queries fetch nothing. The
earlier earthaccess.open + h5py path is kept as atl03.extract_legacy for comparison. scripts/bench_access.py
compares the access methods; see the spec (Appendix C) for the approach.
Scene geometry is latitude-aware (scene.frame_crs): polar-stereographic near the poles, a per-scene
azimuthal-equidistant projection elsewhere, so scenes render anywhere on Earth.
The scene surface is a real DEM chosen by region, always on WGS84-ellipsoid heights (the same vertical reference as
ATL03), read by window over /vsicurl/ and cached: ArcticDEM v4.1 (Arctic, EPSG:3413) and REMA v2.0 (Antarctic,
EPSG:3031) — both already ellipsoidal — and Copernicus GLO-30 elsewhere, whose EGM2008 orthometric heights are
converted to ellipsoidal by adding the NGA egm08 geoid undulation (h = H + N). There is no photon-interpolated
fallback: a scene shows a DEM only where one covers it. Scene imagery is Sentinel-2 cloudless (EOX, CC BY-NC-SA 4.0),
draped on the surface. The Explore/Lake globe basemap is Natural Earth 50 m land (public domain). Attributions appear
on screen.
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 comparisonData (data/) is gitignored; delete it to force a re-fetch.
For each GLAS shot, the ICESat-2 surface height at the footprint centre comes from a local along-track linear fit of
the signal photons within the co-location radius. A disc median is an order statistic and cannot resolve the sub-cm
slope effect; the fit is continuous in position, so it can. Only the along-beam component of the plate-motion shift is
observable on a single beam, and the per-pair artifact panel keeps the mm-level vertical part of the frame step
separate from the slope effect. Every answer carries the unresolved list and states "plate motion applied", never
"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.
OpenTopography global DEM rasters + point queries (free key)
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)