Abstraxn

Weather forecast and current conditions

weather.forecast

Read-onlyIdempotent

Weather data from a global weather data provider — current conditions, short-range forecast, astronomy, historical, marine, and location search. Free, read-only, no wallet needed. Every action requires q, a location: a city name (e.g. "Paris"), "lat,lon" (e.g. "48.85,2.35"), a US/UK/Canadian postal code, or an IATA airport code. Pick one action:

current: current conditions for q. Optional aqi (default false) adds basic air quality data.
forecast: forecast for q. Optional days — this deployment runs on a data plan capped at 3 days, so only 1-3 is accepted; omit for the provider default. Optional aqi, alerts (default false, adds active weather alerts for the location where available).
astronomy: sunrise/sunset/moonrise/moonset/moon phase for q on date (required, YYYY-MM-DD).
search: resolve a fuzzy q into matching locations (name, region, country, lat/lon) — use this first if you only have an approximate place name and need to disambiguate.
history: past weather for q on date (required, YYYY-MM-DD, must be yesterday). This deployment enforces a free-tier data plan that only allows yesterday's date — any other date is rejected before a provider call is made.
marine: marine/sailing conditions for q. This deployment runs on a data plan limited to 1 day of data with no tide information.

Results are for general informational purposes only — do not use them as the sole basis for decisions involving personal safety, aviation, marine navigation, or emergency planning.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	Yes	Location: city name, "lat,lon", postal code, or airport code. Required for every action.
`aqi`	No	current / forecast / history: include basic air quality data (default false).
`date`	No	astronomy / history: date in YYYY-MM-DD format. Required for both.
`days`	No	forecast: number of forecast days (1-3 on this deployment's plan). Omit for the provider default.
`action`	Yes	Which weather operation to perform.
`alerts`	No	forecast: include active weather alerts for the location (default false).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`message`	No

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark the tool as read-only and non-destructive, and the description adds important deployment limitations: forecast capped at 3 days, history only yesterday, marine limited to 1 day with no tides. It also includes an appropriate safety disclaimer about informational use.

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 long but efficiently organized: a lead sentence establishes scope, followed by one bullet per action with its relevant parameters and limitations. Every sentence adds non-redundant information that an agent needs for correct invocation.

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 six-action tool, the description covers all actions, location formats, per-action parameter applicability, deployment limits, and caveats. The presence of an output schema covers return-value details, so the description is complete for selection and invocation.

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?

Although the schema covers all parameters, the description adds real operational meaning: q format examples (city, lat,lon, postal code, IATA), which parameters apply to which action, and constraints like yesterday-only dates. This goes well beyond the schema's basic field 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?

The description clearly identifies the tool as a weather data provider covering current conditions, forecast, astronomy, history, marine, and location search. This specificity distinguishes it from unrelated sibling tools like network, crypto, and market tools.

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?

Each action is documented with its own usage context, including explicit guidance to use 'search' first for approximate place names. Deployment-specific constraints like the 3-day forecast cap and yesterday-only history clarify exactly when requests will fail.

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

All Abstraxn tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Tools are grouped by domain (market, network, places, social, travel, web3) and each has a distinct purpose. However, within the 'network' group, tools like token_price, token_info, and market.crypto/price_feed could be confused for similar price lookups, but descriptions clarify their differences (free vs paid, DEX vs CoinGecko).

Naming Consistency3/5

The naming uses a dot-separated domain prefix (e.g., market.crypto, network.blocknumber, places.lookup) which is consistent in structure, but the action selection within each tool (e.g., search vs price_feed) is not reflected in the tool name itself. This hybrid approach is clear but not strictly uniform.

Tool Count4/5

With 11 tools covering a wide range of domains (crypto, network, places, social, travel, web3), the count is appropriate for a multi-purpose server. Each domain has a focused set of actions, so the tool count feels well-scoped without being excessive.

Completeness3/5

The server covers a broad but shallow surface across multiple domains. For example, crypto market data is well-covered, but places lacks a reverse geocode or photo tool. Travel has only flight and hotel search, missing car rentals or activities. The network domain is relatively complete for read operations, but lacks write support beyond prepare_transfer.

Resources

Need Help?