geosphere-mcp-server

get_current_weather

Retrieve current weather conditions for a latitude/longitude point, using high-resolution GeoSphere Austria data across Austria and the Alpine region, including observed precipitation.

Instructions

Get current weather conditions for a location.

High-resolution GeoSphere Austria data (AROME/INCA/nowcast). Serves Austria
and the Alpine region only; a point outside that grid returns an
out-of-coverage notice. The response states which datasets served it.

Observations decide whether and what is falling; the rest of the condition
comes from GeoSphere's weather symbol for the current hour.

Args:
    latitude: Decimal latitude (e.g. 48.2208 for Vienna). Geocode city
        names to coordinates yourself.
    longitude: Decimal longitude (e.g. 16.3738 for Vienna).

Input Schema

Name	Required	Description	Default
`latitude`	Yes
`longitude`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it names the underlying datasets (AROME/INCA/nowcast), discloses that out-of-grid requests yield an out-of-coverage notice rather than an error, and says the response states which datasets served it. It omits latency, caching, or rate-limit behavior, which keeps it below a 5.

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-loads the verb and resource, then layers scope, provenance, and semantics in short paragraphs; each block is load-bearing. The brief note on how falling precipitation is decided is slightly tangential but reinforces trust in the result, so it earns most of its space.

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 two-parameter read tool with an output schema already present, the description covers everything an agent needs: what it returns conceptually, geographic limits, failure mode outside coverage, and parameter format. Nothing material is left to inference.

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% and the schema supplies only bare 'number' types, so the description does the real work: it specifies decimal latitude/longitude semantics, gives concrete Vienna values for both fields, and tells the agent to resolve place names itself. Without this text the parameters would be effectively undocumented.

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?

States a specific verb and resource ('Get current weather conditions') and immediately scopes it by data source and geography. The word 'current' plus the observation/symbol explanation clearly separates it from siblings like get_hourly_forecast and get_air_quality without needing to name them.

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?

Gives a hard applicability rule (Austria and the Alpine region only, out-of-coverage point returns a notice) and an explicit responsibility for the caller (geocode city names to coordinates yourself). It stops short of routing advice such as when to prefer get_hourly_forecast or get_storm_outlook instead.

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

Deploy Server