Agent Data Tools: Everyday data

by dev.workers.revmesh2074.agent-data-tools

Weather forecast today: any city, 48 hours

weather_today

Read-only

Weather forecast today for any city or coordinates: current temperature, conditions, rain, wind and humidity now, plus an hourly forecast up to 48 hours ahead (MET Norway data). Give a city such as London or lat and lon. Use for travel, events, logistics or a daily brief. Example: city=London. Price $0.002/call via x402 USDC or a card key (/credits), first 25 free; failed calls free. Reads or computes only and changes nothing; each call is charged, so repeats are not free.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "weather_today"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Latitude in decimal degrees, -90 to 90 (with lon, instead of city)
`lon`	No	Longitude in decimal degrees, -180 to 180 (with lat, instead of city)
`city`	No	City or place name, e.g. London or Tokyo (used when lat and lon are not given)
`hours`	No	Hours of hourly forecast to return, 1-48 (default 12; 48 covers tomorrow)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Goes beyond the annotations by naming the data source (MET Norway), the per-call price and free tier, and explicitly reconciling the non-idempotent annotation's practical meaning ('each call is charged, so repeats are not free'). It also restates the no-side-effects guarantee, which is mild redundancy with readOnlyHint/destructiveHint but harmless. It stops short of describing response shape or how partial failures are surfaced.

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?

Purpose and scope are front-loaded in the first sentence, followed by input guidance and pricing. The pricing sentence packs several clauses ($0.002/call, x402 USDC, card key, first 25 free, failed calls free) that are dense but each carries distinct billing information the agent should know.

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?

With no output schema, the description compensates by enumerating the returned weather fields and the hourly horizon, and it covers inputs, data source, and cost. It is nearly sufficient to call correctly; only the exact response shape and error behavior remain unspecified, which is acceptable for a simple read tool.

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 coverage is 100%, so the baseline is 3; lat/lon ranges, the city alternative, and the 1-48 hour bounds are all already documented in the schema. The description corroborates the city-vs-coordinates choice and notes that 48 hours 'covers tomorrow', but adds little semantic detail (e.g. behavior when both city and lat/lon are supplied) beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Weather forecast today') and enumerates the returned data: current temperature, conditions, rain, wind, humidity, and hourly forecast up to 48 hours, from MET Norway. That is far more specific than a tautology, but it does not distinguish itself from the sibling tools 'weather' and 'weather_forecast', so an agent cannot tell from the description alone which forecast tool to pick.

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 clear usage contexts ('travel, events, logistics or a daily brief') and an input example (city=London). It offers no when-not-to-use guidance and never names an alternative sibling tool, so routing between this and 'weather'/'weather_forecast' is left to inference.

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

All Agent Data Tools: Everyday data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?