Skip to main content
Glama
haiyunsky

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

by haiyunsky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_option_pressure

Read-onlyIdempotent

Identify options-market positioning and dealer-hedging pressure zones, including max-pain targets, gamma walls, and expected-move ranges for a ticker’s nearest expiry.

Instructions

Retrieve options-market positioning and dealer-hedging pressure zones.

Use this tool when:

  • You want to identify max-pain price (where option sellers face least loss at expiry) as a gravitational target near expiration.

  • You need to locate gamma walls (strike clusters with large open interest) that act as price magnets or resistance/support levels.

  • You want the expected-move range implied by the options market for the current weekly/monthly expiry cycle.

Returns

dict with keys: symbol : str — normalized ticker max_pain : float — max-pain strike price gamma_wall : float — largest gamma concentration strike expected_move : float — ±expected move in dollars for nearest expiry squeeze_target: float — upside squeeze price target expiry_date : str — target expiry date (YYYY-MM-DD) pressure_zones: list — list of significant strike/OI concentration dicts

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

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare it as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds domain meaning to the returned fields, but it does not disclose operational traits such as data freshness, market-hours behavior, or rate limits beyond what the annotations and output schema provide.

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 front-loaded with purpose and use cases, then structured return-value details. The returns section largely duplicates the existing output schema, so it is not maximally concise, but the overall structure is clear and readable.

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

Completeness5/5

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

With a single required parameter, full schema coverage, rich annotations, and an output schema, the description is more than sufficient for correct invocation. It covers purpose, use cases, and return semantics without leaving material gaps.

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 the input schema covers it at 100% with a pattern, examples, and a clear warning against using company names. The description does not add any symbol-format guidance beyond the schema, so the baseline 3 is appropriate.

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 states a specific verb and resource: retrieving options-market positioning and dealer-hedging pressure zones. It explains the concrete outputs (max pain, gamma walls, expected move), making the tool clearly distinct in practice. However, it does not explicitly differentiate itself from sibling tools such as get_iv_radar or analyze_stock.

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' bullets give clear triggering conditions for max-pain, gamma walls, and expected-move analysis. It does not mention when not to use the tool or name a sibling alternative, so it falls short of the top score.

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