HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics
Server Quality Checklist
Latest release: v0.3.1
- Disambiguation5/5
Each tool targets a distinct aspect of stock/options analysis: aggregated analysis, chart generation, research reports, AI prediction, backtest curves, IV metrics, Monte Carlo simulation, options pressure, and pre-trade risk scan. Even the two comprehensive tools (analyze_stock and generate_stock_research_report) are clearly differentiated by output format (JSON vs. markdown) and recommended use cases.
Naming Consistency5/5All 9 tools follow a consistent verb_noun pattern in snake_case: analyze_stock, generate_stock_images, generate_stock_research_report, get_ai_prediction, get_equity_curves, get_iv_radar, get_monte_carlo, get_option_pressure, get_pretrade_risk_scan. The verbs are appropriate and the naming is uniform.
Tool Count5/5With 9 tools, the server is well-scoped for quantitative stock and options analytics. The tool count covers an aggregate analysis, specific data dimensions (AI, IV, Monte Carlo, options pressure, backtest, risk scan), and presentation (charts, reports) without unnecessary overlap or bloat.
Completeness5/5The tool set provides comprehensive coverage for stock analysis and options analytics: directional prediction, volatility analysis, options positioning, Monte Carlo simulations, strategy backtests, risk scanning with portfolio context, and visualizations. There are no obvious gaps for the stated domain.
Average 4.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 93 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 26 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- 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 explains the return structure and key metrics, which partially addresses transparency. However, it does not disclose behavioral traits such as authorization requirements, rate limits, or error handling. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, bulleted use cases, a do-not-use note, and formatted parameters/returns. Every sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema), the description is complete. It covers return fields, usage scenarios, and sibling differentiation. Minor omission: no mention of error behavior for invalid symbols, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete coverage (100%) with description, pattern, and examples for the single 'symbol' parameter. The tool description repeats this info but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve implied-volatility (IV) metrics for a single stock' and lists specific metrics (IV rank, percentile, volatility regime, risk reversal). It also explicitly distinguishes from the sibling 'analyze_stock' by noting that the IV data is included in that response, thus differentiating the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use this tool when:' scenarios (assessing options cheapness, current volatility regime, skew analysis) and a clear 'Do NOT use' condition (if already called analyze_stock). This gives concrete guidance on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes ensemble models (GBM, LSTM, VQC), input features (VIX, rates, options flow), and per-ticker accuracy variation. No annotations to contradict; detailed behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for usage, engine details, parameters, and returns. No extra fluff; every sentence contributes. Slightly lengthy return description is justified by missing output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description fully documents all return fields (symbol, prediction, probabilities, votes, regime, signal strength). Also covers model details and accuracy caveats, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter symbol has 100% schema coverage. Description adds 'Do NOT pass company names' and notes META/QQQ have better hit rates, providing extra beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource+scope: 'Get an AI/ML directional prediction for a stock's next-session move'. Clear action and outcome, distinct from sibling tools like get_iv_radar or get_monte_carlo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this tool when' scenarios: need probability estimate, ensemble breakdown, or compare confidence to IV pricing. Could mention alternatives but offers actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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 the GBM model, default 10,000 paths, and calibration data (realized volatility and IV). While it does not cover limitations or model assumptions, it provides sufficient behavioral context for a simulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for use cases and a clear 'Returns' section. It is appropriately sized (~200 words) with each sentence adding value. Slightly more conciseness in the parameter description could push it to 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description fully explains return values with a detailed dict breakdown, including nested dictionaries for range and distribution. Given the complexity of a Monte Carlo simulation with multiple outputs, the description is very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explicitly warning against using company names instead of tickers ('Do NOT pass company names — use official tickers only.'), which helps prevent common errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it runs a Monte Carlo price-path simulation for a stock over a 30-day horizon, with a specific verb (run/simulate) and resource (price-path). It distinguishes itself from siblings like 'analyze_stock' and 'get_ai_prediction' by focusing on probabilistic range and risk quantification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use scenarios: needing a probabilistic range, quantifying downside risk, sizing positions. It implicitly suggests alternatives for single-point estimates but does not explicitly name sibling tools as alternatives, keeping it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It thoroughly explains return structure, edge cases (e.g., no watchlist), and authentication requirements. However, it does not explicitly state whether the operation is read-only or has side effects, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (purpose, usage, params, example, returns, notes). The parameter section is redundant with the schema, but overall the description is concise given the tool's complexity and front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides comprehensive documentation of all return fields, including nested structures, edge cases, and user-facing messages. With no output schema, the description fully compensates, and the single parameter is well-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter; both the schema and description provide identical details (uppercase ticker, examples, no company names). The description adds an example call but no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a pre-trade risk scan for adding a single stock, listing specific risk metrics. It explicitly distinguishes from siblings 'get_monte_carlo' and 'analyze_stock', making the tool's unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this tool when' and 'Do NOT use this tool for' sections, with alternative tool names and clear criteria. This gives an AI agent unambiguous guidance on when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses key behaviors: images are public URLs, expire after 24 hours, and troubleshooting for rendering failures (copy URL to browser). It also details the return structure, which compensates for the lack of output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (usage, note, parameters, returns). Every sentence adds value without redundancy. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides complete information: what the tool does, when to use it, behavioral notes, parameter details, and return format (listing four keys). The context signals (1 param, no output schema) are fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's parameter section ('symbol: Exchange ticker in uppercase, e.g. NVDA, AAPL') does not add significant meaning beyond the schema's pattern, examples, and description. Therefore, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates chart image URLs for a stock, listing three specific chart types (price chart, IV surface, options flow heatmap). It distinguishes itself from siblings like 'analyze_stock' or 'get_equity_curves' by focusing on visual outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (user asks to see/show/visualize a chart, accompany analysis with visuals, share chart links). It does not include when-not-to-use or alternative tools, but the siblings are provided separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses latency (~10-20 s), reliance on HPSILAB_API_KEY, and that output is a full markdown report of ~800-1200 words. Could mention if it's read-only or modifies state, but reasonable given context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings, bullet points, and clear sections. Front-loaded with purpose and six sections list. Slightly verbose but each sentence adds value. Could tighten 'Output is a complete markdown string' vs earlier mention, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description provides return keys (symbol, report, generated_at) and report length. Lists six sections in detail. Also includes notes on API key and programmatic alternatives. Covers most information an agent needs to decide and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter symbol with 100% schema description coverage. Description adds meaningful guidance beyond schema: 'Do NOT pass company names — use official tickers only.' This helps avoid common errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a structured markdown research report for a single stock covering all major quantitative signal sources. It distinguishes itself from siblings like analyze_stock (structured JSON), get_iv_radar, get_monte_carlo, etc., by noting these are faster for specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user asks for report, write-up, deep dive) and when not to use (quick directional verdict → analyze_stock, specific data dimension → sub-tools). Also mentions latency of 10-20 seconds as a trade-off.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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 clearly describes what the tool does (retrieves data) and what it returns, implying a read-only operation. It could explicitly state it has no side effects, but the language is consistent with a non-destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a lead sentence, a bullet list of use cases, a parameter section, and a returns section. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description is very complete. It covers the purpose, when to use, the required parameter, and a detailed list of return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter. The description repeats the schema info but adds value with a negative instruction: 'Do NOT pass company names — use official tickers only.' This goes beyond the schema's examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb+resource: 'Retrieve options-market positioning and dealer-hedging pressure zones.' It lists concrete use cases (max-pain, gamma walls, expected move), distinguishing it from sibling tools like analyze_stock or get_iv_radar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool when:' and provides three specific scenarios, giving clear context. It does not mention when not to use or name alternatives, but the sibling tools are sufficiently different so this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses read-only nature, return structure, and data type (dict with specific fields). Lacks details on error handling or prerequisites but adequate for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headings (Parameters, Returns) and bullet points. Every sentence adds value; no fluff. Front-loaded with purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description fully documents return structure with field names, types, and examples. Includes enough detail to understand expected output without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by warning against company names and reiterating symbol format, going beyond schema. However, it largely reiterates schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('backtested equity curves and performance metrics for standard quantitative strategies applied to a single stock'), clearly distinguishing it from sibling tools like 'analyze_stock' or 'get_ai_prediction' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this tool when' section with three concrete scenarios (evaluating rule-based strategies, needing risk-adjusted metrics, building multi-leg options strategies) provides clear guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses aggregation of multiple data sources, API key requirement, quota/ticker coverage, and latency (~5-15 s). No annotations are provided, so the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections for purpose, usage, parameters, returns, and notes. Each sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains return structure. Combined with behavioral and usage details, it provides a complete understanding for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter. The description adds value by reinforcing the symbol format and explicitly forbidding company names, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'full institutional-grade quantitative analysis for a single stock,' using a specific verb and resource. It distinguishes itself from sibling sub-tools by positioning itself as the primary holistic analysis tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (holistic verdict, multiple signals, user requests 'stock analysis') and when not to (prefer sub-tools for specific dimensions), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/haiyunsky/hpsilab-quant-finance-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server