Skip to main content
Glama
Sign In

Openaq

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Get Measurements

get_measurements
Read-onlyIdempotent

Get the most recent time series (hourly or daily aggregates) for a single OpenAQ sensor (sensor id from find_stations), newest first. Use for pollutant trends over time at one station/parameter. Returns the sensor's LAST limit readings — note that many OpenAQ sensors are archived and stopped reporting years ago, so "most recent" can legitimately be several years old: always read the returned timestamps rather than assuming the data is current. Use find_stations or get_latest to pick a sensor that is still reporting.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "limit": 20,
      "sensor_id": 2772
    },
    "name": "get_measurements"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many of the most recent data points to return (1-1000, default 24).
periodNoAggregation: "hours" (default) or "days".
_apiKeyNoOpenAQ API key (optional; the gateway supplies one).
sensor_idYesOpenAQ sensor id (a station+parameter pair, from find_stations).

Output Schema

NameRequiredDescriptionDefault
countYesNumber of measurements returned
measurementsYesHistorical air quality measurements

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "limit": 20,
-    "location_id": 2178,
-    "parameter": "pm25"
-  },
-  {
-    "limit": 50,
-    "location_id": 5847
-  }
-]New value: +[
+  {
+    "limit": 20,
+    "sensor_id": 2772
+  },
+  {
+    "limit": 30,
+    "period": "days",
+    "sensor_id": 13866
+  }
+]
    • changedInput schema / properties / limit / description
      Previous value: -"Number of data points (1-1000, default 24)."New value: +"How many of the most recent data points to return (1-1000, default 24)."
  2. Changed7 schema fields changed
    • addedInput schema / properties / _apiKey
      Added value: +{
+  "description": "OpenAQ API key (optional; the gateway supplies one).",
+  "type": "string"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of measurement records to return (default 20, max 100)."New value: +"Number of data points (1-1000, default 24)."
    • removedInput schema / properties / location_id
      Removed value: -{
-  "description": "Numeric location ID from get_locations (e.g. 2178).",
-  "type": "number"
-}
    • removedInput schema / properties / parameter
      Removed value: -{
-  "description": "Pollutant parameter to filter by. One of: pm25, pm10, o3, no2, so2, co.",
-  "enum": [
-    "pm25",
-    "pm10",
-    "o3",
-    "no2",
-    "so2",
-    "co"
-  ],
-  "type": "string"
-}
    • addedInput schema / properties / period
      Added value: +{
+  "description": "Aggregation: \"hours\" (default) or \"days\".",
+  "type": "string"
+}
    • addedInput schema / properties / sensor_id
      Added value: +{
+  "description": "OpenAQ sensor id (a station+parameter pair, from find_stations).",
+  "type": "number"
+}
    • changedInput schema / required
      Previous value: -[
-  "location_id"
-]New value: +[
+  "sensor_id"
+]
  3. Added
  4. Removed
  5. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds critical behavioral context beyond annotations: it warns that many sensors are archived and 'most recent' can be years old, and advises checking timestamps. This complements the readOnlyHint and idempotentHint annotations, enhancing the agent's understanding of tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences plus an important note), front-loads the primary purpose, and uses efficient language. Every sentence adds value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to explain return values. It covers what the tool does, how to use it, key caveats (old data), and prerequisites, making it complete for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing clear descriptions for each parameter. The description adds value by explaining that limit controls the number of most recent readings and that sensor_id comes from find_stations. While not exhaustive, it meaningfully supplements the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the most recent time series (hourly or daily aggregates) for a single OpenAQ sensor, ordered newest first. It specifies the resource (time series), the verb (get), and the scope (single sensor). This distinguishes it from siblings like get_latest and find_stations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states usage for pollutant trends over time at one station/parameter and advises using find_stations or get_latest to select an active sensor. This provides clear context and alternatives, guiding the agent on when and how to apply the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Openaq toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources