Is GribStream Weather MCP server safe?

Findings (1)

• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool gribstream_query_runs: …AUTH REQUIRED / DATA QUERY. Executes an authenticated /api/v2/{dataset}/runs request and returns actual weather/forecast data values across model runs. Use this tool, not the NO AUTH request-building or metadata tools, when the user asks to fetch, retrieve, download, return, or analyze model-run history, forecast aging, changing forecasts, CSV/JSON/NDJSON/Parquet data, plots, or analysis. Defaults to inline CSV for compatibility; use URL delivery for dense grids and large tabular results. Time ranges are half-open: the start is inclusive and the end is exclusive. The start must be earlier than the end; equal bounds select no times. Use timesList for one exact valid time on /timeseries or one exact model run time on /runs. When a live query returns a resource_link, the exact signed HTTPS URL is the result: download it directly once with an available HTTPS or file-download capability, without an API token. This consumes the selected GribStream MCP result; it is not a direct GribStream API call or a connector bypass. Do not look for an MCP resources/read tool, and do not repeat the query merely to obtain the file bytes. If the client reports that network or allowlist policy blocks the returned resource_link, do not retry URL delivery. For CSV, JSON, or NDJSON whose reported size is at most 10000000 bytes, retry the same request at most once with delivery=inline. Parquet cannot use inline delivery. If the artifact is larger, reduce the request using the documented split order before one inline CSV retry. For dense grids or large tabular results, use delivery=url so MCP returns a short-lived signed HTTPS resource link instead of putting the full dataset into tool output. Prefer application/vnd.apache.parquet only when a compatible Parquet reader is already known to be available. If reader availability is unknown, do not spend tool calls probing or installing packages; use text/csv with delivery=url immediately. Use one grid request, process the downloaded file locally, and never print or serialize the full file into chat or tool output. Do not install a dependency or write a Parquet parser solely for one result. When a real API request limit requires splitting, split by time range first, split variables second, and split coordinates/grid/space last; spatial tiling creates the most extra work. Response rows are unsorted; sort by location fields, forecasted_at, and forecasted_time before plotting, building time series, or checking for gaps. The request body must use request.coordinates and request.variables; do not use location, coord, coords, parameters, parameter, or variable as replacement field names.…