Stormクロス会場予測市場インテリジェンスAPIを、あらゆるModel Context Protocolクライアントに公開するMCPサーバー。
Stormは、Eyewall Marketsを運営する自律型AIエージェントであり、Polymarket、Kalshi、Manifold、Futuur、Betfair、ForecastExなどにまたがるクロス会場予測市場インテリジェンスサービスです。このパッケージは、軽量なstdio MCPブリッジであり、Claude Desktop、Claude Code、Cursor、Zed、その他MCP対応ホストなどのLLMクライアントが、Stormの標準的なイベント、クロス会場スプレッド、会場カタログ、ユーザーごとのアラート受信トレイをネイティブのツール呼び出しとして読み取れるようにします。
これは、すでにStormのサブスクリプションを持っており、自身のLLMワークスペースでStormが見ている情報を確認したいアナリスト、トレーダー、エージェント開発者を対象としています。
Storm APIはEdgeティアのサブスクライバー（月額499ドル）に限定されています。
api_keyは https://eyewallmarkets.com/account で生成してください。下位ティアにはAPIアクセス権がなく、このサーバーが呼び出すすべてのエンドポイントからHTTP 403が返されます。
APIキーはstk_の後に48文字の16進数が続く形式（合計52文字）で、単一のアカウントにスコープされています。他のベアラー認証情報と同様に扱ってください。
完全なAPIリファレンスは https://eyewallmarkets.com/api/docs にあります。
Related MCP server: pmxt-mcp
Claude DesktopのMCP設定ファイルを編集し、mcpServersの下にstormエントリを追加します：
{
"mcpServers": {
"storm": {
"command": "npx",
"args": ["-y", "@eyewallmarkets/storm-mcp"],
"env": {
"STORM_API_KEY": "stk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}macOSのパスは以下の通りです：
~/Library/Application Support/Claude/claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json· Windows:%APPDATA%\Claude\claude_desktop_config.json
Claude Desktopを再起動します。新しい会話内のツールリストに7つのstorm_*ツールが表示されるはずです。
claude mcp add storm npx -- -y @eyewallmarkets/storm-mcp次に、Claude Codeがサーバーを起動する環境にAPIキーをエクスポートします（またはシェルプロファイルに設定します）：
export STORM_API_KEY=stk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx正確なCLI呼び出しはClaude Codeのバージョンによって異なる場合があります。公式ドキュメント（https://docs.claude.com/en/docs/claude-code/mcp）で標準的な形式（mcp add行自体で環境変数を渡す方法を含む）を確認してください。
インストール後、Claude Code内で/mcpを実行し、stormサーバーが接続され、7つのツールが登録されていることを確認します。
Cursorは~/.cursor/mcp.jsonからMCPサーバー定義を読み取ります。Claude Desktopで使用したものと同じ形式を追加します：
{
"mcpServers": {
"storm": {
"command": "npx",
"args": ["-y", "@eyewallmarkets/storm-mcp"],
"env": {
"STORM_API_KEY": "stk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}CursorのMCP統合をリロードします（設定 → MCP → 更新）。
Zedは~/.config/zed/settings.jsonのassistant.context_serversでMCPサーバーを設定します：
{
"assistant": {
"context_servers": {
"storm": {
"command": "npx",
"args": ["-y", "@eyewallmarkets/storm-mcp"],
"env": {
"STORM_API_KEY": "stk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}
}Zedを再起動するか、アシスタントパネルをリロードします。
すべての設定は、サーバー起動時に読み込まれる環境変数によって行われます。
変数 | 必須 | デフォルト | 説明 |
| はい | — | EdgeティアのAPIキー。形式は |
| いいえ |
| APIルートを上書きします。ステージングやローカル開発サーバーに便利です。 |
| いいえ |
| リクエストごとのタイムアウト（ミリ秒）。 |
| いいえ |
|
|
7つのツールはすべて読み取り専用で、べき等です。引数の形式は以下のJSONスキーマ風の形式で文書化されています。ライブスキーマはMCPクライアントが実際に認識するものです。
storm_list_events標準的な（クロス会場の）イベントを一覧表示します。カーソルによるページネーションが可能です。
{
"limit": { "type": "integer", "default": 50, "max": 200 },
"cursor": { "type": "string", "optional": true },
"category": { "type": "string", "optional": true, "example": "politics" },
"status": { "type": "string", "optional": true, "enum": ["open", "closed", "resolved"] }
}プロンプト例: "Stormで次に公開される政治イベントを20件リストアップして。"
storm_get_eventスラグで単一のイベントを取得します。これには、リンクされたすべての結果と会場ごとの価格が含まれます。
{
"slug": { "type": "string", "required": true, "example": "us-pres-2028" }
}プロンプト例: "us-pres-2028のStormの全記録を取得して、どの結果が最も広いクロス会場スプレッドを持っているか教えて。"
storm_list_spreadsネットエッジ（手数料差し引き後）が基準をクリアする最近のクロス会場スプレッドを一覧表示します。エッジの降順でソートされます。
{
"min_edge_bps": { "type": "integer", "default": 100 },
"limit": { "type": "integer", "default": 50, "max": 200 },
"cursor": { "type": "string", "optional": true }
}プロンプト例: "現在、少なくとも250 bpsのエッジがあるStormスプレッドのトップ10を表示して。"
storm_get_market(venue_slug, external_id)で単一の会場/市場記録を検索します。
{
"venue": { "type": "string", "required": true, "example": "polymarket" },
"external_id": { "type": "string", "required": true }
}プロンプト例: "StormでPolymarket市場0xabc...を検索して。"
storm_list_venuesStormが追跡するすべての会場を一覧表示します。規制状況（CFTC登録DCM、オフショアなど）、手数料体系、機能フラグ（オーダーブック、AMM、パリミュチュエル）が含まれます。
{}プロンプト例: "Stormが追跡している会場のうち、CFTC登録DCMはどれ？"
storm_get_alerts_inboxユーザーのAPIチャネルアラート受信トレイをポーリングします。Edgeサブスクライバーはアラートをapi配信チャネルにルーティングできます。このツールは未確認のキューを排出します。
{
"since": { "type": "integer", "minimum": 0, "optional": true, "example": 4521 }
}カーソルは、最後に確認したアラートの整数idです。新しいアラートのみを取得するには、前回のレスポンスからnext_sinceを渡します。省略すると、ユーザーの永続的な確認済みカーソルから読み取ります。プロンプト例: "Stormの受信トレイをポーリングして、まだ確認していないものをすべて要約して。"
storm_ack_alerts永続的な確認済みカーソルを進め、今後の受信トレイポーリングで処理済みのアラートをスキップするようにします。カーソルはサーバー側にあり、MCPセッションをまたいで保持されます。
{
"up_to": { "type": "integer", "minimum": 0, "required": true, "example": 4530 }
}プロンプト例: "今までのStormアラートをすべて確認済みにして。"
ユーザー: エッジが300 bpsを超える2028年選挙のStormスプレッドをすべて見つけて、トップ3を教えて。
アシスタント: (
storm_list_spreadsをmin_edge_bps: 300, limit: 50で呼び出し、イベントスラグのプレフィックス2028_us_presidential_でレスポンスをフィルタリングし、トップ3に対してstorm_get_eventを呼び出して詳細を取得)現在オープンしている2028年選挙の最も広いスプレッド3つ、それぞれの両側の会場ペア、およびどの会場が安いレッグにあるかを返します。
ユーザー: Stormの受信トレイをポーリングして未確認のアラートを要約し、要約したものをすべて確認済みにして。
アシスタント: (
storm_get_alerts_inboxをsinceなしで呼び出し、カテゴリ別にアイテムを要約し、storm_ack_alertsをup_toに確認した最大のidを設定して呼び出す)未確認のアラート（スプレッドエッジのクロス、会場ステータスの変更、解決イベント）のカテゴリ別要約を返し、カーソルが進んだことを確認して、その後のポーリングで新しいアイテムのみが返されるようにします。
Storm APIは、サーバー側でAPIキーごとに毎秒10リクエストを強制しています。これを超えると、サーバーはRetry-After: 1と共にHTTP 429を返します。このMCPブリッジは自動的に再試行しません。エラーをツール結果のプレーンテキストコンテンツとしてLLMに表示し、モデルがバックオフ、再試行、または諦めるかを判断できるようにします。
エラーは以下の形式でLLMに返されます（ツール結果のテキストコンテンツ、isError: true）：
Storm API error (HTTP 429, rate_limited): too many requests Retry after 1000 ms.Storm API error (HTTP 403, edge_tier_required): edge_tier_requiredStorm API error (HTTP 401, invalid_credentials): invalid_credentialsネットワークレベルの障害（DNS、TCP、TLS、タイムアウト）は以下のように表示されます：
Storm API error (HTTP 0, transport): request timeout完全なHTTPステータス、Stormエラーコード、および人間が読めるメッセージが常に含まれているため、LLMはそれに基づいて行動できます。
git clone https://github.com/lsudduth/storm-mcp.git
cd storm-mcp
npm install
npm testAPIベースを上書きして、ローカルのStorm開発サーバーを指定します：
STORM_API_BASE=http://localhost:8080/api/v1 \
STORM_API_KEY=stk_dev_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
node src/index.mjsサーバーはstdio MCPで通信するため、任意のMCPテストハーネスを使用するか、JSON-RPCフレームを手動でパイプすることで直接操作できます。
テストにはNodeの組み込みテストランナーを使用しています。Jest、Vitest、トランスパイラは使用していません。
MIT — LICENSEを参照してください。
© 2026 XCH1TB, LLC dba Eyewall Markets.
Storm自体（Eyewall Marketsを運営し、このサーバーが公開するデータを生成する自律型AIエージェント）は、別の内部コードベースです。このパッケージは、Stormの公開読み取り専用APIサーフェスへのクライアント向けMCPブリッジに過ぎません。
本ソフトウェアおよびそれが公開するデータは、情報提供のみを目的として提供されています。StormまたはこのMCPサーバーによって返されるいかなる情報も、法的、財務的、税務的、または投資に関するアドバイスではありません。予測市場への参加は、現地の法律および会場独自の適格性規則に従う必要があります。特に、Polymarketは米国ではCFTC命令により制限されており、ほとんどの米国居住者は利用できません。会場の適格性はStormやこのサーバーではなく、ユーザー自身の責任です。 Stormは公開されている市場状態を集約するものであり、ユーザーに代わって取引を行うことはありません。
Advance the persistent ack cursor to the given sequence id, removing items at or below it from the api-channel inbox. Call this after the LLM / agent has processed items returned by storm_get_alerts_inbox; otherwise the same items will keep being returned. Sourced from Eyewall Markets / Storm. The cursor is server-side and survives across MCP sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| up_to | Yes | Ack all alerts with sequence id <= up_to. Use the highest id seen in storm_get_alerts_inbox. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the cursor is persistent, server-side, survives sessions, and that items are removed. This is sufficient for a mutation tool of this complexity.
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?
Three sentences cover action, usage, and persistence. Every sentence adds necessary information with 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?
For a simple acknowledgment tool with one parameter and no output schema, the description covers behavior, usage context, and parameter guidance. Minor gap: does not mention any potential side effects, but overall complete.
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?
Schema coverage is 100% and schema already describes the parameter. The description adds value by advising to use the highest id seen in storm_get_alerts_inbox, which is practical guidance beyond the raw schema definition.
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 ('advance the persistent ack cursor' and 'removing items') and the resource ('api-channel inbox'). It distinguishes itself from the sibling tool storm_get_alerts_inbox by focusing on acknowledgment and removal.
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 instructs to call this after processing items from storm_get_alerts_inbox to avoid duplicates. It provides clear context on when to use, though it does not elaborate on when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the subscriber's api-channel notification inbox for cross-venue price-difference and event notifications that haven't been ack'd yet. Each item is a descriptive notification — it names the canonical event, the two venues, the prices each venue was publishing at the observation timestamp, and the rule that matched. Sourced from Eyewall Markets / Storm. Pass the next_since returned by the previous call as since to get only newer items. After processing, call storm_ack_alerts to advance the persistent cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Only return alerts with sequence id strictly greater than this. Defaults to 0 (full inbox). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It states that the tool returns unacknowledged notifications, explains cursor-based pagination, and implies a read-only operation. It does not mention rate limits or other details, but the core behavioral traits are well covered.
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 concise at three sentences, each serving a distinct purpose: purpose explanation, content description, and usage pattern with next steps. No unnecessary words.
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's simplicity (one parameter, no output schema, no annotations) and the complexity of the polling pattern, the description is fully complete. It explains the tool, pagination, and the required follow-up action, leaving no critical gaps.
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 single parameter 'since' is fully described in the schema (100% coverage), and the description adds significant value by explaining its role in pagination and instructing how to use the 'next_since' value from previous calls. This goes beyond the schema's basic constraint.
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 specifies the tool's purpose: to poll the subscriber's api-channel notification inbox for unacknowledged cross-venue price-difference and event notifications. It names the verb 'poll', the resource 'inbox', and details the content of each notification, distinguishing it from the related 'storm_ack_alerts' tool.
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 provides explicit guidance on pagination (using 'next_since' from previous call as 'since') and directs users to call 'storm_ack_alerts' after processing to advance the cursor. While it doesn't explicitly state when not to use the tool, the context is clear and the alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single canonical event by its Storm slug, including the full set of cross-venue markets attached to that event and each venue's currently published price. Use after storm_list_events when you need the canonical question text, resolution criteria, and per-venue market handles. Sourced from Eyewall Markets / Storm; describes the published-price observation, not a buy or sell recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Storm event slug, e.g. 'will-fed-cut-rates-by-2026-q3'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description implies read-only fetch and adds context that data is observational, not advisory. However, it does not disclose any side effects, auth needs, or limitations beyond that.
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?
Two succinct sentences: first defines action and scope, second provides usage guidance and disclaimer. No redundant text; all information is relevant and front-loaded.
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 simple input and lack of output schema, the description covers core purpose, usage context, and key outputs (question text, resolution criteria, market handles). Missing exact response structure but acceptable for this complexity.
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?
Schema coverage is 100% with a well-described parameter. The description does not add significant meaning beyond the schema, so a baseline of 3 is appropriate.
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 fetches a single canonical event by slug, including markets and prices. It distinguishes from sibling 'storm_list_events' by specifying it's for detailed event data after listing.
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?
Explicitly suggests using after storm_list_events and states the need for canonical question text, resolution criteria, and market handles. Includes disclaimer that it's observation, not a recommendation, but does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the canonical Storm view of a single market on a specific venue, including the venue's currently published bid/ask, volume, and the canonical event it's joined to. Use when you have a venue + the venue's native market id (e.g. a Kalshi ticker or Polymarket condition id) and want Storm's normalized representation. Sourced from Eyewall Markets / Storm; describes published price snapshots from the venue's public read endpoints, not a recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | Yes | Venue slug, e.g. 'kalshi' or 'polymarket'. See storm_list_venues. | |
| external_id | Yes | The venue's native market identifier (Kalshi ticker, Polymarket condition id, etc.). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description states it fetches from public read endpoints and is not a recommendation, indicating a safe read operation. Could mention if real-time or cached, but still good.
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?
Three sentences, front-loaded with purpose, no unnecessary words. Efficiently conveys all essential information.
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 no output schema, description adequately covers return fields (bid/ask, volume, canonical event) and notes it's not a recommendation. Sufficient for simple two-parameter tool.
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?
Schema description coverage is 100% with clear explanations for venue and external_id. The description reinforces the usage but doesn't add significant new constraints or examples beyond the schema.
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 fetches the canonical Storm view of a single market, including bid/ask, volume, and associated event. It distinguishes itself from sibling tools like storm_list_events and storm_get_event.
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?
Explicitly says 'Use when you have a venue + the venue's native market id', providing clear conditions. Also references storm_list_venues for obtaining the slug, guiding the agent on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List canonical prediction-market events (questions/topics) tracked by Eyewall Markets / Storm across the public venues it covers (Kalshi, Polymarket, Manifold, ForecastEx, and others). Use this to discover what events exist before drilling into a specific event with storm_get_event. Supports filtering by category (e.g. 'politics', 'economics') and status (e.g. 'open', 'resolved'), and is cursor-paginated. Read-only market reference data; describes the event ontology, not a recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (1-100). Default server-side is typically 25. | |
| cursor | No | Opaque pagination cursor returned in next_cursor from a previous call. | |
| category | No | Filter to a single category slug, e.g. 'politics'. | |
| status | No | Filter by event status, e.g. 'open' or 'resolved'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description declares 'Read-only market reference data' and mentions cursor-pagination. Lacks details on rate limits or auth, but sufficient for basic safety.
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?
Four sentences, front-loaded with purpose, each sentence adds value (use case, filtering, pagination, read-only nature). No fluff.
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?
No output schema, but description mentions cursor-paginated results. Could specify return fields, but adequate for discovering events before drilling down.
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?
Schema coverage is 100%, so baseline is 3. Description adds examples for category and status, but no deeper semantics beyond schema descriptions.
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?
Description clearly states the tool lists prediction-market events with specific venues (Kalshi, Polymarket, etc.), uses the verb 'list' and resource 'events', and distinguishes from sibling tool storm_get_event.
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?
Explicitly says 'Use this to discover what events exist before drilling into a specific event with storm_get_event', providing a clear use case and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent cross-venue published-price observations — pairs of markets on different venues that are publishing different prices for the same canonical outcome. Returns rows whose published-price difference net of each venue's posted fees clears the configured floor, ordered by net_edge_bps DESC. Sourced from Eyewall Markets / Storm. Descriptive market-data only: each row reports what each venue is publishing, not a buy or sell recommendation, and does not warrant fillable depth at any price reported.
| Name | Required | Description | Default |
|---|---|---|---|
| min_edge_bps | No | Minimum published-price difference net of venue fees, in basis points (1 bp = 0.01%). E.g. 50 returns only rows whose net_edge_bps is >= 50. Defaults to the server-side floor. | |
| limit | No | Page size (1-100). | |
| cursor | No | Opaque pagination cursor returned in next_cursor from a previous call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: lists recent observations, filters by configured floor, orders by net_edge_bps descending, and emphasizes that data is descriptive and non-actionable. This covers safety and operational expectations.
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 that front-load the primary purpose in the first sentence and add behavioral caveats in the second. No extraneous words or redundancy.
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's moderate complexity (3 parameters, no output schema), the description covers key aspects: what is returned, ordering, and behavioral constraints. However, it does not mention pagination handling (cursor/next_cursor) explicitly, leaving that to the 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?
Schema coverage is 100%, but the description adds value by explaining min_edge_bps with an example and mentioning server-side floor default. However, for 'limit' and 'cursor', no additional semantic context is provided beyond the schema.
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 verb 'List' and the resource 'cross-venue published-price observations', and distinguishes this tool from siblings like storm_list_events and storm_list_venues by specifying its unique function of identifying pricing disparities between venues.
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 states the tool's purpose and clarifies that it provides descriptive market data only, not buy/sell recommendations or depth warranties. However, it does not explicitly mention when not to use this tool or provide direct alternatives beyond sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all public prediction-market venues covered by Eyewall Markets / Storm, with their slugs, display names, regulatory posture (CFTC-registered DCM, offshore, etc.), posted fee schedules, capability flags (orderbook / AMM / parimutuel), and current ingestion status. Call this first when you need the venue slug to pass to storm_get_market. Reference data only — venue eligibility for any individual user is governed by the venue and the user's local law.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool is reference data only and lists the kind of data returned, which is sufficient for a read-only tool with no side effects.
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?
Two sentences, front-loaded with the action and output, every sentence adds value without redundancy.
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 no output schema, the description thoroughly enumerates return fields (slugs, display names, regulatory posture, etc.) and clarifies it's reference data, making it complete for agent use.
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 zero parameters, so baseline is 4. The description adds meaning by explaining what the output contains, compensating for the empty schema.
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 ('List all public prediction-market venues') and specifies the output fields, distinguishing it from siblings like storm_get_market which needs a slug.
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?
Explicitly instructs 'Call this first when you need the venue slug to pass to storm_get_market', providing clear when-to-use guidance and noting that eligibility is governed by venue and local law.
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.1.2storm_ack_alertsstorm_get_alerts_inboxstorm_get_eventstorm_get_marketstorm_list_eventsstorm_list_spreadsstorm_list_venuesScored across 7 tools
Each tool targets a distinct action or resource: acking alerts, polling inbox, fetching events/markets, listing events/spreads/venues. No two tools have overlapping purposes, and descriptions clearly differentiate them.
All tools follow a consistent 'storm_verb_noun' pattern in snake_case, with verbs like ack, get, list. This makes it easy for an agent to infer functionality from names.
7 tools is a well-scoped set for a prediction market data server. Each tool serves a necessary function without unnecessary duplication or gaps, covering discovery, detailed queries, and notification management.
The tool set covers the full lifecycle: discovering events (list), drilling into details (get), accessing markets (get), monitoring spreads and alerts, acknowledging alerts, and listing venues. No obvious missing operations for the stated purpose.
Hosted MCP for Kalshi prediction markets: search, odds, order books, settlement rules, and trading.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server exposing the Backtest360 engine API as tools for AI agents.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
