Skip to main content
Glama
ContentWriterco

powietrze-mcp

by ContentWriterco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Podłącz w 30 sekund

Adres MCP: https://powietrze.compabase.com/mcp (Streamable HTTP, bez logowania).

  • Claude: Ustawienia → Connectors → Add custom connector → wklej adres.

  • ChatGPT: Settings → Connectors (tryb deweloperski) → dodaj serwer MCP.

  • Claude Code: claude mcp add --transport http powietrze https://powietrze.compabase.com/mcp

  • Lokalnie (stdio): npx -y powietrze-mcp, np. w Claude Desktop:

{ "mcpServers": { "powietrze": { "command": "npx", "args": ["-y", "powietrze-mcp"] } } }

Related MCP server: gios-air-mcp

Co potrafi

Narzędzie

Do czego

air_quality

Dla miejscowości, adresu albo współrzędnych: najbliższe stacje GIOŚ (do 25 km) z indeksem jakości powietrza (bardzo dobry … bardzo zły), ostatnimi pomiarami PM2.5, PM10, NO2, O3, SO2, średnią dobową pyłów i odniesieniem do norm; ostrzeżenia smogowe GIOŚ w województwie; prognoza na 3 dni z modelu Copernicus CAMS – maksymalne PM2.5/PM10, europejski indeks jakości powietrza i pyłki (brzoza, olsza, trawy, bylica, ambrozja).

air_stations

Stacje pomiarowe GIOŚ w mieście, gminie, powiecie albo województwie.

data_sources

Źródła i zastrzeżenia.

Przykładowe pytania: „Czy mogę dziś pobiegać w Krakowie?”, „Jaki jest smog w Zakopanem i czy jutro będzie lepiej?”, „Czy w weekend będzie dużo pyłków brzozy w Warszawie?”, „Jaka jest jakość powietrza przy ul. Marszałkowskiej 1 w Warszawie?”.

Skąd dane

  • Pomiary: Główny Inspektorat Ochrony Środowiska – Państwowy Monitoring Środowiska, API https://api.gios.gov.pl/pjp-api (ok. 290 stacji, wartości godzinowe; dane bieżące są niezweryfikowane). Odpowiedzi trzymamy w pamięci podręcznej (lista stacji 12 h, pomiary i indeks 15 min), żeby nie obciążać GIOŚ.

  • Prognoza i pyłki: Copernicus Atmosphere Monitoring Service (CAMS) przez Open-Meteo (CC BY 4.0) – model w siatce ok. 10 km, nie zastępuje pomiaru. Można wyłączyć: POWIETRZE_FORECAST=0.

  • Adresy: GUGiK (państwowy rejestr adresów).

Własny serwer

npx -y powietrze-mcp --http --port 3000      # MCP: http://localhost:3000/mcp
npx -y powietrze-mcp now "Kraków, Rynek Główny 1"
npx -y powietrze-mcp stations "małopolskie"

Zmienne: POWIETRZE_FORECAST=0, POWIETRZE_RATE_LIMIT, POWIETRZE_STATS=1 (anonimowe liczniki pod /stats), POWIETRZE_CONTACT, POWIETRZE_PUBLIC_URL.

Licencja

Kod: MIT. Dane: GIOŚ (Państwowy Monitoring Środowiska), Copernicus CAMS / Open-Meteo (CC BY 4.0), GUGiK – dane przetworzone. Projekt niezależny, hostowany pro publico bono przez Compabase. Zobacz też rozkład-mcp, ceny-nieruchomosci-mcp i leki-mcp.

English

powietrze-mcp gives AI assistants live air quality in Poland: the nearest official GIOŚ monitoring stations with the Polish air quality index and the latest hourly PM2.5, PM10, NO2, O3 and SO2, smog warnings for the voivodeship, and a 3-day Copernicus CAMS forecast of particulate matter and pollen (birch, alder, grass, mugwort, ragweed). Public endpoint: https://powietrze.compabase.com/mcp (no key), or run locally with npx -y powietrze-mcp.

Available Tools

3 tools
air_qualityAir quality now and forecast (Poland)A
Read-only
Inspect

Current air quality near a place in Poland from the nearest official GIOŚ stations: Polish air quality index, latest hourly PM2.5, PM10, NO2, O3, SO2 (+24 h means for dust), reference limits, active smog warnings for the voivodeship, and a 3-day forecast of PM and pollen (birch, alder, grass, mugwort, ragweed) from Copernicus CAMS. place: town, address or 'lat,lon'.

NameRequiredDescriptionDefault
placeYesTown, address or 'lat,lon' in Poland
forecastNoInclude the CAMS forecast and pollen (default true)
stationsNoHow many nearby stations (default 3, within 25 km)

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint. The description adds meaningful context beyond them: the authoritative provenance (official GIOŚ stations, Copernicus CAMS), the hard geographic restriction to Poland, the voivodeship-level scope of smog warnings, and the 25 km station radius. It does not disclose behavior for places outside Poland or for zero-station cases.

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

Conciseness4/5

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

Front-loaded with the core purpose and the data inventory, which is the most valuable information for selection. The long enumeration of pollutants is dense but each item earns its place; only the trailing restatement of the place parameter duplicates the schema.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so thoroughly by listing the returned measurements, means, limits, warnings, and forecast horizons. Missing only edge-case behavior (place not found, outside Poland) for a read-only open-world tool.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including defaults for forecast and stations. The description's trailing 'place: town, address or lat,lon' simply restates the schema, and it adds no new syntax or constraint detail — baseline 3 applies.

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

Purpose4/5

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

The description names a specific verb and resource (current air quality plus forecast for a place in Poland) and enumerates the exact data returned — index, hourly PM2.5/PM10/NO2/O3/SO2, warnings, 3-day PM and pollen forecast. It is unmistakably distinct from air_stations and data_sources in substance, though it never names those siblings explicitly to route the agent.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the geographic scoping ('in Poland') and the forecast toggle convey when the tool fits, but there is no explicit when-to-use/when-not guidance and no mention of air_stations or data_sources as alternatives for station listings or provenance.

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

air_stationsGIOŚ monitoring stationsA
Read-only
Inspect

List official air monitoring stations (GIOŚ) in a town, commune, county or voivodeship, with coordinates.

NameRequiredDescriptionDefault
queryYesTown, commune, county or voivodeship name

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds that results are official GIOŚ stations returned with coordinates, but says nothing about result count, pagination, or behavior for unknown locations.

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?

A single front-loaded sentence with zero waste; the resource and scope are stated immediately and nothing needs trimming.

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

Completeness4/5

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

For a one-parameter read-only lookup with annotations covering safety and no output schema, the description states the source, the query scope, and the returned payload (coordinates). Only minor behavioral details are absent, which is acceptable at this complexity.

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

Parameters3/5

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

Schema description coverage is 100% with a single documented parameter, so the schema already explains that 'query' accepts a town, commune, county or voivodeship. The description merely restates the same list, adding no format or matching semantics beyond the schema.

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

Purpose4/5

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

States a specific verb ('List') and resource ('official air monitoring stations (GIOŚ)') plus the geographic scope, so the agent knows exactly what is returned. It does not explicitly distinguish itself from the siblings air_quality or data_sources, which is the only gap.

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

Usage Guidelines3/5

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

Usage is implied by the geographic query framing — an agent would infer this is for locating stations by place — but there is no explicit when-to-use, when-not-to-use, or reference to the sibling tools (e.g., air_quality for readings at those stations).

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

data_sourcesData sourcesC
Read-only
Inspect

Where the data comes from and caveats.

NameRequiredDescriptionDefault

No parameters

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds essentially no behavioral context beyond that — it doesn't say whether this returns provenance metadata, a list, external references, or how large/stable the result is.

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

Conciseness3/5

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

It is short with no wasted words, but it is a sentence fragment that is not front-loaded with a verb and reads as a caption rather than a definition. Brevity here reflects under-specification more than discipline.

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

Completeness2/5

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

With no output schema and no parameters, the description is the only source of information about what this tool yields, and it does not explain the return content, structure, or the nature of the 'caveats'. For a metadata/provenance tool it leaves the agent guessing.

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 tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description to clarify.

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

Purpose2/5

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

The description is a noun-phrase fragment ('Where the data comes from and caveats') that essentially restates the name and title. There is no verb and no statement of what the tool actually returns or does, so an agent cannot confidently distinguish it from siblings like air_quality or air_stations.

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

Usage Guidelines2/5

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

Nothing indicates when to call this rather than air_quality or air_stations, nor any prerequisite or exclusion. Usage is at best implied by the word 'caveats', which is too weak to count as guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedair_quality
    • First observedair_stations
    • First observeddata_sources
Deploy Server
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

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: station discovery, data provenance/context, and air quality retrieval for a place. An agent can easily choose between listing stations, reading source caveats, and fetching current/forecast air quality.

Naming Consistency5/5

All tool names use consistent snake_case noun phrases: air_stations, data_sources, air_quality. There is no mixing of casing or verb styles, and each name directly reflects its tool's scope.

Tool Count5/5

Three tools is well-scoped for a focused air quality server: one for station lookup, one for data provenance, and one for the main air quality query. Each tool earns its place without redundant surface area.

Completeness4/5

The surface covers the core workflow: find stations, understand data caveats, and retrieve current plus forecast air quality including pollutants and pollen. Minor gaps exist around station-specific detailed measurements or historical queries, but typical agent needs are covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers