WSB Analyst MCP Server
Servidor MCP de WSB Analyst
Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona datos de WallStreetBets en tiempo real para su análisis con Claude u otros clientes LLM.
Características
Obtener publicaciones de WallStreetBets : filtrar publicaciones por puntuación, cantidad de comentarios y tipo de contenido
Análisis detallado de publicaciones : extraiga comentarios, enlaces y metadatos de las publicaciones
Recopilación de enlaces externos : recopila enlaces que se comparten en las discusiones de WSB
Plantillas de análisis : Plantillas de indicaciones listas para usar para el análisis de mercado
Informes de progreso : actualizaciones de progreso en tiempo real durante la recopilación de datos
Integración con MCP : integración perfecta con Claude Desktop y otros clientes de MCP
Related MCP server: MCP Reddit Server
Requisitos
Python 3.12 o superior
Credenciales de la API de Reddit
Claude Desktop u otro cliente MCP
Instalación
Instalación mediante herrería
Para instalar WSB Analyst para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @ferdousbhai/wsb-analyst-mcp --client claudeClone este repositorio o descargue los archivos fuente:
git clone https://github.com/ferdousbhai/wsb-analyst-mcp
cd wsb-analyst-mcpCree un entorno virtual e instale dependencias:
# Using uv (recommended)
uv syncConfiguración de las credenciales de la API de Reddit
Para utilizar este servidor, debe crear una aplicación Reddit para obtener las credenciales de API:
Inicia sesión en tu cuenta de Reddit
Desplácese hacia abajo y haga clic en "crear otra aplicación..." o "crear una aplicación..."
Complete los siguientes datos:
Nombre : Analista WSB MCP (o cualquier nombre que prefiera)
Tipo de aplicación : seleccione "script"
Descripción : Descripción opcional de su aplicación.
Acerca de la URL : se puede dejar en blanco.
URI de redireccionamiento : use
http://localhost:8000(cualquier URL válida funciona ya que no usamos OAuth)
Haga clic en "crear aplicación"
Después de la creación, anote:
client_id : La cadena debajo del nombre de la aplicación (aparece justo debajo de "script de uso personal")
client_secret : La cadena etiquetada como "secreto"
Configuración para Claude Desktop
Abra el archivo de configuración de Claude Desktop:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonVentanas:
%APPDATA%\Claude\claude_desktop_config.json
Agregue la siguiente configuración (ajuste las rutas según sea necesario):
{
"mcpServers": {
"wsb-analyst": {
"command": "uvx",
"args": [
"run",
"wsb-analyst"
],
"env": {
"REDDIT_CLIENT_ID": "your_client_id_here",
"REDDIT_CLIENT_SECRET": "your_client_secret_here"
}
}
}
}Reiniciar Claude Desktop
Uso con Claude Desktop
Una vez configurado, puedes interactuar con el servidor WSB Analyst a través de Claude:
Abra Claude Desktop
Debería ver un icono de martillo en la esquina inferior derecha del cuadro de entrada del mensaje.
Haga clic en el martillo para ver las herramientas disponibles.
Acceda a las plantillas de solicitud mediante comandos de barra (por ejemplo,
/analyze_wsb_market)
Consultas de ejemplo:
"¿Cuáles son las acciones con mayor tendencia hoy en WallStreetBets?"
Analice las publicaciones recientes de WallStreetBets y cuénteme sobre posibles oportunidades de mercado.
"¿Qué recursos externos comparten los usuarios de WSB sobre las acciones de AMD?"
Herramientas disponibles
find_top_posts
Obtener y filtrar publicaciones de WSB según criterios.
Parámetros:
min_score(predeterminado: 100): Puntuación mínima (votos positivos) requeridamin_comments(predeterminado: 10): Número mínimo de comentarios requeridoslimit(predeterminado: 10): número máximo de publicaciones a devolverexcluded_flairs(predeterminado:["Meme", "Shitpost", "Gain", "Loss"]): Lista de etiquetas de publicaciones para excluir.
fetch_post_details
Obtenga información detallada sobre una publicación específica de WSB, incluidos los comentarios principales.
Parámetros:
post_id: ID de publicación de Reddit
fetch_batch_post_details
Obtiene detalles de múltiples publicaciones de manera eficiente.
fetch_detailed_wsb_posts
Obtenga y filtre las publicaciones de WSB, luego obtenga información detallada, incluidos los principales comentarios y enlaces para cada una.
get_external_links
Recopila todos los enlaces externos de las publicaciones principales.
get_trending_tickers
Identifica y devuelve una lista de cotizaciones bursátiles mencionadas o discutidas con frecuencia en publicaciones recientes de WSB.
Plantillas de indicaciones
/analyze_wsb_market
Proporciona una plantilla de instrucciones para guiar al estudiante de maestría en la realización de un análisis de mercado exhaustivo utilizando las herramientas disponibles ( fetch_detailed_wsb_posts , get_external_links ). Indica al estudiante la estructura y el enfoque del análisis.
/find_market_movers
Crea una indicación enfocada en los factores que impulsan acciones específicas o el mercado en general. Esta indicación guía al LLM para usar herramientas como find_top_posts , fetch_post_details o fetch_batch_post_details .
Integración con el servidor MCP de Firecrawl
Para mejorar las capacidades de análisis, especialmente al gestionar enlaces externos en publicaciones de WSB, puede integrar este servidor con el servidor Firecrawl MCP . Esto permite a su agente LLM no solo identificar enlaces compartidos en WSB, sino también extraer y analizar el contenido de esas páginas enlazadas.
Licencia
Instituto Tecnológico de Massachusetts (MIT)
Available Tools
6 toolsfetch_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
| Name | Required | Description | Default |
|---|---|---|---|
| post_ids | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| min_score | No | ||
| min_comments | No | ||
| limit | No | ||
| excluded_flairs | No |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| min_score | No | ||
| min_comments | No | ||
| limit | No | ||
| excluded_flairs | No |
TDQS
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.
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.
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.
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.
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.
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.
get_external_linksB
Get all external links from top WSB posts.
Args:
min_score: Minimum score (upvotes) required
min_comments: Minimum number of comments required
limit: Maximum number of posts to scan
Returns:
Dictionary with all unique external links found
| Name | Required | Description | Default |
|---|---|---|---|
| min_score | No | ||
| min_comments | No | ||
| limit | No |
TDQS
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 that the tool scans posts and returns unique external links, but it lacks details on rate limits, authentication needs, error handling, or what constitutes 'top WSB posts' (e.g., time frame or sorting criteria). This leaves significant gaps in understanding the tool's behavior.
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 highly concise and well-structured. It starts with a clear purpose statement, followed by bullet-point-like sections for 'Args' and 'Returns,' each with brief, direct explanations. Every sentence earns its place, and there is no wasted verbiage, making it easy to scan and understand quickly.
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 annotations, no output schema), the description is partially complete. It covers the purpose and parameters well but lacks behavioral details and usage guidelines. Without an output schema, it should ideally explain the return format more thoroughly (e.g., structure of the dictionary), but it does state the return type, which helps somewhat.
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 meaningful context beyond the input schema, which has 0% description coverage. It explains that 'min_score' refers to 'Minimum score (upvotes) required,' 'min_comments' is 'Minimum number of comments required,' and 'limit' is 'Maximum number of posts to scan.' This clarifies the purpose of each parameter, compensating 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all external links from top WSB posts.' It specifies the verb ('Get'), resource ('external links'), and scope ('from top WSB posts'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'fetch_detailed_wsb_posts' or 'find_top_posts,' which might also involve post retrieval, so it misses full sibling distinction.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'fetch_batch_post_details' or 'get_top_trending_tickers.' Without this context, users might struggle to choose the right tool for their needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_top_trending_tickersA
Fetch top trending stock tickers from ApeWisdom, filtered by valid NASDAQ symbols.
Args:
num_stocks: Number of top stocks to consider based on upvotes and mentions. Defaults to 20.
filter: ApeWisdom filter category (e.g., 'wallstreetbets', 'all'). Defaults to 'wallstreetbets'.
Returns:
A list of valid, trending tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| num_stocks | No | ||
| filter | No | wallstreetbets |
TDQS
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 mentions fetching and filtering but lacks details on rate limits, authentication needs, error handling, or data freshness. For a tool interacting with external data sources, this omission leaves significant behavioral aspects unclear to the agent.
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 efficiently structured with a clear purpose statement followed by labeled sections for Args and Returns. Each sentence adds value without redundancy, making it easy to parse and front-loaded with the core functionality, demonstrating excellent conciseness and organization.
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 tool with 2 parameters, no annotations, and no output schema, the description covers purpose and parameters well but lacks behavioral context and usage guidelines. It's adequate for basic understanding but incomplete given the external data source complexity, as it doesn't address reliability or integration aspects that an agent might need.
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?
Given 0% schema description coverage, the description fully compensates by explaining both parameters clearly. It defines 'num_stocks' as 'Number of top stocks to consider based on upvotes and mentions' and 'filter' with examples like 'wallstreetbets' and 'all', adding essential context beyond the bare schema, which only lists types and defaults.
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 specific action ('Fetch top trending stock tickers'), source ('from ApeWisdom'), and key constraint ('filtered by valid NASDAQ symbols'). It distinguishes itself from sibling tools by focusing on ticker retrieval rather than post details or external links, making the purpose immediately understandable and distinct.
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 no guidance on when to use this tool versus alternatives. While it mentions filtering by NASDAQ symbols, it doesn't specify scenarios where this tool is preferred over sibling tools like 'find_top_posts' or 'fetch_detailed_wsb_posts', leaving the agent without context for selection among available options.
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.
6 tool updates
- First observed
fetch_batch_post_details - First observed
fetch_detailed_wsb_posts - First observed
fetch_post_details - First observed
find_top_posts - First observed
get_external_links - First observed
get_top_trending_tickers
TDQS
Scored across 6 tools
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.
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.
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.
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
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
Real-time US stock market news, r/wallstreetbets sentiment, options GEX & max pain, daily recaps
141
Related MCP Servers
- AlicenseBqualityBmaintenanceA 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.327MIT
- AlicenseNot gradedqualityDmaintenanceA 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.10MIT
- AlicenseNot gradedqualityAmaintenanceA 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.62MIT
- FlicenseBqualityFmaintenanceA 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
- A tool for analyzing Indian stock data for investment decisions using LLMs and news insights
- Major Historical and Contemporary Events in Hong Kong
- A search for information on 'Deep Insight'
- A guide to Business Intelligence, Passive Income, and Algorithm Interpreters for Self-Learning and Side-Hustles
- Information about 雪球 (Xueqiu or Snowball)