Weather Edge 是一个用于校准 Kalshi 天气市场信号的 MCP 服务器。它将公开的预测和市场数据转化为 AI 代理的紧凑工具界面。
校准各城市的 NWS 日最高气温预测
读取当前的 Kalshi 天气市场价格
估算每个区间的概率、边缘和净期望值
通过 MCP 工具和可选的 FastAPI 界面公开结果
Related MCP server: SimpleFunctions
pip install weather-edge-mcp{
"mcpServers": {
"weather-edge": {
"command": "python",
"args": ["-m", "weather_edge_mcp"]
}
}
}使用以下任一命令：
weather-edge-mcp
python -m weather_edge_mcpweather-edge-mcp --transport stdio
weather-edge-mcp --transport sse --port 8050
weather-edge-mcp --transport streamable-http --port 8050工具 | 描述 |
| 获取某个城市 Kalshi 天气市场的校准信号 |
| 扫描所有支持的城市 |
| 获取某个支持城市的偏差调整后预测上下文 |
| 获取结算站点的最新 METAR 观测数据 |
| 支持的城市及校准参数 |
支持的城市：nyc, chicago, denver, miami, la
Weather Edge 还附带一个可选的 FastAPI 应用：
python -m uvicorn weather_edge_mcp.web_app:app --host 0.0.0.0 --port 8080路由：
/api/health
/api/signals?city=nyc
/api/all-signals
/dashboard
/subscribe
如果安装并配置了可选的 x402 堆栈，付费路由可以在那里进行门控。MCP stdio 模式保持纯净且无副作用。
该仓库包含用于 Glama/容器构建的 Dockerfile。
docker build -t weather-edge-mcp .
docker run --rm weather-edge-mcp --helpsrc/weather_edge_mcp/
core.py # forecasting, market fetches, calibration, formatting
mcp_server.py # MCP tools
web_app.py # optional FastAPI surface
cli.py # command-line entrypoint美国国家气象局 (NWS) 预测 API
航空气象 METAR API
Kalshi 公共市场 API
python -m unittest discover -s tests -v
python -m buildMIT
Run a full scan across all supported cities and rank top weather-market signals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It describes the action as a 'full scan' but does not mention any side effects, potential rate limits, authorization requirements, or whether the scan is resource-intensive. The agent has no information about safety or performance implications, which is a significant gap for a potentially expensive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single sentence that clearly and efficiently conveys the tool's purpose. Every word is meaningful, with no redundancy or filler. It is appropriately sized for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (though not shown in this evaluation), the description is largely complete. It states the tool scans all cities and ranks signals. However, it could benefit from noting that this is a broad, potentially expensive operation, and that the output schema details the results. Overall adequate but slightly lacking in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (empty schema). The description adds no parameter-level information because none is needed. With zero parameters, the baseline for this dimension is 4, and the description does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a full scan across all supported cities and ranks top weather-market signals. It specifies the verb ('run a full scan'), resource ('signals'), and scope ('all supported cities'), distinguishing it from siblings like get_weather_signals which likely filter by city or other criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool: for a comprehensive scan across all cities. However, it does not explicitly state when not to use it or mention alternatives such as get_weather_signals for more targeted queries. The context of sibling tools provides some guidance, but the description lacks explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw calibrated forecast context for one supported city.
Args: city: One of nyc, chicago, denver, miami, la.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry full behavioral disclosure. It does not mention any behavioral traits such as whether the operation is read-only, any authentication needs, or rate limits. The term 'raw calibrated forecast context' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes a clear parameter list. Every sentence is functional, but it could be more structured with headings or bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description need not explain return values. However, for a simple tool with one parameter, it is minimally complete but lacks guidance on error conditions or alternative tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by listing the allowed cities (nyc, chicago, denver, miami, la). However, it does not explain the meaning of 'city' beyond these values or provide formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('raw calibrated forecast context'), and it is distinct from sibling tools which focus on signals or observations. However, it does not explicitly differentiate itself from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_weather_signals or get_station_observation. The description only lists supported cities without explaining the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest METAR observation from the settlement station for one city.
Args: city: One of nyc, chicago, denver, miami, la.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral disclosure. It mentions the tool provides the latest METAR observation and lists allowed cities, but lacks details on error handling, cache behavior, or output structure. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, including a structured Args section. Every sentence is necessary, though front-loading could be improved by placing the allowed cities list earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an existing output schema, the description is mostly complete. It covers the purpose, parameter, and allowed values. Missing are any notes on return format or potential errors, but these are mitigated by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by enumerating allowed city values (nyc, chicago, denver, miami, la) which the input schema does not provide (no enum). Since schema coverage is 0%, this partially compensates, but does not explain format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the latest METAR observation for a single city, which distinguishes it from sibling tools like get_all_signals or get_forecast. However, it does not explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists valid city values but provides no guidance on when to use this tool instead of siblings like get_forecast or get_all_signals. No exclusion criteria or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get calibrated edge signals for one city's Kalshi weather markets.
Args: city: One of nyc, chicago, denver, miami, la.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It implies a read operation ('Get') and lists city options but does not explicitly state side effects, permissions, or rate limits. However, the simple retrieval nature and presence of output schema mitigate missing details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences), front-loads the purpose, and includes the parameter specification without redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and an output schema, the description covers the essential purpose and allowed values. It does not explain return structure (handled by output schema) or any prerequisites, but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enum, but the description adds the allowed values 'nyc, chicago, denver, miami, la' for the city parameter, fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get' and the resource 'calibrated edge signals for one city's Kalshi weather markets', clearly distinguishing it from siblings like get_all_signals (broader) and get_forecast (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the allowed city values and states 'one city', but does not explicitly guide when to use this tool vs alternatives like get_all_signals for multiple cities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported cities, settlement stations, and calibration parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It only describes the action as 'List', implying read-only, but offers no details on side effects, data source, or reliability. More context is needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the verb. Every word is essential, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and an output schema exists, so the description is minimally adequate. However, it does not hint at the structure or size of the output, nor any filtering capabilities. For a trivial tool, this is sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description does not need to explain parameters. Baseline 4 is appropriate as no additional semantic is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported cities, settlement stations, and calibration parameters. The verb 'List' combined with specific resources differentiates it from sibling tools that deal with signals, forecasts, and observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1get_all_signalsget_forecastget_station_observationget_weather_signalslist_citiesScored across 5 tools
Each tool has a distinct purpose: listing cities, getting forecasts, getting observations, getting signals for one city, and scanning all cities. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (get_* and list_cities), with no mixing of conventions or ambiguous verbs.
5 tools is well-scoped for a weather market server covering 5 cities. Each tool provides essential functionality without redundancy.
The tool set covers key operations: listing cities, retrieving raw data (forecast, observation), and market signals. A minor gap is the lack of a combined retrieval for all cities' raw data, but overall coverage is solid.
Kalshi weather markets: daily-high board beside the NWS forecast, live edges, EV, Kelly, base rates.
Calibrated world model for AI agents. 40 tools: world state, markets, trading. Kalshi + Polymarket.
Calibrated probabilistic foresight for AI agents, powered by live prediction-market signal.
Financial data for AI agents: crypto data, Polymarket odds, weather/oil calibration, trust scoring.
