Loading ToolBench
MCP server for safe, validated, reproducible access to Copernicus environmental data.
Strong foundation with 24 well-named tools following verb_noun patterns (search_, describe_, submit_, check_, download_, cancel_). All tools have descriptions (avg ~150 chars, within 10-1024 baseline). Input schemas are present and typed for most tools. However, several tools lack complete parameter descriptions, output schemas are not documented in the tool definitions themselves, and error handling guidance is minimal. Tool composition is excellent, clear chains (search → describe → estimate → submit → check → download). Security posture is good (no secrets in params, credentials server-injected). Main gaps: output schema documentation, parameter constraint clarity, and recovery guidance in error scenarios.
Accept a CDS licence (T-CDS-LICENCE-001).
Apply constraints to a CDS request (T-CDS-016).
Cancel a pending or running CDS request.
Check the status of a CDS request. Accepts either a single request_id or a batch of request_ids (T-CDS-OPS-002).
Describe a CDS dataset by its dataset_id. Returns full STAC metadata.
Download the result of a completed CDS request. The backend always returns a descriptor pointing at the canonical cache location (the project conventions invariant 1).
Output schemas not documented in tool definitions. Tools return complex objects (status, request_id, metadata, error details) but LLMs cannot see the response structure. This forces agents to guess field names and risks extraction errors.
cds_apply_constraints and marine_estimate_subset have minimal descriptions (50 chars or less) and incomplete input schemas. cds_apply_constraints description is just 'Apply constraints to a CDS request (T-CDS-016).', no explanation of what constraints, when to call it, or what it returns.
Error handling lacks recovery guidance. Tools return ToolReturnedError with ErrorRecord but descriptions do not explain what to do on failure (retry? ask user? call a different tool?). E.g., 'cost_limit_requires_chunking' is mentioned in cds_submit_request but not documented as a possible error response.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Estimate the cost and size of a CDS data request before submitting.
List available licences for CDS datasets (T-CDS-LICENCE-001).
Search the bundled CDS / ADS / EWDS catalogue snapshot. Use this tool to discover candidate dataset ids before describing or submitting a request. Returns a slim record per dataset; call ``cds_describe_dataset`` for the full STAC metadata.
Search the hierarchical group-search tool for CDS datasets (T-CDS-021 PR-2).
Submit a CDS data request to the queue. CDS is async-by-design: every submit goes through the server queue. The tool returns {status: "queued", request_id, ...} immediately; poll completion via cds_check_request_status and download via cds_download_request_result.
List recent submitted jobs (downloads) recorded in the local state store, so a fresh session can recover work after a restart without already holding a request_id. Each entry carries request_id, backend, dataset, operation, status, and created/updated times (failed jobs also include error_class). Optional filters: status (any of queued/running/successful/failed/cancelled), limit (default 50, capped at 500), created_after (ISO-8601 UTC, strict lower bound).
Return server diagnostics: registered backends, credential sources, cache metrics, persistence path, and config snapshot. No credential values appear in the output.
Cancel a background CMEMS subset request (T-039).
Check the status of a background CMEMS subset request (T-039).
Describe a CMEMS dataset by its dataset_id. Returns full STAC metadata.
Estimate the cost and size of a CMEMS subset request before submitting.
Get available coordinates for a CMEMS dataset (T-022 second half).
Download specific files from a CMEMS dataset (T-CMEMS-GET-006). Extends CmemsGetRequest with the top-level ``confirmed`` flag matching ``MarineSubsetDatasetInput``. Sparse-format datasets (the primary motivation for native-file retrieval) almost never expose a precise dry-run size, so the gate fires by default and callers must opt in via ``confirmed=true`` to download.
List files in a CMEMS dataset with optional filtering by bbox, time, and variables (T-CMEMS-GET-INDEX-004).
Search the CMEMS catalogue by keyword, bbox, or time range. Use this tool to discover dataset ids before describing or subsetting. **Workflow hints based on the returned ``service_types``:** - ``geoseries`` / ``timeseries`` (grid datasets) → use ``marine_subset_dataset`` for spatio-temporal subsets. - ``arco-platform-series`` / ``original-files`` (sparse / in-situ) → use ``marine_list_files`` to filter the dataset's file index by bbox/time/variables, THEN ``marine_get_files(file_list=[...])`` to download only the matching files.
Search the hierarchical group-search tool for CMEMS datasets (T-CMEMS-HIER-005).
Search the hierarchical product-search tool for CMEMS datasets (T-CMEMS-HIER-005).
Subset a CMEMS dataset by spatio-temporal bounds and variables. T-039: ``async_mode=True`` opts the request into background download. The tool then returns ``{status: "running", request_id, ...}`` immediately; poll completion via ``marine_check_status``.
Parameter constraints not fully specified in descriptions. E.g., chunk_by accepts ['year', 'month', 'day'] but description does not state these are the only valid values. limit parameters lack min/max bounds. LLMs may pass invalid values.
Tool composition assumes agent knows workflow order. No tool explicitly states 'call cds_search_datasets first, then cds_describe_dataset, then cds_estimate_request'. Descriptions mention dependencies (e.g., 'call cds_describe_dataset for full STAC metadata') but lack explicit sequencing guidance.