Storm 교차 거래소 예측 시장 인텔리전스 API를 모든 Model Context Protocol 클라이언트에 노출하는 MCP 서버입니다.
Storm은 Polymarket, Kalshi, Manifold, Futuur, Betfair, ForecastEx 등을 아우르는 교차 거래소 예측 시장 인텔리전스 서비스인 Eyewall Markets을 운영하는 자율 AI 에이전트입니다. 이 패키지는 LLM 클라이언트(Claude Desktop, Claude Code, Cursor, Zed 및 기타 MCP 인식 호스트)가 Storm의 표준 이벤트, 교차 거래소 스프레드, 거래소 카탈로그 및 사용자별 알림 받은 편지함을 네이티브 도구 호출로 읽을 수 있게 해주는 가벼운 stdio MCP 브리지입니다.
이 서버는 이미 Storm 구독을 보유하고 있으며 자신의 LLM 작업 공간에서 Storm이 보는 내용을 확인하고자 하는 분석가, 트레이더 및 에이전트 빌더를 대상으로 합니다.
Storm API는 Edge 티어 구독자(월 $499)에게만 제공됩니다. https://eyewallmarkets.com/account에서
api_key를 생성하세요. 하위 티어는 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순 이익(수수료 제외)이 기준치를 넘는 최근 교차 거래소 스프레드 목록을 가져옵니다. 이익(edge) 내림차순으로 정렬됩니다.
{
"min_edge_bps": { "type": "integer", "default": 100 },
"limit": { "type": "integer", "default": 50, "max": 200 },
"cursor": { "type": "string", "optional": true }
}예시 프롬프트: "지금 당장 최소 250 bps 이상의 이익이 있는 상위 10개 Storm 스프레드를 보여줘."
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개를 알려줘.
어시스턴트: (
min_edge_bps: 300, limit: 50으로storm_list_spreads를 호출하고, 이벤트 슬러그 접두사2028_us_presidential_로 응답을 필터링한 다음, 상위 3개에 대해storm_get_event를 호출하여 정보를 보강함)현재 열려 있는 가장 넓은 2028년 선거 스프레드 3개, 각 측의 거래소 쌍, 그리고 어느 거래소가 저렴한 레그(leg)에 있는지 반환합니다.
사용자: 내 Storm 받은 편지함을 폴링하고 확인되지 않은 알림을 요약한 다음, 요약한 모든 내용을 확인 처리해 줘.
어시스턴트: (
since없이storm_get_alerts_inbox를 호출하고, 항목을 카테고리별로 요약한 다음,up_to를 확인한 가장 큰id로 설정하여storm_ack_alerts를 호출함)확인되지 않은 알림(스프레드 이익 교차, 거래소 상태 변경, 해결 이벤트)의 카테고리별 요약을 반환하고 커서 진행을 확인하여 이후 폴링에서 새로운 항목만 반환되도록 합니다.
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.
Eyewall Markets를 운영하고 이 서버가 노출하는 데이터를 생성하는 자율 AI 에이전트인 Storm 자체는 별도의 내부 코드베이스입니다. 이 패키지는 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
