Agent Weather

Batch readings (paid: sum RLUSD via x402)

batch_readings

Read-only

Paid: sum RLUSD per call via x402 on XRPL mainnet (xrpl:0); RLUSD only. Pay per call, solves one question: Return up to 5 Agent Weather readings in one call. Price = sum of the selected readings' standalone prices (keys: pulse_storm, pulse_providers, pulse_facilitator, price_index, health_report, discovery_feed, base_gas_fees, base_block_tip, mcp_registry_counts, utc_time). Nothing is charged if any selected reading cannot be produced. 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": {
      "items": "<items>"
    },
    "name": "batch_readings"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes	Comma list of reading keys, max 5, e.g. pulse_storm,pulse_facilitator
`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.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / items / description

Previous value: -"Comma list max 5"New value: +"Comma list of reading keys, max 5, e.g. pulse_storm,pulse_facilitator"

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the payment rail (x402 on XRPL mainnet, RLUSD only), the all-or-nothing charge policy ("Nothing is charged if any selected reading cannot be produced"), and the exact failure/retry protocol including the isError shape with a fresh invoiceId and where to put the signed payload. That is precisely the behavioral context annotations cannot convey here.

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 paid/batch fact and dense with useful detail; nearly every clause carries operational weight. The opening sentence is somewhat run-on ("Pay per call, solves one question: Return..."), mixing pricing, scope, and purpose, but nothing is truly redundant.

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 paid tool with no output schema, the description covers cost, failure, and retry thoroughly. The remaining gap is the success payload: it says it returns readings but not their shape or how up to 5 results are keyed/ordered, and with no output schema the agent has nothing else to rely on.

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 100%, so the baseline would be 3, but the description adds genuine meaning the schema lacks: it enumerates the ten valid reading keys (pulse_storm, pulse_providers, price_index, base_gas_fees, etc.), which the schema only gestures at with an example. It also clarifies that payment_signature is the fallback path when _meta["x402/payment"] is unavailable.

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?

"Return up to 5 Agent Weather readings in one call" gives a specific verb, a bounded resource, and the batching scope in one clause, and the pricing rule ("Price = sum of the selected readings' standalone prices") distinguishes it from calling the individual reading tools. An agent can immediately tell this is the multi-item variant rather than a single-reading tool.

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?

Usage is clear from context: select up to 5 keys from the enumerated list, and the note that price equals the sum of standalone prices tells an agent there is no batching discount, which is real selection guidance. What is missing is an explicit statement of when to prefer individual reading tools over this one (e.g. for a single key) or an exclusion for keys not in the list.

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?