Agent Weather

IANA timezone + DST (paid: 0.001 RLUSD / 0.001 USDC on Base / 0.001 RLUSD on Base via x402)

timezone_dst

Read-only

Paid: 0.001 RLUSD per call via x402 on XRPL mainnet (xrpl:0), or 0.001 USDC on Base (eip155:8453). Pay per call, solves one question: Convert an instant into an IANA zone, or list DST transitions. Reads runtime ICU/IANA tzdata. Without payment this returns isError with the x402 PaymentRequired object (fresh invoiceId); retry with the signed payload in _meta["x402/payment"] or the payment_signature argument. Unpaid calls cost nothing.

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": {
      "timezone": "<timezone>"
    },
    "name": "timezone_dst"
  }
}

Input Schema

Name	Required	Description
`op`	No
`year`	No
`instant`	No
`timezone`	Yes
`payment_signature`	No	Optional. Base64 x402 PAYMENT-SIGNATURE value (signed RLUSD or USDC PaymentPayload) for hosts that cannot set _meta["x402/payment"]. Omit on the first call to receive the payment requirements.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

B3.1/5.0

Behavior4/5

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

Annotations only declare read/safe/idempotent=false; the description adds genuinely new behavior: reads runtime tzdata, requires x402 payment on XRPL or Base, returns isError with a PaymentRequired object containing a fresh invoiceId when unpaid, and can be retried with a signed payload in _meta["x402/payment"] or payment_signature. That is a substantive disclosure an agent needs before calling. It does not describe output shape, but this dimension is about behavior, not returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly half the text is pricing and payment-mechanics boilerplate that duplicates the title, and the actual purpose ('solves one question...') arrives only after the pricing block. The content is not padded with fluff, but it is not front-loaded on what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should explain what a conversion result or a transitions list looks like; it does not. With op and year undocumented and 20% schema coverage, an agent must guess the mode-selection contract even though the payment path is described exhaustively.

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

Parameters2/5

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

Schema description coverage is only 20%, so the description must carry parameter meaning, and it largely does not. The op parameter (the key discriminator between convert and transitions) and the year parameter are never explained, and the timezone/instant formats are only loosely implied by 'instant into an IANA zone'.

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?

The description names a specific verb and resource: 'Convert an instant into an IANA zone, or list DST transitions', and identifies the tzdata source (runtime ICU/IANA). It is clearly distinct from siblings like get_business_day or cron_next, though the actual purpose is buried behind a payment preamble.

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 two operating modes (convert vs. list transitions) are implied by 'or list DST transitions', but the description never names the op values, never says which parameters apply to which mode, and never contrasts this tool with siblings that also do date/time work. It gives payment flow guidance in detail but no routing guidance.

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

All Agent Weather 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?