Prediction Markets Quant

Kalshi Weather Board — daily-high strikes vs the NWS forecast

weather_board

Read-only

Use for "Kalshi NYC high temperature odds". Every open Kalshi daily-high strike in 13 cities: YES price, settlement station and source, the strict-comparison rule, close time, and the NWS forecast high beside it. Pass city ("nyc", "KXHIGHCHI"). Market data only.

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_board"
  }
}

Input Schema

Name	Required	Description	Default
`day`	No	today (default) · tomorrow · all.
`city`	No	City name or series ("nyc", "KXHIGHTBOS"). Omit for all.

Output Schema

Name	Required	Description
`rule`	No	The strict comparison Kalshi settles on.
`as_of`	No	When the board was read.
`cities`	No	Per city and settlement day: NWS high, close time, strikes with two-sided YES mids.
`sources`	No
`tell_user`	No	Show this sentence to the user first.
`timestamp`	No
`needs_input`	No
`example_call`	No
`data_freshness`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / day / description

Previous value: -"today · tomorrow · all (default)."New value: +"today (default) · tomorrow · all."

Changed1 schema field changedOct 31, 2026

changedOutput schema / properties / cities / description

Previous value: -"Per city and settlement day: NWS high, bias-adjusted high, close time, strikes with two-sided YES mids."New value: +"Per city and settlement day: NWS high, close time, strikes with two-sided YES mids."

Changed2 schema fields changedOct 23, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

AddedOct 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false), so the bar is lower, and the description still adds real context: 13-city scope, the strict-comparison settlement rule, and the fact that it is market data only with no analysis. It doesn't mention refresh behavior, pagination across strikes, or rate considerations, which is the remaining gap.

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?

Three tight sentences, front-loaded with the use case before the payload list. The telegraphic clause stacking ('close time, and the NWS forecast high beside it') is dense but earns its place; no filler.

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 an output schema present, return-value detail is unnecessary, and the two optional params are fully covered by the schema. What remains missing is minor: defaults for 'day' (today) and what happens when a city has no open strikes.

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 both parameters are already documented. The description's city examples ('nyc', 'KXHIGHCHI') restate the schema's own examples and it adds nothing about the day parameter, so baseline 3 applies.

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 names a specific resource (every open Kalshi daily-high strike) and enumerates the payload: YES price, settlement station/source, comparison rule, close time, and NWS forecast high. The opening phrase 'Use for "Kalshi NYC high temperature odds"' plus the '13 cities' scope makes it clearly distinguishable from the sibling analysis tools (calculate_ev, kelly_size, bayes_update).

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?

'Use for ...' gives an explicit trigger phrase, and 'Market data only' fences off the analytical work that the siblings handle. It lacks an explicit counterpart callout (e.g. 'for EV of a strike, use calculate_ev'), so the routing is strong but not fully closed.

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

All Prediction Markets Quant 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.