Ein MCP-Server für Claude Desktop, der echte ICESat-2-ATL03-Photonen und ICESat/GLAS-GLAH06-Schüsse über ein ausgewähltes Gebiet abruft, sie als 3D-Punktwolke (deck.gl) rendert und — per Umschalter — eine Koregistrierung von ITRF2014 + Epoche (Plattenbewegung, ITRF2014-PMM / NOAM) mit pyproj anwendet, wobei die kollokierten Δh-Statistiken aktualisiert werden. Ausgehend von docs/cross-mission-altimetry-mcp-spec.md, das das vollständige Design und die Begründung enthält.
Die Koregistrierung entfernt Plattenbewegung zwischen Epochen. Sie entfernt nicht Eisfluss, GIA, Geoid/Gezeiten, Firnkompaktion oder das vertikale Datum, und das Widget weist bei jeder Antwort darauf hin. GLAS-Höhen werden mithilfe von d_deltaEllip des Produkts vom TOPEX/Poseidon- zum WGS84-Ellipsoid umgerechnet, wobei die Sättigungskorrektur d_satElevCorr angewendet wird; das wird in jedem Vergleichbarkeitsblock festgehalten.
uv sync # Python 3.13
uv run pytest # offline unit testsEarthdata Login: Ein Bearer-Token wird aus ~/.edl/token.prod gelesen (überschreibbar mit AICESAT_EDL_FILE oder durch Setzen von EARTHDATA_TOKEN). Der Server schreibt nie auf stdout (Stdio-MCP-Transport); Logs gehen auf stderr.
Related MCP server: mcp-opentopography
Fügen Sie unter Verwendung des absoluten Pfads zu Ihrem Checkout Folgendes zu ~/Library/Application Support/Claude/claude_desktop_config.json hinzu:
{
"mcpServers": {
"aicesat": {
"command": "/opt/homebrew/bin/uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/aicesat", "run", "aicesat-server"]
}
}
}Starten Sie Claude Desktop neu. Die einheitliche UI wird inline als MCP-App gerendert; der Server stellt sie außerdem unter http://127.0.0.1:8765/ bereit (Port über AICESAT_PORT) für die Nutzung im Browser.
Tools: open_ui, list_regions, list_scenes, check_coverage, show_photons (Region, Bounding-Box oder Polygon), add_glas, coregister, lake_status, lake_load_cells, job_status.
Eine in sich geschlossene Seite (erstellt aus src/aicesat/ui/* + mitgeliefertem deck.gl / h3-js durch scripts/build_ui.py, reines Python; der Server erstellt sie beim Start neu, wenn sich die Quellen ändern), die sowohl inline in Claude Desktop als auch unter / bereitgestellt wird:
Explore — ein 3-D-Globus (Basiskarte Natural Earth, keine flache Projektion). Überall navigieren, einen Kasten oder ein Polygon zeichnen, die Abdeckung prüfen und eine Szene als Hintergrundjob erstellen; Szenen-Footprints und die geladenen H3-Zellen werden auf dem Globus angezeigt.
Lake — der persistente Parquet-See als H3-Gitter: Statistiken pro Zelle beim Überfahren, ein Speicherlimit, das die am längsten nicht verwendeten Zellen automatisch verdrängt, und Hintergrundladen oder -auslagern ausgewählter Zellen.
Scene — der 3-D-Viewer: ICESat-2- und GLAS-Punkte auf ein DEM gelegt, ein Adjustments-Bedienfeld mit Korrekturumschaltern und die kollokierten Δh-Histogramme. Die tatsächliche Plattenbewegungsverschiebung ist im Szenenmaßstab unterpixelig, sodass sich die Punktwolken nicht sichtbar bewegen — der Effekt wird aus dem Δh-Bedienfeld abgelesen, nicht aus einer übertriebenen Visualisierung. Bedienfelder lassen sich einklappen und schließen.
Die UI kommuniziert mit einer transportneutralen API (api.py), die auf zwei Arten bereitgestellt wird: die /api/*-Routen auf localhost für den Browser und MCP-Tools mit visibility:["app"], die der Host für die Inline-App bereitstellt. scripts/e2e_apps.py prüft die MCP-App-Anbindung.
Der ATL03-Pfad öffnet zur Abfragezeit kein HDF5. Pro Granule zeichnet eine Indexerstellung (index.py) den Bytebereich jedes Chunks, die Filter-Pipeline und die H3-Zellen auf, die der Chunk berührt. Abfragen führen eine Bounding-Box bzw. ein Polygon auf Zellen zurück, holen nur die benötigten Chunks per HTTPS-Bereichsanfrage (EDL-Bearer-Token → vorab signierte URL), dekodieren sie ohne HDF5-Bibliothek und materialisieren die Photonen in einen Hive-partitionierten Parquet-See (lake.py) mit Herkunft pro Zeile und koregistrierten Koordinaten. DuckDB beantwortet Abfragen über den See (api.py); eine Abdeckungstabelle zeichnet auf, was materialisiert ist, sodass wiederholte Abfragen nichts abrufen. Der frühere Pfad earthaccess.open + h5py bleibt für Vergleichszwecke als atl03.extract_legacy erhalten. scripts/bench_access.py vergleicht die Zugriffsmethoden; siehe die Spezifikation (Anhang C) für das Vorgehen.
Die Szenengeometrie ist breitengradbewusst (scene.frame_crs): In der Nähe der Pole polarstereografisch, sonst eine szenenspezifische azimutal-äquidistante Projektion, sodass Szenen überall auf der Erde gerendert werden können.
Die Szenenoberfläche ist ein reales, je nach Region gewähltes DEM, immer auf WGS84-Ellipsoidhöhen (dieselbe vertikale Referenz wie ATL03), fensterweise über /vsicurl/ gelesen und zwischengespeichert: ArcticDEM v4.1 (Arktis, EPSG:3413) und REMA v2.0 (Antarktis, EPSG:3031) — beide bereits ellipsoidisch — und andernorts Copernicus GLO-30, dessen EGM2008-orthometrische Höhen durch Addition der NGA-egm08-Geoidundulation in ellipsoidische Höhen umgerechnet werden (h = H + N). Es gibt keinen Rückgriff auf Photoneninterpolation: Eine Szene zeigt ein DEM nur dort, wo ein solches sie abdeckt. Als Szenenbild dient Sentinel-2 cloudless (EOX, CC BY-NC-SA 4.0), das auf die Oberfläche gelegt wird. Die Globus-Basiskarte von Explore/Lake ist Natural Earth 50 m land (Public Domain). Quellenangaben erscheinen auf dem Bildschirm.
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 comparisonDaten (data/) sind gitignored; löschen Sie sie, um einen erneuten Abruf zu erzwingen.
Für jeden GLAS-Schuss stammt die ICESat-2-Oberflächenhöhe im Zentrum des Footprints aus einem lokalen linearen Fit entlang der Bahn über die Signalphotonen innerhalb des Kollokationsradius. Ein photometrischer Fit ist eine Ordnungsstatistik und kann den Subzentimeter-Steigungseffekt nicht auflösen; der Fit ist stetig in der Position, daher kann er es. Nur die entlang des Strahls wirkende Komponente der Plattenbewegungsverschiebung ist bei einem einzelnen Strahl beobachtbar, und das Artefakt-Bedienfeld pro Paar hält den vertikalen Anteil des Rahmensprungs im mm-Bereich getrennt vom Steigungseffekt. Jede Antwort enthält die Liste unresolved und besagt „Plattenbewegung angewendet", niemals „die Missionen stimmen überein".
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)
