Skip to main content
Glama
enesjakozh
ferdousbhai

WSB Analyst MCP Server

by ferdousbhai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WSB 분석가 MCP 서버

대장간 배지

Claude 또는 다른 LLM 클라이언트로 분석할 수 있는 실시간 WallStreetBets 데이터를 제공하는 MCP(Model Context Protocol) 서버입니다.

특징

  • WallStreetBets 게시물 가져오기 : 점수, 댓글 수, 콘텐츠 유형별로 게시물 필터링

  • 자세한 게시물 분석 : 게시물에서 댓글, 링크 및 메타데이터 추출

  • 외부 링크 모음 : WSB 토론에서 공유되는 링크를 모으세요

  • 분석 템플릿 : 시장 분석을 위한 즉시 사용 가능한 프롬프트 템플릿

  • 진행 상황 보고 : 데이터 수집 중 실시간 진행 상황 업데이트

  • MCP 통합 : Claude Desktop 및 기타 MCP 클라이언트와의 원활한 통합

Related MCP server: MCP Reddit Server

요구 사항

  • Python 3.12 이상

  • Reddit API 자격 증명

  • Claude Desktop 또는 다른 MCP 클라이언트

설치

Smithery를 통해 설치

Smithery 를 통해 Claude Desktop용 WSB Analyst를 자동으로 설치하려면:

지엑스피1

이 저장소를 복제하거나 소스 파일을 다운로드하세요.

git clone https://github.com/ferdousbhai/wsb-analyst-mcp
cd wsb-analyst-mcp

가상 환경을 만들고 종속성을 설치합니다.

# Using uv (recommended)
uv sync

Reddit API 자격 증명 설정

이 서버를 사용하려면 API 자격 증명을 얻기 위해 Reddit 애플리케이션을 만들어야 합니다.

  1. Reddit 계정에 로그인하세요

  2. https://www.reddit.com/prefs/apps 로 이동합니다.

  3. 아래로 스크롤하여 "다른 앱 만들기..." 또는 "앱 만들기..."를 클릭하세요.

  4. 다음 세부 정보를 입력하세요.

    • 이름 : WSB 분석가 MCP(또는 원하는 이름)

    • 앱 유형 : "스크립트" 선택

    • 설명 : 귀하의 신청서에 대한 선택적 설명

    • url 정보 : 비워두어도 됩니다

    • 리디렉트 uri : http://localhost:8000 사용하세요(OAuth를 사용하지 않으므로 유효한 URL이면 무엇이든 가능합니다)

  5. "앱 만들기"를 클릭하세요

  6. 생성 후 다음 사항을 기록해 두십시오.

    • client_id : 앱 이름 아래의 문자열("개인용 스크립트" 바로 아래에 나타남)

    • client_secret : "secret"이라는 라벨이 붙은 문자열

Claude Desktop 구성

Claude Desktop의 구성 파일을 엽니다.

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

다음 구성을 추가합니다(필요에 따라 경로를 조정합니다):

{
  "mcpServers": {
    "wsb-analyst": {
      "command": "uvx",
      "args": [
        "run",
        "wsb-analyst"
      ],
      "env": {
        "REDDIT_CLIENT_ID": "your_client_id_here",
        "REDDIT_CLIENT_SECRET": "your_client_secret_here"
      }
    }
  }
}

Claude Desktop을 다시 시작하세요

Claude Desktop과 함께 사용

구성이 완료되면 Claude를 통해 WSB Analyst 서버와 상호 작용할 수 있습니다.

  1. 클로드 데스크톱 열기

  2. 메시지 입력 상자의 오른쪽 하단에 망치 아이콘이 표시됩니다.

  3. 사용 가능한 도구를 보려면 망치를 클릭하세요.

  4. 슬래시 명령어(예: /analyze_wsb_market )를 통해 프롬프트 템플릿에 액세스합니다.

예시 쿼리:

  • "오늘 WallStreetBets에서 가장 인기 있는 주식은 무엇인가요?"

  • "최근 WallStreetBets 게시물을 분석하고 잠재적인 시장 기회에 대해 알려주세요"

  • "WSB 사용자들은 AMD 주식에 관해 어떤 외부 리소스를 공유하고 있나요?"

사용 가능한 도구

find_top_posts

기준에 따라 WSB 게시물을 가져와 필터링합니다.

매개변수:

  • min_score (기본값: 100): 필요한 최소 점수(추천)

  • min_comments (기본값: 10): 필요한 최소 댓글 수

  • limit (기본값: 10): 반환할 최대 게시물 수

  • excluded_flairs (기본값: ["Meme", "Shitpost", "Gain", "Loss"] ): 제외할 게시물 플레어 목록입니다.

fetch_post_details

상위 댓글을 포함하여 특정 WSB 게시물에 대한 자세한 정보를 가져옵니다.

매개변수:

  • post_id : Reddit 게시물 ID

fetch_batch_post_details

여러 게시물에 대한 세부 정보를 효율적으로 가져옵니다.

fetch_detailed_wsb_posts

WSB 게시물을 가져와 필터링한 다음, 각 게시물에 대한 상위 댓글과 링크를 포함한 자세한 정보를 얻으세요.

get_external_links

인기 게시물의 모든 외부 링크를 수집합니다.

get_trending_tickers

최근 WSB 인기 게시물에서 자주 언급되거나 논의된 주식 티커 목록을 식별하여 반환합니다.

프롬프트 템플릿

/analyze_wsb_market

LLM이 사용 가능한 도구( fetch_detailed_wsb_posts , get_external_links )를 사용하여 포괄적인 시장 분석을 수행할 수 있도록 안내하는 템플릿 프롬프트를 제공합니다. LLM에게 분석의 구조와 초점을 알려줍니다.

/find_market_movers

특정 주식이나 전체 시장의 움직임을 파악하는 데 초점을 맞춘 프롬프트를 생성합니다. 이 프롬프트는 LLM이 find_top_posts , fetch_post_details 또는 fetch_batch_post_details 와 같은 도구를 사용하도록 안내합니다.

Firecrawl MCP 서버와 통합

특히 WSB 게시물에서 발견된 외부 링크를 처리할 때 향상된 분석 기능을 위해 이 서버를 Firecrawl MCP 서버 와 통합할 수 있습니다. 이를 통해 LLM 에이전트는 WSB에서 공유된 링크를 식별할 뿐만 아니라 링크된 페이지의 콘텐츠를 스크래핑하고 분석할 수 있습니다.

특허

MIT

Available Tools

6 tools
fetch_batch_post_detailsC
Fetch details for multiple posts efficiently.

Args:
    post_ids: List of Reddit post IDs

Returns:
    Dictionary with details for all requested posts
ParametersJSON Schema
NameRequiredDescriptionDefault
post_idsYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but provides minimal behavioral context. It states it fetches details efficiently but doesn't disclose rate limits, authentication needs, error handling, or what happens if some post IDs are invalid. This is inadequate for a tool with no annotation coverage.

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?

The description is appropriately brief with three sentences that are front-loaded (purpose first, then args, then returns). No wasted words, though the structure could be slightly improved by integrating usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on return format (beyond 'dictionary'), error cases, performance characteristics, and differentiation from siblings, making it insufficient for reliable tool selection.

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 description coverage is 0%, but the description adds basic meaning by specifying 'post_ids' as 'List of Reddit post IDs'. However, it doesn't clarify format constraints, size limits, or provide examples, leaving significant gaps in parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('fetch details') and resource ('multiple posts'), and mentions efficiency. However, it doesn't distinguish this batch operation from the sibling 'fetch_post_details' tool, which likely fetches single posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives like 'fetch_post_details' or 'fetch_detailed_wsb_posts'. The description mentions efficiency for multiple posts but doesn't specify thresholds or exclusions.

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

fetch_detailed_wsb_postsB
Fetch and filter WSB posts, then get detailed information including top comments and links for each.

Args:
    min_score: Minimum score (upvotes) required
    min_comments: Minimum number of comments required
    limit: Maximum number of posts to return
    excluded_flairs: List of post flairs to exclude. Defaults to ["Meme", "Shitpost", "Gain", "Loss"].

Returns:
    A dictionary with detailed data for the filtered posts.
ParametersJSON Schema
NameRequiredDescriptionDefault
min_scoreNo
min_commentsNo
limitNo
excluded_flairsNo

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions fetching, filtering, and returning detailed data but lacks critical information: whether this is a read-only operation, potential rate limits, authentication requirements, data freshness, error handling, or what 'detailed information' specifically includes beyond comments and links. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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?

The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by an 'Args' section with parameter explanations and a 'Returns' section. Each sentence adds value without redundancy. However, the 'Returns' section is somewhat vague ('A dictionary with detailed data'), which slightly reduces efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description provides adequate basics: purpose and parameter semantics. However, it lacks details on behavioral traits (e.g., read-only status, rate limits), output structure beyond 'dictionary', and differentiation from sibling tools. For a tool with 4 parameters and no structured metadata, this is minimally viable but leaves gaps in usage context.

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 description coverage is 0%, so the description must compensate. It provides clear semantics for all four parameters: 'min_score' as minimum upvotes, 'min_comments' as minimum comment count, 'limit' as maximum posts to return, and 'excluded_flairs' with default values and purpose. This adds meaningful context beyond the bare schema, though it doesn't explain parameter interactions or validation rules.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Fetch and filter WSB posts, then get detailed information including top comments and links for each.' This specifies the verb (fetch and filter), resource (WSB posts), and scope (detailed information with comments and links). However, it doesn't explicitly differentiate from sibling tools like 'fetch_batch_post_details' or 'fetch_post_details' beyond mentioning 'detailed information'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'find_top_posts' and 'get_top_trending_tickers' available, there's no indication of how this tool differs in use cases, prerequisites, or appropriate contexts. The description only explains what the tool does, not when to choose it.

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

fetch_post_detailsB
Fetch detailed information about a specific WSB post including top comments. Caches results for 5 minutes.

Args:
    post_id: Reddit post ID

Returns:
    Detailed post data including comments and extracted links
ParametersJSON Schema
NameRequiredDescriptionDefault
post_idYes

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses caching behavior ('Caches results for 5 minutes'), which is useful context beyond basic functionality. However, it lacks details on error handling, rate limits, authentication needs, or what happens if the post_id is invalid.

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?

The description is appropriately sized and front-loaded, with the core purpose stated first, followed by caching info and parameter/return details. Every sentence adds value, though the structure could be slightly improved by integrating caching into the main sentence for better flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description does a decent job by explaining the parameter and return value in general terms. However, for a tool with caching and potential complexity in returns, it should provide more detail on output structure, error cases, or limitations to be fully complete.

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?

With 0% schema description coverage and only one parameter, the description adds significant value by explaining that 'post_id' is a 'Reddit post ID', clarifying its format and source. This compensates well for the lack of schema documentation, though it could specify format constraints like length or pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Fetch') and resource ('detailed information about a specific WSB post including top comments'), making the purpose explicit. However, it doesn't distinguish this tool from its siblings like 'fetch_detailed_wsb_posts' or 'fetch_batch_post_details', which likely have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'fetch_batch_post_details' and 'fetch_detailed_wsb_posts', there's no indication of differences in scope, filtering, or use cases, leaving the agent without contextual direction.

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

find_top_postsB
Fetch and filter WSB posts based on criteria. Caches results for 5 minutes.

Args:
    min_score: Minimum score (upvotes) required
    min_comments: Minimum number of comments required
    limit: Maximum number of posts to return
    excluded_flairs: List of post flairs to exclude. Defaults to ["Meme", "Shitpost", "Gain", "Loss"].

Returns:
    A dictionary with filtered posts data
ParametersJSON Schema
NameRequiredDescriptionDefault
min_scoreNo
min_commentsNo
limitNo
excluded_flairsNo

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully mentions the 5-minute caching behavior, which is valuable operational context. However, it doesn't address other important behavioral aspects like error handling, rate limits, authentication requirements, or what happens when no posts match criteria.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement upfront, followed by well-organized parameter explanations in an 'Args' section and a 'Returns' section. Every sentence adds value with no wasted words, making it easy to scan and understand.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no annotations, and no output schema, the description does an adequate job explaining the parameters and caching behavior. However, it lacks information about return format details (beyond 'dictionary with filtered posts data'), error conditions, and how it differs from sibling tools, leaving some gaps in understanding.

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?

The description provides clear semantic meaning for all 4 parameters beyond what the schema offers (which has 0% description coverage). It explains what 'min_score' and 'min_comments' represent, clarifies that 'limit' controls maximum returns, and provides the default excluded flairs with examples. This compensates well for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch and filter WSB posts') and the resource ('WSB posts'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'fetch_detailed_wsb_posts' or 'get_top_trending_tickers', which appear to operate on similar data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings. While it mentions caching behavior, it doesn't specify scenarios where this filtering approach is preferred over alternatives like 'fetch_detailed_wsb_posts' or 'get_top_trending_tickers'.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updates
    • First observedfetch_batch_post_details
    • First observedfetch_detailed_wsb_posts
    • First observedfetch_post_details
    • First observedfind_top_posts
    • First observedget_external_links
    • First observedget_top_trending_tickers
Deploy Server
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

TDQS

B3.2/5.0

Scored across 6 tools

Disambiguation2/5

There is significant overlap between tools, particularly fetch_detailed_wsb_posts and find_top_posts which both fetch and filter WSB posts with identical parameters, causing confusion. Additionally, fetch_batch_post_details and fetch_post_details both retrieve post details, though one handles multiple IDs and the other a single ID, which could be consolidated into a single tool with an optional list parameter.

Naming Consistency4/5

Tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., fetch_post_details, get_external_links), making them readable and predictable. However, the naming is not perfectly consistent as some tools use 'fetch' while others use 'get' for similar actions, which is a minor deviation.

Tool Count4/5

With 6 tools, the count is reasonable for a server focused on WSB analysis, covering post fetching, filtering, link extraction, and ticker trending. It is slightly under-scoped as it could benefit from additional tools for deeper analysis or data manipulation, but the core functionality is adequately represented.

Completeness3/5

The toolset covers key aspects like fetching posts, extracting links, and getting trending tickers, but there are notable gaps. For example, there is no tool for updating or deleting data, and advanced features such as sentiment analysis or historical data tracking are missing, which limits comprehensive analysis workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • StockFlow MCP Server

    twolven
    A
    license
    B
    quality
    B
    maintenance
    A Model Context Protocol server providing real-time stock data and options analysis through Yahoo Finance, enabling LLMs to access market data, analyze stocks, and evaluate options strategies.
    3
    27
    MIT

  • MCP Reddit Server

    wllcnm
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants like Claude to browse and analyze Reddit content, including searching subreddits, retrieving post details with comments, and viewing trending posts.
    10
    MIT

  • Schwab Model Context Protocol

    jkoelker
    A
    license
    Not graded
    quality
    A
    maintenance
    A server that implements the Model Context Protocol for Schwab API, allowing access to account information, positions, stock quotes, and order/transaction history designed for integration with Large Language Models.
    62
    MIT

  • sellthenews-mcp

    swl007007
    F
    license
    B
    quality
    F
    maintenance
    A read-only MCP server that provides access to financial news, Wall Street Bets sentiment analysis, and detailed options data from sellthenews.org. It enables LLMs to retrieve real-time news feeds, search historical data, and analyze options chains or Greek exposure for specific tickers.
    5
    -

Appeared in Searches