Skip to main content
Glama
Sign In
HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics

HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics

by haiyunsky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_monte_carlo

Read-onlyIdempotent

Estimate probabilistic stock price ranges and odds of crossing resistance or support by running a 5,000-path GBM simulation over 10 trading days.

Instructions

Run a Monte Carlo price-path simulation for a stock over the next 10 trading days.

Use this tool when:

  • You need a probabilistic price range rather than a single point estimate.

  • You want the odds of finishing above recent resistance or below support.

  • You are sizing a position using a volatility-adjusted scenario.

The simulation uses a GBM (Geometric Brownian Motion) model calibrated with the stock's historical daily log-return drift and volatility (not implied volatility). 5,000 paths are run.

Returns

dict with keys: ticker : str — normalized ticker horizon_days : int — simulation horizon in trading days (10) ci : float — confidence level of lower/upper_bound (0.90) lower_bound : float — lower edge of the central ci price range upper_bound : float — upper edge of the central ci price range mean_price : float — mean simulated price at horizon median_price : float — median simulated price at horizon support : float — 20-day rolling low resistance : float — 20-day rolling high (also returned as threshold) prob_above : float — probability (0–1) the horizon price exceeds resistance prob_below : float — 1 - prob_above volatility : float — daily log-return standard deviation std_tomorrow : float — one-day price standard deviation (spot × volatility) final_prices : list — every simulated horizon price msg : str — one-line plain-English summary

Input Schema

NameRequiredDescriptionDefault
symbolYesExchange ticker in uppercase, e.g. 'NVDA', 'AAPL', 'SPY', 'QQQ'. Do NOT pass company names ('Nvidia') — use official tickers only.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.11.1
    • changedInput schema / properties / symbol / description
      Previous value: -"Exchange ticker in uppercase, e.g. 'MSFT', 'NVDA', 'SPY'. Do NOT pass company names — use official tickers only."New value: +"Exchange ticker in uppercase, e.g. 'NVDA', 'AAPL', 'SPY', 'QQQ'. Do NOT pass company names ('Nvidia') — use official tickers only."
    • changedInput schema / properties / symbol / examples
      Previous value: -[
-  "MSFT",
-  "NVDA",
-  "SPY"
-]New value: +[
+  "NVDA",
+  "AAPL",
+  "SPY",
+  "QQQ"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "get_monte_carloDictOutput",
+  "type": "object"
+}
  2. Changed3 schema fields changedv0.3.1
    • addedInput schema / properties / symbol / description
      Added value: +"Exchange ticker in uppercase, e.g. 'MSFT', 'NVDA', 'SPY'. Do NOT pass company names — use official tickers only."
    • addedInput schema / properties / symbol / examples
      Added value: +[
+  "MSFT",
+  "NVDA",
+  "SPY"
+]
    • addedInput schema / properties / symbol / pattern
      Added value: +"^[A-Z][A-Z0-9.-]{0,15}$"
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and open-world, so the description's added value is the model disclosure: GBM calibrated on historical log-return drift and volatility, explicitly *not* implied volatility, with 5,000 paths. That is genuinely useful context (and quietly explains why this differs from get_iv_radar), but it omits cost/latency, data requirements (e.g. how much history is needed), and behavior on an unknown or thinly traded ticker.

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

Conciseness3/5

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

Purpose and usage bullets are well front-loaded, but the description then embeds a full 15-line 'Returns' section that duplicates field-by-field what the existing output schema already declares. That block consumes more than half the text without adding information an agent can't get from structured data, so the otherwise clean structure is diluted.

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

Completeness4/5

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

Given a single required parameter, full schema coverage and an output schema, the definition covers everything needed to invoke it correctly: model assumptions, fixed horizon, path count, and when to choose it. Missing only secondary details such as error behavior for invalid symbols and whether repeated calls return identical paths, which the idempotentHint implies but doesn't confirm.

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?

There is only one parameter and schema coverage is 100%, with the schema itself spelling out uppercase ticker format, a regex pattern, examples, and the 'no company names' rule. The description adds nothing about `symbol`, so this sits at the baseline where the schema does all the work.

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

Purpose5/5

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

States a specific verb and resource ('Run a Monte Carlo price-path simulation') plus the scope ('next 10 trading days') in the first line. The three 'Use this tool when' bullets distinguish it from point-estimate siblings like get_ai_prediction and analyze_stock by explicitly framing it as a probabilistic range rather than a single number.

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

Usage Guidelines4/5

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

The 'Use this tool when' block gives three concrete selection conditions, including the key contrast 'a probabilistic price range rather than a single point estimate', which implicitly routes point-estimate requests elsewhere. It stops short of naming a concrete alternative sibling or a 'do not use when' case, so it is clear context but not full routing guidance.

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

Deploy Server

Other Tools