jiskta-mcp

Official

by Jiskta

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
Tools 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).
Naming Consistency4/5
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.
Tool Count5/5
10 tools is well-scoped for the environmental data domain, covering geocoding, climate queries, water risk, and facility data without being overwhelming or sparse.
Completeness4/5
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.
Average 4.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
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 (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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jiskta-mcp MCP server](https://glama.ai/mcp/servers/Jiskta/jiskta-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Jiskta/jiskta-mcp)

Score Badge

Copy to your README.md:

[![jiskta-mcp MCP server](https://glama.ai/mcp/servers/Jiskta/jiskta-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Jiskta/jiskta-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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