Agent Utils (x402)

by dev.workers.revenue-agent-jw.agent-utils-x402-production

NWS climate-day high/low + official CLI

climate_day

Read-onlyIdempotent

Daily high and low temperature for a US weather station from NWS: running provisional high/low over the station's climate day (midnight-midnight local standard time) and the official NWS Daily Climate Report (CLI) high/low once issued, flagged preliminary or final. Useful for temperature settlement, weather prediction markets and climate records. Optional temperature buckets (width/offset or explicit edges). Errors: 400 JSON {error} for invalid input. PAID: $0.002 USDC per call on Base via x402 (MCP transport: retry with params._meta["x402/payment"]). Same tool over plain HTTP: GET /v1/weather/climate-day.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "station": "<station>"
    },
    "name": "climate_day"
  }
}

Input Schema

Name	Required	Description
`cli`	No	override CLI location code (default: station without leading K)
`date`	No	climate date (LST), default today; up to ~6 days back
`edges`	No	comma-separated increasing bucket edges; overrides width/offset
`round`	No
`units`	No
`station`	Yes	NWS/ICAO station id, e.g. KNYC, KMDW, KLAX
`bucket_width`	No	bucket width, default 1
`bucket_offset`	No	bucket origin, default 0

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and open-world, but the description adds substantial context they cannot: the two-tier data model (provisional vs official CLI, flagged preliminary/final), the 400 JSON error shape, and the x402 paid-call mechanism with the exact retry hook. That payment/retry detail is genuinely actionable and is the strongest part of the definition.

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-loaded with the core purpose, then layered: usage, buckets, errors, payment. Dense but every sentence carries information; the only mild clutter is the HTTP endpoint note, which matters for non-MCP callers.

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 eight parameters and no output schema, the description does the heavy lifting on return values (provisional and official high/low with a preliminary/final flag) and error behavior. It stops short of explaining what the bucket parameters produce in the response, which is the one remaining gap.

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 75%, and the description still adds meaning: bucket construction via width/offset or explicit edges with edges overriding, the CLI code defaulting to the station id without the leading K, and the date defaulting to today with a ~6-day lookback. Only 'round' and 'units' go unexplained, and both are self-describing enums.

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: daily high/low temperature for a US NWS station, split into provisional running values and the official CLI report. It is distinguishable from the generic sibling us_weather by the climate-day and CLI framing, though it never names that sibling to sharpen the contrast.

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?

It supplies usage context ('temperature settlement, weather prediction markets and climate records') and notes the ~6-day lookback limit, which implies when it fits. It never states when to prefer us_weather over this tool, nor any exclusions or prerequisites beyond the paid-call note.

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

All Agent Utils (x402) 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?