Skip to main content
Glama
Bigred97

au-weather-mcp

compare_locations

Compare current weather across multiple Australian locations simultaneously. Each location is resolved independently; failures return errors without affecting other results.

Instructions

Compare current weather across multiple Australian locations in one call.

Fans out concurrently via asyncio.gather, so all locations come back in roughly the time of a single call (after the cache is warm). Each location is independently resolved (curated / state / postcode / geocode / etc.) and independently fetched. If one location fails (e.g. geocoder can't find it), that row gets an error field while the rest still return.

Examples: # Capital-city dashboard resp = await compare_locations(["sydney","melbourne","brisbane","perth"]) for row in resp.locations: print(row.location_name, row.current.temperature_c)

# Tropical north today
resp = await compare_locations(["Cairns","Darwin","Townsville","Broome"])

# Mixed input shapes work
resp = await compare_locations(["sydney","NSW","2026","-33.87,151.21"])

When to use: - "Compare weather in " — the canonical use case - Build a multi-region dashboard in one tool call - Plan a holiday across regions

Returns: ComparisonResponse with one ComparisonRow per input location. Successful rows have current populated; failed rows have error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locationsYesTwo to ten Australian locations to compare side-by-side. Each entry accepts the same shapes as latest(): curated ID, place name, state, postcode, or 'lat,lng'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metricYes
sourceNoOpen-Meteo (aggregates Bureau of Meteorology data under licence)
locationsYes
attributionNoWeather data by Open-Meteo.com (https://open-meteo.com), licensed under CC BY 4.0. Underlying data includes the Australian Bureau of Meteorology (https://www.bom.gov.au) under Open-Meteo's licensing arrangement.
retrieved_atYes
server_versionYes
Behavior5/5

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

Without annotations, the description carries full burden. It details concurrent fan-out via asyncio.gather, independent resolution of each location, error handling (failures yield error fields without affecting others), and caching behavior. This provides comprehensive insight into the tool's operation.

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 clear sections (purpose, behavior, examples, when to use, returns). It is informative without being verbose, though slightly more conciseness could be achieved by trimming some repetitive elements.

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 output schema exists, the description appropriately focuses on input usage and behavioral details. It covers single-parameter usage thoroughly, explains error behavior, and mentions return structure, making it self-contained for effective agent invocation.

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 100% and the schema already describes the 'locations' parameter well. The description adds value by providing concrete examples and clarifying that mixed input shapes (IDs, names, postcodes) are accepted, which enhances usability beyond the schema alone.

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 'Compare current weather across multiple Australian locations in one call.' It specifies the verb (compare), resource (current weather), and scope (multiple Australian locations). This clearly distinguishes it from sibling tools like 'get_weather' which handles a single location.

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 'When to use' section provides clear use cases such as comparing weather in several cities, building multi-region dashboards, or planning holidays. It does not explicitly list alternatives, but the context strongly implies when to use this tool versus single-location tools like 'get_weather'.

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

Install Server

Other Tools

Latest Blog Posts

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/Bigred97/au-weather-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server