Trading Volatility MCP

Official

by tradingvolatility

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation3/5
Several tools target the same ticker and provide overlapping market-state information (get_ticker_state, get_market_structure, get_trade_setup, explain_ticker). While each has a distinct output format, the boundaries are not immediately clear from names alone. Gamma curve and GEX curve tools also overlap conceptually.
Naming Consistency5/5
All tools use snake_case with verb-first names (get_, rank_, run_, explain_, list_), and server_info is the only exception but still follows a predictable pattern. Very consistent and easy to parse.
Tool Count4/5
17 tools is on the heavy side but justifiable for a comprehensive volatility analytics API covering per-ticker analysis, cross-ticker ranking, screeners, and income setups. The count is slightly above the ideal range but not bloated.
Completeness4/5
The server covers a wide range of analysis needs: state snapshots, narratives, signals, levels, historical series, gamma/GEX curves, options volume, rankings, screeners, and trade setups. Minor gaps like open interest or an IV surface exist, but they are not critical for its stated purpose.
Average 4/5 across 17 of 17 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get the current signals', implying a read operation, but does not mention whether the call is safe, what data it returns, caching behavior, or rate limits. It adds no behavioral context beyond the core purpose.
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 a single, compact sentence with no filler. It is front-loaded and easy to parse. However, it is under-specified, which slightly reduces the value of its brevity.
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?
The tool is simple with only one parameter, and an output schema is present, which lessens the need for return-value explanation. However, the description lacks usage context and behavioral details, especially given no annotations. It does not help an agent decide when to select this tool among 17 siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single required 'ticker' parameter. The description merely says 'for a ticker', which restates the parameter name without adding meaning (e.g., format, examples, or constraints). Since the schema provides no descriptions and the description doesn't compensate, this is a clear gap.
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 'Get the current signals for a ticker', specifying both the action (get) and the resource (signals for a ticker). The parenthetical '(active setup/positioning signals)' adds specificity and differentiates it from sibling tools like get_ticker_state or get_trade_setup. However, it doesn't explicitly contrast with alternatives, so it's not a 5.
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 on when to use this tool versus alternatives. It simply states what it does, lacking any context about recommended use cases, prerequisites, or exclusions. The presence of many sibling tools makes this omission more significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states only that it returns 'basic information' but does not mention whether it performs network calls, is read-only, or has any side effects. The agent must infer safety from the tool name.
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 a single short sentence, perfectly concise with no wasted words. It conveys the core purpose without unnecessary elaboration.
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 the tool's simplicity (0 parameters, no nested objects, and an output schema available), the description is mostly adequate. It doesn't enumerate the 'basic information' contents, but for a trivial server-info tool, this is a minor gap.
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 tool has zero parameters, so there is nothing to describe. The schema confirms 0 properties, and the description adds no parameter-related information, which is appropriate for a parameterless tool.
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 'Basic information about this MCP server' clearly identifies the tool's resource (the MCP server itself) and implies an informational purpose. It distinguishes from sibling tools by scope (server metadata vs. market data/operations), though 'basic information' is somewhat vague and doesn't enumerate what fields are included.
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, nor does it mention any prerequisites or exclusions. The tool's uniqueness among siblings is implicit, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'deterministic' and 'when available' for views, which is useful, but it does not explicitly state whether the operation is read-only, requires authentication, or has side effects. The word 'Get' implies safe reads, but this is not explicitly disclosed.
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 concise and front-loaded: two sentences with no redundant content. The first sentence states the core purpose clearly, and the second adds parameter nuance without fluff.
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 an output schema handles return values, the description covers purpose and the optional view. However, it lacks guidance on when to use this tool over siblings and does not disclose potential limitations (e.g., view availability criteria). For a simple read tool, this is adequate but not complete.
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%, so the description must compensate. It explains the optional 'view' parameter (selects alternate explanation view) and implies 'ticker' is the symbol via 'a ticker's current regime'. However, it does not provide enumerated or format details for 'ticker', which is mostly self-explanatory.
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?
The description clearly states the tool provides a 'deterministic narrative interpretation' of a ticker's regime and positioning, a plain-language read. This specific verb+resource combination distinguishes it from siblings like get_ticker_state, which likely returns raw state data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (use for plain-language state interpretation) but does not explicitly state when to use this tool instead of alternatives like get_ticker_state. No exclusions or sibling references are provided, leaving the 'when-not' unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the resource and bucket types but does not mention authentication requirements, data latency, or error behavior. The read-only nature is implicit from 'Get' 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, and includes an enumerated list of buckets without any filler words. Every element earns its place.
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?
The tool is simple (one parameter) and has an output schema, so the description need not detail return values. The bucket list is sufficient for basic understanding, though it would benefit from a note on how it differs from get_gamma_curve.
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?
The description mentions 'for a ticker', which references the single parameter, but adds little beyond the schema's 'Ticker' title. It does not explain format or constraints, yet the parameter is self-explanatory given the low complexity.
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?
The description clearly states the action ('Get'), the specific resource ('strike-aligned gamma decomposition'), and the precise expiration buckets (combined, nearest, first_weekly, first_monthly, all_other_expiries). This distinguishes it from sibling tools like get_gamma_curve and get_gex_by_strike.
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 explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The intended use is only implied by the verb 'Get' and the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the output is deterministic and lists content, but it does not explicitly state that the tool is read-only, whether authentication is required, or how it handles invalid tickers. It adds some context but is not fully transparent.
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 a single, dense sentence that front-loads the core verb and resource, then uses a colon to list the output contents. Every phrase adds value with no redundancy. It is concise and well-structured, though slightly run-on.
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?
The description thoroughly enumerates the components of the trade setup, and an output schema is present to explain return structure. Lacking only explicit usage guidance and safety details, it is largely complete for a one-parameter read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only echoes the parameter name ('for a ticker') without adding format details, constraints, or examples. While it ties the ticker to the purpose, it provides minimal additional semantics beyond the parameter name.
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?
The description clearly states the tool gets a trade setup for a ticker, listing specific outputs (regime, bias, opportunity score/tier, etc.). It distinguishes itself from siblings like get_ticker_state (state only) and get_signals (signals only) by aggregating market state and a deterministic recommendation into a compact, agent-oriented package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('compact agent-oriented') but does not explicitly state when to use this tool over alternatives like get_ticker_state or explain_ticker. No direct comparison or exclusions are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It discloses the `view` parameter's effect on output formatting, but does not state whether the operation is read-only, the response structure, or any error conditions. The read-only nature is implied but not explicit.
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 two concise sentences, front-loading the core purpose and then providing essential format details. No redundant or irrelevant information.
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?
For a two-parameter, read-oriented tool with an output schema, the description covers the essential aspects: what levels are returned, which parameters control the call, and output formatting options. It lacks usage context, but that is scored separately.
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 coverage is 0%, so the description compensates by explaining both parameters: `ticker` is the symbol to query, and `view` formats the output with allowed values. It adds the default ('json') and explains the purpose of each parameter, which is beyond the schema's bare type definitions.
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?
The description clearly states the tool's function: retrieving key price levels for a ticker, and enumerates specific level types (gamma flip, walls, max pain, expected-move bounds). This specificity distinguishes it from sibling tools that handle gamma curves or GEX by strike.
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 given on when to use this tool versus alternatives. The description focuses solely on mechanics (view options) and does not mention prerequisites, typical use cases, or when to prefer other tools like get_gamma_curve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose operational behavior. It describes the return content but does not mention authentication requirements, side effects, error conditions, or rate limits. The verb 'Get' suggests read-only, but this is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and uses no filler. It efficiently conveys the tool's output and the optional parameter behavior.
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?
The tool has an output schema, so the description need not detail return formats. It covers the main sections returned and the include parameter. It is sufficiently complete for an agent to select and invoke the tool, though it would benefit from mentioning any prerequisites.
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 explains the 'include' parameter's purpose and gives examples ('state', 'call_diag'), adding meaning beyond the bare schema. The 'ticker' parameter is self-explanatory and requires no further semantics.
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?
The description clearly states the tool's function: 'Get the assembled market-structure interpretation for a ticker' and lists the specific outputs (headline signal, regime classification, expected behavior, key levels, supporting metrics). This distinguishes it from sibling tools like get_ticker_state or get_levels, which focus on individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a comprehensive market-structure interpretation is needed) but provides no explicit guidance on when not to use it or which sibling tool might be more appropriate. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It adds useful context: real-time data, aggregation by strike, exp selects contract month, include adds IV columns. However, it does not mention auth, rate limits, or behavior when no data is available.
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?
Two sentences: first states purpose, second provides parameter guidance. No redundancy or filler. Front-loaded and appropriately sized.
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?
An output schema exists, so return values don't need explanation. The description covers purpose, key parameters, and optional behavior. It omits potential caveats (e.g., behavior with no trades) but is adequate for a focused data retrieval tool.
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 explains exp (contract month) and include (adds IV columns); ticker is self-evident from the tool description. This adds meaning beyond the raw schema.
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?
The description uses a specific verb and resource: 'Get real-time options volume aggregated by strike for a ticker and a specific expiration.' This clearly states what the tool does and distinguishes it from siblings like get_gamma_curve or get_gex_by_strike.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or when-not-to-use conditions are given. The description implies usage when options volume data is needed, and provides parameter usage hints (exp and include), but doesn't name sibling tools or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses one behavioral trait: 'Both are optional and fall back to the API defaults.' This is useful but limited; it does not address auth, rate limits, invalid inputs, or response behavior. Since the output schema exists, return structure is covered, but the description could be more explicit about operational nuances.
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 two sentences: the first states the core purpose, the second packs parameter guidance and default behavior. No wasted words, information is front-loaded, and the structure is easy to scan.
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?
For a moderately simple data-retrieval tool with an output schema, the description effectively covers purpose, parameter formats, and default behavior. It lacks explicit comparison to sibling tools, but this is partially covered by purpose clarity. Overall, it is sufficient for an agent to understand what the tool returns and how to invoke it.
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 input schema provides only parameter names with no descriptions (0% coverage). The description compensates by explaining the format and semantics of `metrics` (comma-separated metric keys with examples) and `window` (lookback like '30d', '180d', or '2y'), along with noting both are optional. This adds meaningful value beyond the schema.
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?
The description clearly states the tool's function: 'Get a historical daily time series for a ticker.' This specific verb+resource (get + historical daily time series) differentiates it from sibling tools like get_ticker_state (current state) or get_levels (derived levels). The intended use for 'charting and regime context' further clarifies its niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use context ('for charting and regime context'), implying this tool is for historical analysis rather than current snapshots. However, it does not explicitly compare with alternatives or state when not to use it, leaving some ambiguity given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the realtime intraday pull and the trading-hours constraint when exp is a specific date, which is valuable. However, it omits other behavioral context like read-only nature (though implied by 'Get'), auth needs, or data freshness. There is also a mismatch between the schema default (null) and the description's claim that 'combined' is default.
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 two sentences. The first sentence states the purpose, and the second covers parameters and constraints. Every word earns its place; no filler or redundancy.
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?
An output schema is present, so return values are documented elsewhere. For the complexity of this tool, the description covers the main parameters and key constraints. It could be more complete if it mentioned when to use this vs. sibling tools, but that is not essential given the schema and clear purpose.
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 is the sole source of parameter meaning. It explains exp with its possible values and default, and realtime with its intraday semantics. Ticker is left implicit (obvious). This adds significant meaning beyond the raw schema, but the default-value mismatch with the schema prevents a perfect score.
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?
The description clearly states the function: "Get the gamma strike curve (net gamma per strike) for a ticker." It uses a specific verb (Get) and resource (gamma strike curve), and the phrase "per strike" distinguishes it from sibling tools like get_gamma_by_expiration and get_gex_by_strike.
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 description provides clear guidance on how to use the exp parameter (with valid values and default) and the realtime parameter (with the trading-hours constraint). However, it does not explicitly contrast this tool with alternatives such as get_gamma_by_expiration or get_gex_by_strike, so exclusions are not stated.
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?
With no annotations, the description carries the transparency burden. It discloses meaningful behavioral output: the tool returns a net GEX strike curve, includes call/put contributions, and identifies dominance. It also defines the `exp` behavior. It does not mention potential errors or data availability, but for a read-only data retrieval tool this is adequate.
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 two sentences, front-loaded with the main purpose and outcome, followed by parameter-specific guidance. Each sentence adds value with no filler or redundancy.
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 the tool's simplicity (2 parameters, output schema present), the description is largely complete. It explains the core functionality, the optional parameter, and the expected output. The only minor gap is the lack of explicit usage contrast with sibling tools, but this does not hinder basic selection and invocation.
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 does so well for `exp` by listing exact accepted values ('combined', 'nearest', 'first_monthly') and the default. `ticker` is self-explanatory from its name and context. This is strong compensation despite the lack of schema-level descriptions.
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?
The description uses a specific verb ('Get'), names the exact resource ('net GEX (gamma exposure) strike curve'), and adds distinguishing output detail ('call/put contributions', 'identifies key strikes and call-vs-put dominance'). This clearly differentiates it from siblings like get_gamma_curve or get_gamma_by_expiration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining the `exp` parameter values and default. However, it does not explicitly say when to use this tool versus alternatives such as get_gamma_curve or get_gamma_by_expiration, so the usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It adds useful behavioral details like the default limit, value ranges for score/IV/price, and AND'd filter logic. However, it does not disclose whether authentication is required, what the return object contains (though an output schema exists), or any rate/performance implications of scanning all tickers.
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 a single dense sentence, but the core purpose is front-loaded. The long filter list is necessary to convey constraints. It is efficient and employs consistent formatting (backticks, ranges) to aid readability, though it could be structured as bullets for even better scannability.
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?
With 12 optional parameters and no annotations, the description covers invocation thoroughly, and the output schema covers return structure. It lacks an explicit comparison to sibling screening tools (run_screener, rank_income_setups) and does not explain the opportunity score's derivation, but it gives enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions and no enums, yet the description details every parameter: ranges (limit 1-200, min_score 0-10, IV rank 0-100, price bounds), CSV formats for multi-value fields, a concrete example for regime, and defaults. This fully compensates for the schema's lack of semantic information.
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?
The description opens with a specific verb ('Rank'), a clear resource ('trade setups'), a scope ('across all tickers'), and a sorting key ('opportunity score descending'). This strongly distinguishes it from sibling tools like rank_income_setups, which focuses on income rather than opportunity.
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 description clearly implies when to use this tool: when a ranked, filterable list of top setups across all tickers is needed. However, it does not explicitly mention alternatives or when not to use it, such as comparing with run_screener or rank_income_setups.
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?
With no annotations provided, the description carries the burden of disclosure. It reveals that the snapshot is 'canonical' and 'compact', and lists the metric categories included. The verb 'Get' implies a read-only operation, and the description goes beyond the schema by explaining the nature of the output, though it does not mention rate limits or error conditions.
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 two sentences long, front-loaded with the primary purpose, and includes a brief but useful explanation of the optional parameter. Every sentence earns its place with no fluff or repetition.
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 the tool's simplicity (2 params, output schema exists) and the lack of annotations, the description is largely complete. It clarifies the tool's role as a starting point and highlights key output contents. It could slightly extend by explicitly noting it is a safe read operation, but the verb and content list already imply this. Overall, a solid description for a straightforward getter.
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 explains the 'include' parameter as a comma-separated list of add-ons with an example ('call_diag'), adding real semantic value. The 'ticker' parameter is self-evident from its name and type, and the description reinforces it by referencing 'a ticker'.
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?
The description clearly states the verb 'Get' and the resource 'canonical compact state snapshot for a ticker', and enumerates the contents (price, gamma regime, IV rank, key positioning metrics). It also distinguishes itself as 'the default starting point for analysis', separating it from siblings like get_signals or get_market_structure.
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 phrase 'default starting point for analysis' provides clear context for when to use this tool. It also explains the optional 'include' parameter, but does not explicitly state when to avoid this tool in favor of alternatives, so it lacks full exclusions.
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?
Since no annotations are provided, the description carries the full burden. It discloses key behavioral traits: filters override preset values, all filters are optional and AND-combined, and `limit` has a default of 20. It also provides range constraints for several parameters. It does not state read-only behavior explicitly, but that is implied by 'run a screener' and is not contradictory. The override and AND logic add significant transparency beyond a simple statement.
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 a single dense paragraph but every clause adds value. It front-loads the core purpose and then systematically lists filters with their constraints. It is not overly verbose, though it could be slightly improved with bullet points or explicit separation. Overall, it is concise and well-organized for the amount of information.
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 the tool's complexity (13 parameters, output schema present), the description covers all parameter semantics, override behavior, and filter logic. It does not explain return values because the output schema handles that. It lacks detailed preset definitions or examples of full invocations, but these are not essential for a correct invocation. The description is sufficiently complete for an agent to select and call the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It does so by naming every parameter, specifying types, ranges, defaults, and CSV formats where applicable (e.g., regime CSV, recommended_direction long/short/neutral). It also enumerates the valid presets for the `name` parameter. This is comprehensive and goes well beyond the bare schema.
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?
The description opens with a specific verb-resource pair: 'Run a named screener preset over the cross-ticker ranking.' It clearly indicates the tool executes preset screeners, and enumerates the exact preset names, which distinguishes it from sibling tools like rank_top_setups or get_signals.
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 description provides strong context on when to use the tool: to run a named preset with optional override filters. It explains how filters combine (AND'd) and that they override preset values, but it does not explicitly mention alternatives or exclusion criteria relative to sibling tools. This is clear usage context without explicit 'when not to use' guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately explains the two return modes ('keyed' vs 'demo') and explicitly states that the API key is not revealed, providing useful security-relevant context beyond a simple status check.
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 two sentences long, front-loaded with the verb and resource, and contains no redundant information. Every clause adds value, explaining modes, their implications, and a security guarantee.
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?
Given the tool's simplicity (0 params, output schema present), the description is complete: it covers what the tool does, what the possible return values mean, and an important security behavior. No additional context is needed for correct invocation.
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 tool has zero parameters, and schema description coverage is trivially 100%. The description appropriately omits parameter details, matching the baseline score of 4 for parameterless tools.
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?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('how the Trading Volatility MCP is authenticated for this session'). It distinguishes from sibling market-data tools by focusing solely on authentication status.
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 context is clear: the tool reports authentication mode for the current session. While no explicit alternatives or exclusions are mentioned, the purpose is unambiguous and self-contained, making it obvious when to invoke it (e.g., at session start to verify access level).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the return content (manifest of endpoints, metrics, parameters, conventions) and purpose, but does not disclose potential behavioral aspects like authentication, rate limits, or whether the data is static or dynamic. For a read-only metadata endpoint, this is adequate but not rich.
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?
Two sentences, each earning its place: the first defines the return value, the second gives usage direction. No filler or redundant content.
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?
Given the tool's simplicity (no params, output schema present), the description fully covers what it does and when to use it. The output schema presumably details the manifest structure, so the description doesn't need to list every field.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details (there are none), but it does clarify that the tool returns a manifest, which indirectly explains why no parameters are needed.
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?
The description starts with 'Return the Trading Volatility v2 capability manifest' which clearly states the specific verb and resource. It also differentiates from sibling tools by positioning this as the self-orientation entry point, distinct from the other data-fetching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first to self-orient' and 'before making other calls', providing clear when-to-use guidance. This implies the alternative is any other tool, and the description makes the ordering clear.
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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: each ticker may appear as both CC and CSP, estimates are as-of the latest snapshot, and earnings/event risk is flagged but not filtered out. It does not explicitly state read-only status, but the ranking nature and the mention of 'estimates' imply no side effects. This is sufficient transparency given the absence of annotations.
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: first sentence defines the purpose and scoring, second sentence explains output fields, third sentence details filters with value ranges, and fourth sentence adds a caveat about snapshots and risk. Every sentence earns its place, and information is front-loaded.
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?
Given the tool's complexity and the presence of an output schema, the description is complete. It explains the ranking logic, output fields, filter options, and data freshness caveat. It covers all essential aspects needed for an agent to select and use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its parameters, but the description fully compensates by detailing each filter: 'type' ('cc' or 'csp'; omit for both), 'min_income_score' (0-10), and 'limit' (2-50, default 10). This adds significant meaning beyond the bare schema titles and enables correct invocation.
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?
The description clearly states the verb 'Rank' and the resource 'single-leg income setups (covered calls and cash-secured puts)' across all tickers. It specifies the scoring mechanism (IVR-led, regime-guarded income-fit score) and distinguishes itself from sibling tools like 'rank_top_setups' by focusing specifically on income setups with a unique scoring approach.
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 description provides clear context for when to use this tool: to rank income setups across all tickers with optional filters. It does not explicitly name alternatives or when-not-to-use conditions, but the scope ('across all tickers') and filter options imply a broad screener use case, which is sufficient context without exclusions.
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:

[![tv-mcp MCP server](https://glama.ai/mcp/servers/tradingvolatility/tv-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tradingvolatility/tv-mcp)

Score Badge

Copy to your README.md:

[![tv-mcp MCP server](https://glama.ai/mcp/servers/tradingvolatility/tv-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tradingvolatility/tv-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/tradingvolatility/tv-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server