Un servidor MCP para Claude Desktop que obtiene fotones reales de ICESat-2 ATL03 y disparos de ICESat/GLAS GLAH06 sobre un área elegida, los representa como una nube de puntos 3D (deck.gl) y, mediante un conmutador, aplica un corregistro ITRF2014 + época (movimiento de placas, ITRF2014-PMM / NOAM) con pyproj, actualizando las estadísticas de Δh colocalizadas. Surgió a partir de docs/cross-mission-altimetry-mcp-spec.md, que contiene el diseño completo y la justificación.
El corregistro elimina el movimiento de placas entre épocas. No elimina el flujo de hielo, el GIA, el geoide/marea, la compactación del firn ni el datum vertical, y el widget lo indica en cada respuesta. Las alturas de GLAS se convierten de TOPEX/Poseidon → elipsoide WGS84 mediante d_deltaEllip del producto, con la corrección de saturación d_satElevCorr aplicada; eso queda registrado en cada bloque de comparabilidad.
uv sync # Python 3.13
uv run pytest # offline unit testsInicio de sesión de Earthdata: se lee un token de portador de ~/.edl/token.prod (se puede sustituir con AICESAT_EDL_FILE o definir EARTHDATA_TOKEN). El servidor nunca escribe en stdout (transporte MCP stdio); los registros van a stderr.
Related MCP server: mcp-opentopography
Añade a ~/Library/Application Support/Claude/claude_desktop_config.json, usando la ruta absoluta a tu clon del repositorio:
{
"mcpServers": {
"aicesat": {
"command": "/opt/homebrew/bin/uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/aicesat", "run", "aicesat-server"]
}
}
}Reinicia Claude Desktop. La interfaz unificada se muestra en línea como una aplicación MCP; el servidor también la sirve en http://127.0.0.1:8765/ (puerto mediante AICESAT_PORT) para usarla en un navegador.
Herramientas: open_ui, list_regions, list_scenes, check_coverage, show_photons (región, bbox o polígono), add_glas, coregister, lake_status, lake_load_cells, job_status.
Una página autocontenida (construida a partir de src/aicesat/ui/* + deck.gl / h3-js incluidos por scripts/build_ui.py, Python puro; el servidor la reconstruye al iniciarse cuando cambian las fuentes), servida tanto en línea en Claude Desktop como en /:
Explore — un globo terráqueo 3D (mapa base Natural Earth, sin proyección plana). Navega a cualquier lugar, dibuja un cuadro o polígono, comprueba la cobertura y crea una escena como trabajo en segundo plano; las huellas de las escenas y las celdas H3 cargadas se muestran en el globo.
Lake — el almacén Parquet persistente como cuadrícula H3: estadísticas por celda al pasar el cursor, un límite de almacenamiento que expulsa automáticamente las celdas usadas menos recientemente y la carga o expulsión en segundo plano de celdas seleccionadas.
Scene — el visor 3D: puntos de ICESat-2 y GLAS superpuestos sobre un DEM, un panel Adjustments de conmutadores de corrección y los histogramas de Δh colocalizados. El desplazamiento real del movimiento de placas es subpíxel a la escala de la escena, por lo que las nubes no se mueven visiblemente: el efecto se lee en el panel de Δh, no en un visual exagerado. Los paneles se contraen y se cierran.
La interfaz se comunica con una API independiente del transporte (api.py) expuesta de dos maneras: las rutas /api/* de localhost para el navegador y las herramientas MCP visibility:["app"] que el host utiliza como proxy para la aplicación integrada. scripts/e2e_apps.py comprueba el cableado MCP-App.
La ruta ATL03 no abre HDF5 en el momento de la consulta. Por cada gránulo, una construcción de índice (index.py) registra el rango de bytes de cada fragmento, la canalización de filtros y las celdas H3 que toca. Las consultas resuelven un bbox/polígono a celdas, obtienen solo los fragmentos necesarios mediante solicitudes de rango por HTTPS (token de portador EDL → URL prefirmada), los decodifican sin una biblioteca HDF5 y materializan los fotones en un almacén Parquet particionado por Hive (lake.py) con procedencia por fila y coordenadas corregistradas. DuckDB responde sobre el almacén (api.py); una tabla de cobertura registra lo materializado para que las consultas repetidas no obtengan nada. La ruta anterior earthaccess.open + h5py se conserva como atl03.extract_legacy para comparación. scripts/bench_access.py compara los métodos de acceso; véase la especificación (Apéndice C) para el enfoque.
La geometría de la escena tiene en cuenta la latitud (scene.frame_crs): proyección estereográfica polar cerca de los polos y una proyección acimutal equidistante por escena en el resto, de modo que las escenas se renderizan en cualquier lugar de la Tierra.
La superficie de la escena es un DEM real elegido por región, siempre en alturas del elipsoide WGS84 (la misma referencia vertical que ATL03), leído por ventanas mediante /vsicurl/ y almacenado en caché: ArcticDEM v4.1 (Ártico, EPSG:3413) y REMA v2.0 (Antártico, EPSG:3031) — ambos ya elipsoidales — y Copernicus GLO-30 en el resto, cuyas alturas ortométricas EGM2008 se convierten a elipsoidales añadiendo la ondulación del geoide NGA egm08 (h = H + N). No hay respaldo por interpolación de fotones: una escena muestra un DEM únicamente donde hay un DEM que la cubre. Las imágenes de la escena son Sentinel-2 cloudless (EOX, CC BY-NC-SA 4.0), superpuestas sobre la superficie. El mapa base del globo de Explore/Lake es la capa de tierra de Natural Earth 50 m (dominio público). Los créditos aparecen en pantalla.
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 comparisonLos datos (data/) están ignorados por git; elimínalos para forzar una nueva descarga.
Para cada disparo de GLAS, la altura de la superficie de ICESat-2 en el centro de la huella proviene de un ajuste lineal local a lo largo de la traza de los fotones de señal dentro del radio de colocalización. Una mediana de disco es un estadístico de orden y no puede resolver el efecto de pendiente subcentimétrico; el ajuste es continuo en la posición, por lo que sí puede. Solo la componente a lo largo del haz del desplazamiento por movimiento de placas es observable en un único haz, y el panel de artefactos por par mantiene separada la parte vertical milimétrica del salto de marco del efecto de pendiente. Cada respuesta lleva la lista unresolved y afirma "movimiento de placas aplicado", nunca "las misiones coinciden".
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)
