Provides geocoding (address to coordinates) and reverse geocoding (coordinates to nearest address) using OpenStreetMap data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jiskta-mcp What was the average NO2 level in Brussels in 2023?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Jiskta Climate & Environmental Data API. Gives AI assistants direct access to historical air quality, ERA5 meteorology, water risk, geocoding, and industrial facility data — without writing any code.
Model Context Protocol is an open standard that lets AI tools (Claude Desktop, Cursor, Cline, Copilot Workspace) call external APIs in conversation. This package runs on your machine, not on any server — it just proxies calls to the Jiskta API using your API key.
Related MCP server: climate-risk-mcp-server
Get an API key: jiskta.com/dashboard — free credits included on signup.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"jiskta": {
"command": "uvx",
"args": ["jiskta-mcp"],
"env": {
"JISKTA_API_KEY": "sk_live_your_key_here"
}
}
}
}No Python installation needed — uvx downloads and runs the package automatically.
Use the same config format your tool supports. The command is always uvx jiskta-mcp with JISKTA_API_KEY set.
pip install jiskta-mcp
export JISKTA_API_KEY=sk_live_...
jiskta-mcpTool | Description |
| Historical air quality + ERA5 met data for a bounding box |
| Same, for a single lat/lon point |
| Dry-run — check credit cost before querying |
| Address → coordinates (113M housenumbers, global) |
| Coordinates → nearest address |
| Coordinate → NUTS3 region + WRI water risk + nearest facility |
| WRI Aqueduct 4.0 water risk for a bounding box |
| Nearest E-PRTR industrial facilities within a radius |
| Check available data months before querying |
| Aggregate raster data to NUTS3 regions or countries |
Once connected, you can ask things like:
"What was the average NO₂ level in Brussels in 2023?"
"Is there any industrial pollution risk near Industrieweg 1, Antwerp?"
"Compare PM2.5 trends across NUTS3 regions in the Ruhr area from 2018 to 2023."
"What's the water stress level for our distribution centre at 51.5°N, 4.3°E?"
"How many days did PM10 exceed the EU limit in Paris last year?"
Air quality: Copernicus CAMS EU reanalysis (0.1°, 2013–present) and CAMS Global (0.75°, 2020–present)
Meteorology: ECMWF ERA5 reanalysis (0.25°, 2013–present)
Water risk: WRI Aqueduct 4.0 (2023), global
Industrial facilities: EEA E-PRTR, ~97,000 EU facilities (CC BY 4.0)
Geocoding: OpenStreetMap (CC BY-SA)
Credits are consumed per tile scanned (geographic area × time period × variable). Use estimate_query_cost before large queries. Top up at jiskta.com/dashboard.
API documentation: jiskta.com/docs
Python SDK: github.com/jiskta/jiskta-python
Examples: github.com/jiskta/jiskta-examples
Get administrative region and water risk context for a coordinate.
Returns the NUTS3 administrative region (for EU locations), WRI Aqueduct 4.0 water risk scores, and the nearest E-PRTR industrial facility within 5 km (if any). Useful for site screening and CSRD/ESRS preliminary assessment.
Args: lat: Latitude in decimal degrees lon: Longitude in decimal degrees
Returns: JSON with: - nuts3_id, nuts3_name, country (EU only) - water_stress: bws (baseline water stress), bwd (water depletion), rfr (riverine flood risk), drr (drought risk) — scored 1–5 where 1=Low, 5=Extremely High - nearest_facility: closest industrial facility within 5 km (if any)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals that NUTS3 applies only to EU locations and details return fields, but does not mention mutation safety, rate limits, error handling, or coordinate validity. A read-only implication is present but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with a one-line summary, args section, and bullet-pointed returns. It is fairly concise, though the returns list is detailed. Front-loads the purpose well. Could be slightly more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 simple parameters and an output schema, the description covers all return fields (nuts3_id, nuts3_name, country, water stress scores with scoring scale, nearest facility). It addresses geographic limitation (EU only) and proximity threshold (5 km). No gaps for intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains both parameters ('latitude in decimal degrees', 'longitude in decimal degrees'), adding units and context beyond the schema's bare type definitions. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get administrative region and water risk context for a coordinate.' It specifies exact outputs (NUTS3, WRI scores, proximity facility) and distinguishes from siblings like geocode and water_risk by combining these into a single enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions 'useful for site screening and CSRD/ESRS preliminary assessment' but does not explicitly state when not to use this tool or provide alternatives. Among sibling tools like geocode or find_facilities, there is no guidance on choosing enrich_location over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the credit cost of a climate query before running it.
Use this before large queries (multi-year, large bounding box) to check the cost. Returns the number of credits that would be consumed and an estimated row count, without actually running the query.
Args: lat_min: Southern boundary latitude lat_max: Northern boundary latitude lon_min: Western boundary longitude lon_max: Eastern boundary longitude time_start: Start date, e.g. "2020-01" time_end: End date, e.g. "2024-12" variables: Comma-separated variable names
Returns: Estimated credit cost and row count.
| Name | Required | Description | Default |
|---|---|---|---|
| lat_min | Yes | ||
| lat_max | Yes | ||
| lon_min | Yes | ||
| lon_max | Yes | ||
| time_start | Yes | ||
| time_end | Yes | ||
| variables | No | no2 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states it 'returns the number of credits...without actually running the query,' indicating a read-only, safe operation. It lacks explicit mention of no side effects but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs, front-loading the main purpose. The parameter list is structured and readable, with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and an output schema, the description covers essential behavior (cost estimate, no query execution). It could mention that it's safe to call multiple times, but overall it's sufficiently complete for its simple purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds value by listing each parameter with a brief explanation (e.g., 'lat_min: Southern boundary latitude'). This clarifies meaning beyond the schema's titles, though it could provide more detail like example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Estimate the credit cost of a climate query before running it,' providing a specific verb (estimate) and resource (credit cost). It distinguishes itself from siblings like 'query_climate' and 'query_climate_point' by positioning itself as a pre-check tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this before large queries (multi-year, large bounding box) to check the cost,' giving clear guidance on when to use. It does not directly mention when not to use or alternatives, but the context implies it for cost estimation only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find E-PRTR industrial facilities near a location.
Searches the European Pollutant Release and Transfer Register (E-PRTR) database of ~97,000 verified industrial facilities in the EU. Returns facilities sorted by distance with their sector, annual NOₓ, PM10, PM2.5, and CO₂ emissions.
Useful for CSRD ESRS E2-9 §55 industrial proximity assessment.
Args: lat: Latitude of the site location lon: Longitude of the site location radius_km: Search radius in kilometres (default 10, max 500) max_results: Maximum number of facilities to return (default 20)
Returns: JSON array of facilities with name, sector, distance, and available emission data.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_km | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the action as 'searches' (implying read-only) and specifies the return format, which suggests no destructive side effects. However, it does not explicitly state that the tool is safe or non-destructive, nor does it mention any authentication, rate limits, or potential errors. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose, a brief paragraph on the database and return data, a clear usage note, a structured Args list, and a Returns line. Every sentence adds value, and the structure is well-organized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 parameters, 2 required, no enums) and the presence of an output schema (though not shown), the description covers the purpose, parameters, return format, and a specific use case. It does not mention any limitations, errors, or authentication requirements, but for a query tool this is generally sufficient. It is complete enough for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON input schema has only titles and types (0% description coverage), but the tool description compensates thoroughly by listing each parameter (lat, lon, radius_km, max_results) with plain-language explanations, defaults, and constraints (e.g., max 500 for radius_km). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds E-PRTR industrial facilities near a location, specifies the database (E-PRTR with ~97,000 facilities), and lists the returned data (sorted by distance, sector, emissions). It distinguishes itself from sibling tools (e.g., geocode, reverse_geocode, query_climate) by focusing on facility proximity assessment, and even mentions a specific regulatory context (CSRD ESRS E2-9 §55).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is useful for CSRD ESRS E2-9 §55 industrial proximity assessment, providing clear context for when to use it. However, it does not explicitly state when not to use it or compare against sibling tools, though the sibling list suggests different purposes (e.g., water_risk, query_climate). The guidance is clear but lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a street address to coordinates (forward geocoding).
Resolves any address worldwide to a latitude/longitude pair using the Jiskta geocoding index (113M housenumbers, global coverage).
Args: address: Free-form address string, e.g. "10 Downing Street, London" or "Eiffel Tower, Paris" or "Potsdamer Platz 1, Berlin, 10785, DE"
Returns: JSON with lat, lon, confidence score (0–1), and matched address components (street, city, postcode, country). confidence=1.0 means exact housenumber match; confidence=0.7 means street centroid; confidence=0.5 means postcode centroid.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: global coverage via Jiskta index, confidence score meanings (1.0 exact, 0.7 street, 0.5 postcode), and return fields (lat, lon, confidence, matched components). This exceeds expectations for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and examples, though some redundancy (e.g., 'worldwide' and 'global coverage' is repeated). Could be slightly tighter without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given the tool's simplicity: one parameter, no annotations, and the description covers input examples, output format, and confidence interpretation. The output schema existence is noted but not needed due to rich description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (address param undefined in schema), but the description compensates with examples and explanation of free-form address strings, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Convert a street address to coordinates (forward geocoding)', which is a clear verb+resource pair. It distinguishes from the sibling 'reverse_geocode' by specifying 'forward geocoding'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'reverse_geocode'. While the sibling list includes reverse_geocode, the description does not direct the agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check which months of climate data are available.
Returns the full data availability index — which months have been downloaded and what quality tier they are (validated reanalysis, interim reanalysis, or NRT). Use this to understand what date ranges are available before running a query.
No API key required, no credits consumed.
Returns: JSON with coverage by pollutant and month, including data type and download timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully takes on transparency. It states no API key required and no credits consumed, and describes the return format (JSON with coverage by pollutant and month, data type, timestamp).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences plus a returns section. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers purpose, usage timing, authentication, cost, and return format. It fully compensates for the lack of annotations and output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4 as per rules. The description correctly indicates no parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks which months of climate data are available, using a specific verb (check) and resource (months of climate data). It distinguishes from sibling tools like query_climate that retrieve actual data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'before running a query,' which gives clear context. It doesn't list alternatives but the sibling tools for actual queries imply when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query historical climate and air quality data for a geographic region.
Returns Copernicus CAMS reanalysis (NO₂, PM2.5, PM10, O₃) and/or ECMWF ERA5 meteorological data (temperature, precipitation, wind, boundary layer height) for any location on Earth.
Args: lat_min: Southern boundary latitude (decimal degrees, e.g. 48.8) lat_max: Northern boundary latitude (decimal degrees, e.g. 49.0) lon_min: Western boundary longitude (decimal degrees, e.g. 2.2) lon_max: Eastern boundary longitude (decimal degrees, e.g. 2.5) time_start: Start of the period, e.g. "2022-01-01" or "2022-01" time_end: End of the period, e.g. "2023-12-31" or "2023-12" variables: Comma-separated list of variables to query. Air quality: no2, pm2p5, pm10, o3. Meteorology: era5_t2m (2m temperature), era5_tp (precipitation), era5_blh (boundary layer height), era5_u10, era5_v10 (wind). Default: "no2" aggregate: Time aggregation — "hourly", "daily", "monthly", "seasonal", or "trend" (OLS slope per year). Default: "monthly" format: Output format — "csv" (rows of data) or "stats" (summary: min/max/mean). Default: "csv"
Returns: CSV data or stats summary depending on the format argument. Credits used are shown in the response metadata.
Examples: - Air quality in Paris 2022: lat_min=48.8, lat_max=49.0, lon_min=2.2, lon_max=2.5, time_start="2022-01", time_end="2022-12", variables="no2,pm2p5" - 5-year NO₂ trend for London: aggregate="trend", time_start="2020-01", time_end="2024-12"
| Name | Required | Description | Default |
|---|---|---|---|
| lat_min | Yes | ||
| lat_max | Yes | ||
| lon_min | Yes | ||
| lon_max | Yes | ||
| time_start | Yes | ||
| time_end | Yes | ||
| variables | No | no2 | |
| aggregate | No | monthly | |
| format | No | csv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions credits usage in response metadata but does not explicitly state the tool is read-only or describe potential side effects, limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for overview, arguments, returns, and examples. It is slightly lengthy but every sentence adds value, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, 6 required, and an output schema, the description covers all inputs, provides examples, and notes credits. It lacks details on error handling and data availability, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates thoroughly by explaining each parameter with examples, value ranges, and default values. It clarifies the meaning of variables, aggregation options, and output formats far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries historical climate and air quality data for a geographic region, specifying data sources (Copernicus CAMS, ERA5) and variables. It uses bounding box coordinates, distinguishing it from the sibling tool `query_climate_point` which likely queries a single point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and detailed parameter explanations but does not explicitly mention when to use this tool over `query_climate_point` or other alternatives. However, the context and examples imply usage for regional queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query climate data for a single point location (snaps to nearest grid cell).
Convenience wrapper around query_climate for point queries. Use this when you have a specific address or coordinate rather than a bounding box region. The coordinate is snapped to the nearest CAMS 0.1° grid cell centre.
Args: lat: Latitude in decimal degrees (e.g. 48.8566 for Paris) lon: Longitude in decimal degrees (e.g. 2.3522 for Paris) time_start: Start date, e.g. "2022-01" or "2022-01-01" time_end: End date, e.g. "2024-12" or "2024-12-31" variables: Comma-separated variable names. Default: "no2,pm2p5,pm10" aggregate: "hourly", "daily", "monthly", "seasonal", or "trend"
Returns: CSV with time series data at the nearest grid cell.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| time_start | Yes | ||
| time_end | Yes | ||
| variables | No | no2,pm2p5,pm10 | |
| aggregate | No | monthly |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It explains the snapping behavior and return format (CSV with time series), but does not mention rate limits, permissions, or explicit read-only nature. However, the described behavior is clear and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by usage guidance and parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (6 parameters, output schema exists), the description covers all essential aspects: purpose, usage guidance, parameter formats, return format, and behavioral nuances like snapping. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter in an 'Args' block with formatting examples (e.g., lat: '48.8566 for Paris') and defaults for variables and aggregate. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool queries climate data for a single point location and snaps to the nearest grid cell. It distinguishes itself from the sibling tool 'query_climate' by noting it is a convenience wrapper for point queries rather than bounding box regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when you have a specific address or coordinate rather than a bounding box region. This provides clear guidance on when to use it versus the alternative query_climate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert coordinates to a street address (reverse geocoding).
Args: lat: Latitude in decimal degrees lon: Longitude in decimal degrees
Returns: JSON with nearest address: street, housenumber, city, postcode, country.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It describes the conversion and return format but lacks details on error handling, rate limits, or accuracy, which are important for a geocoding tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes parameter explanations and return format. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and return format. However, it does not address edge cases (e.g., invalid coordinates) or error behavior, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides only types (number) with 0% description coverage. The description adds 'Latitude in decimal degrees' and 'Longitude in decimal degrees', significantly enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert coordinates to a street address (reverse geocoding)' using a specific verb and resource. It distinguishes from the sibling tool 'geocode' which performs forward geocoding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (reverse geocoding) but does not explicitly state when to use or avoid, nor mention alternatives. However, the sibling tool list allows differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate raster climate data to administrative regions (NUTS3 or country).
Performs a spatial join — takes one or more raster datasets and computes the mean value for each NUTS3 region or country that overlaps the bounding box. Returns a table of regions with mean values per dataset.
Useful for regional comparison, portfolio screening, or joining climate data with official statistics by administrative area.
Args: lat_min: Southern boundary latitude lat_max: Northern boundary latitude lon_min: Western boundary longitude lon_max: Eastern boundary longitude time_start: Start date, e.g. "2022-01-01" time_end: End date, e.g. "2022-12-31" datasets: List of dataset source names to aggregate. Options: "cams_no2", "cams_pm2p5", "cams_pm10", "cams_o3", "era5_t2m", "era5_tp", "era5_blh", "era5_u10", "era5_v10", "viirs_radiance", "odiac_co2", "ghsl_pop", "ghsl_built", "aqueduct_bws", "aqueduct_bwd", "aqueduct_rfr", "aqueduct_drr" resolution: "nuts3" (EU administrative regions) or "country" (global)
Returns: JSON with a list of regions, each containing the mean value of each requested dataset. Also includes region name, country, and cell count.
| Name | Required | Description | Default |
|---|---|---|---|
| lat_min | Yes | ||
| lat_max | Yes | ||
| lon_min | Yes | ||
| lon_max | Yes | ||
| time_start | Yes | ||
| time_end | Yes | ||
| datasets | Yes | ||
| resolution | No | nuts3 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the spatial join operation and that it computes mean values. However, it does not disclose potential edge cases (e.g., no overlapping regions) or performance implications. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: one-line purpose, brief explanation, use cases, then clear Arg list and Returns. It is front-loaded with the key action and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (7 required) and an output schema, the description explains all inputs and the output format. It covers the spatial join, aggregation method, and administrative regions. The presence of an output schema reduces the need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The 'Args:' section explains each parameter with examples and allowed values for datasets. It adds meaningful context beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Aggregate raster climate data to administrative regions (NUTS3 or country).' This is a specific verb+resource that clearly states the tool's purpose. It distinguishes from siblings like query_climate (likely returns raw data) and geocode (address lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for regional comparison, portfolio screening, or joining climate data with official statistics by administrative area.' This provides clear usage context. It implies when to use it (for spatial aggregation) versus alternatives, but does not explicitly mention when not to use or name sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get WRI Aqueduct 4.0 water risk scores for a geographic region.
Returns water stress, depletion, flood risk, and drought risk for every 0.1° grid cell in the bounding box. Useful for CSRD ESRS E3-1 §27 (water stress) and E3-3 §38 (flood/drought risk) portfolio screening.
Scores: 1=Low, 2=Low-Medium, 3=Medium-High, 4=High, 5=Extremely High. Source: WRI Aqueduct 4.0 (2023). No credits consumed.
Args: lat_min: Southern boundary latitude lat_max: Northern boundary latitude lon_min: Western boundary longitude lon_max: Eastern boundary longitude Max bounding box: 50°×50°
Returns: JSON array of grid cells with bws, bwd, rfr, drr scores and labels.
| Name | Required | Description | Default |
|---|---|---|---|
| lat_min | Yes | ||
| lat_max | Yes | ||
| lon_min | Yes | ||
| lon_max | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles transparency. It states the output format (grid cells with scores), the score scale 1-5, the spatial resolution (0.1°), the max bounding box (50°×50°), and that no credits are consumed. This sufficiently describes the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single introductory sentence, then breakdown of metrics, scores, source, and argument descriptions. Every sentence adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (not shown but indicated), the description still explains the return structure (JSON array of grid cells with specific fields). It covers purpose, parameters, constraints, output format, and data source, making it complete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must add meaning. It defines each parameter (lat_min, lat_max, lon_min, lon_max) with brief descriptions like 'Southern boundary latitude' and adds a max bounding box constraint, which adds value beyond the schema's type-only info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves WRI Aqueduct 4.0 water risk scores (water stress, depletion, flood, drought) for a bounding box region. It distinguishes from sibling tools like geocode or query_climate by specifying the unique data source and metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case (CSRD ESRS portfolio screening) and explicitly mentions the regulation sections, which guides when to use. However, it does not exclude alternatives or mention when not to use this tool versus siblings like query_climate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1enrich_locationestimate_query_costfind_facilitiesgeocodeget_coveragequery_climatequery_climate_pointreverse_geocodespatial_linkwater_riskTools are largely distinct, but enrich_location overlaps with find_facilities and water_risk in purpose, potentially causing confusion. However, descriptions clarify the differences (point vs. area, limited vs. full search).
Most tools use verb_noun snake_case (e.g., enrich_location, query_climate), but geocode and reverse_geocode have inconsistent verb placement, and get_coverage uses a different verb prefix. Overall pattern is clear.
10 tools is well-scoped for the environmental data domain, covering geocoding, climate queries, water risk, and facility data without being overwhelming or sparse.
Core workflows (geocode, query climate, water risk, facility lookup) are covered. Minor gaps exist, such as a tool to list all available variables, but the set handles typical use cases well.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-world data for agents: air quality, geocoding, quakes, holidays, web search
Interact with climate metrics via Riskthinking.AI's CDT Express API in supported AI chat experiences
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
Access UK flood warnings, river levels, water quality, Met Office forecasts, and carbon data
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jiskta/jiskta-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
