API Acre

data.us-weather-forecast

Read-onlyIdempotent

Get a global weather forecast for a city/locality name or exact coordinates. Returns normalized day/night or hourly periods worldwide: NOAA/NWS is preferred within supported U.S. coverage for optional station conditions and active alerts, while MET Norway provides an attributed open-data fallback globally.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`place`	No	City or locality name, optionally followed by country and first-level region qualifiers, for example London, GB or Paris, Texas, US. Provide either place or both latitude and longitude.
`units`	No	US customary or SI units requested from the NWS API	us
`periods`	No	Maximum periods to return; day_night supports at most 14 and hourly at most 48
`latitude`	No	Latitude in decimal degrees, rounded to four decimal places. Provide with longitude instead of place.
`timezone`	No	Optional IANA time zone used to group MET Norway day/night periods. Place-name requests use the matched GeoNames zone; coordinate requests default to UTC; NWS returns its authoritative point time zone.
`longitude`	No	Longitude in decimal degrees, rounded to four decimal places. Provide with latitude instead of place.
`forecast_type`	No	Day/night forecast periods or hourly forecast periods	day_night
`source_preference`	No	Prefer NWS within its U.S. coverage and fall back to MET Norway globally, or explicitly select one source	auto
`include_active_alerts`	No	Include up to 10 currently active NWS alerts whose affected area contains the requested point
`include_current_conditions`	No	Include the latest observation from the nearest available NWS station; kept opt-in to preserve baseline latency

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Structured Global weather forecast result
`meta`	Yes
`service`	Yes
`version`	Yes
`request_id`	Yes	Unique request identifier

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful source-selection behavior: NOAA/NWS preferred for U.S. coverage, MET Norway attributed fallback globally, and optional inclusion of station conditions and active alerts. No contradiction with annotations.

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 a single, front-loaded sentence that conveys the core purpose, the dual input modes, the output period types, and the source strategy without wasted verbiage. Every clause earns its place.

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?

For a moderately complex tool with 10 parameters and an output schema, the description covers the key decision-relevant context: global scope, forecast period kinds, source precedence, and optional alert/condition augmentation. The schema handles remaining details like the oneOf constraint and exact parameter bounds, so the description does not need to repeat them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with detailed per-parameter descriptions for place, coordinates, units, periods, timezone, forecast type, source preference, and alerts. The description adds a high-level summary of accepted inputs (place vs coordinates) but does not materially augment the schema's parameter semantics.

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 opens with 'Get a global weather forecast for a city/locality name or exact coordinates', clearly stating the verb, resource, and input modes. It further distinguishes the tool by specifying normalized day/night or hourly periods and the dual-source NWS/MET-only behavior.

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?

The context is clear: this is a global weather forecast tool with NWS preferred in U.S. areas and MET Norway fallback. However, there is no explicit mention of when to prefer this tool over the sibling data.current-weather tool or other weather-related alternatives, so usage guidance is implied rather than explicit.

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

All API Acre 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

A3.8/5.0

Disambiguation4/5

Tools are grouped into clear domain prefixes (crypto, data, developer, document, research, web) and each tool name describes a specific function; however, a few umbrella tools like web.full-audit and data.contract overlap with their more targeted counterparts, creating minor ambiguity.

Naming Consistency5/5

All tool names follow a consistent pattern: a domain prefix, a dot, and a hyphenated lowercase compound name (e.g., crypto.base-block-inspect, web.seo-audit). This makes naming predictable and easy to scan.

Tool Count1/5

At 63 tools, the surface area is very large and exceeds the 50+ threshold for extreme mismatch. While the tools are organized into six domains, the sheer number makes it difficult for an agent to select efficiently, and some tools are bundled combinations of others.

Completeness5/5

Each domain offers a thorough set of operations: crypto covers address, account, block, contract, events, gas, and transaction inspection; data covers cleaning, conversion, schema, and validation; developer covers code review, dependency/license audits, and test generation; research covers SEC, OFAC, GLEIF, and USAspending; web covers extraction, SEO, security, and performance. No obvious dead ends exist for the read-only/inspection purpose.

Resources

Need Help?