Skip to main content
Glama
xmpuspus

ph-civic-data-mcp

by xmpuspus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Air quality at a Philippine location

get_air_quality
Read-onlyIdempotent

Check real-time air quality for Philippine cities, with pollutant levels (PM2.5, PM10, CO, NO2, SO2, O3) and AQI readings.

Instructions

Real-time air quality for a Philippine city via Open-Meteo (no API key).

Returns PM2.5, PM10, CO, NO2, SO2, and O3, plus European AQI and US AQI with category interpretation. Covers about 80 major PH cities through a local coordinate table. measured_at is always UTC, never Asia/Manila time. Examples:

get_air_quality("Manila") # current readings for Metro Manila get_air_quality("Cebu City") # current readings for Cebu City get_air_quality("Davao") # current readings for Davao City

On failure: a location not in the coordinate table returns data_status "invalid_request", with validation_error true and a caveat naming the location. An Open-Meteo fetch failure returns data_status "unavailable", with upstream_error true and the real error text in caveats. A response with no time, an unparseable time, or no pollutant field returns data_status "indeterminate", with upstream_error true and a caveat naming the problem.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locationYesCity or municipality name, such as "Manila", "Cebu City", or "Davao".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • changedInput schema / properties / location / description
      Previous value: -"City or municipality name (e.g. \"Manila\", \"Cebu City\", \"Davao\")."New value: +"City or municipality name, such as \"Manila\", \"Cebu City\", or \"Davao\"."
  2. Addedv0.4.0
  3. Removedv1.0.3
  4. Addedv1.0.2

TDQS

A4.7/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the readOnly/idempotent annotations: measured_at is always UTC, coverage is limited to ~80 cities via a local coordinate table, and there are three explicit failure modes with distinct data_status values. This gives an agent a precise model of the tool's runtime 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 front-loaded with the core purpose and return payload, followed by concise examples and a clearly organized failure-mode section. The length is justified by the operational details, and every sentence serves a distinct purpose.

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?

For a single-parameter, read-only tool with an output schema, the description is complete: it covers inputs, outputs, timezone behavior, coverage limits, and all documented error states. No critical information needed to invoke the tool correctly is missing.

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?

The schema already describes the location parameter well with examples, and schema coverage is 100%. The description adds meaningful semantics by explaining the city-coverage limitation and the invalid_request behavior when a location is not in the coordinate table, going beyond the schema's basic type and example.

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 states a specific verb and resource: real-time air quality for a Philippine city via Open-Meteo. It enumerates the exact pollutants and AQI types returned, and the Philippine-city scope clearly separates it from sibling weather, earthquake, and health tools.

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

Usage Guidelines4/5

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

The description clearly indicates when to use the tool: when a user needs real-time air quality for a Philippine city. It provides usage examples and a coverage caveat, but it does not explicitly name sibling tools or state when-not-to-use conditions, so it falls just short of full routing guidance.

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

Deploy Server

Other Tools