Skip to main content
Glama
Sign In

FlashAlpha

by com.flashalpha.lab
OverviewDiscussionsAdmin

Get VRP History

get_vrp_history
Read-only

Get historical VRP time series: daily ATM IV, realized vol (5/10/20/30d), VRP, straddle price, and expected move for charting and backtesting.

Input Schema

NameRequiredDescriptionDefault
endNoNormalized range end YYYY-MM-DD; at most 366 calendar days.
daysNoNumber of days of legacy persisted history (default 30, max 365)
startNoNormalized range start YYYY-MM-DD; SPY/QQQ, completed dates only.
apiKeyNoFlashAlpha API key. Omit when calling via /mcp-oauth (OAuth flow); required on /mcp.
seriesNolegacy (default) or normalized constant-tenor reconstructed history; normalized requires start/end instead of days. normalized is release pending (503 daily_series_disabled until enabled).
symbolYesStock/ETF ticker
tenor_daysNoNormalized IV tenor in calendar days: 30, 60 or 90.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / series / description
      Previous value: -"legacy (default) or normalized constant-tenor reconstructed history; normalized requires start/end instead of days."New value: +"legacy (default) or normalized constant-tenor reconstructed history; normalized requires start/end instead of days. normalized is release pending (503 daily_series_disabled until enabled)."
  2. Changed5 schema fields changed
    • changedInput schema / properties / days / description
      Previous value: -"Number of days of history (default 30, max 365)"New value: +"Number of days of legacy persisted history (default 30, max 365)"
    • addedInput schema / properties / end
      Added value: +{
+  "default": null,
+  "description": "Normalized range end YYYY-MM-DD; at most 366 calendar days.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / series
      Added value: +{
+  "default": null,
+  "description": "legacy (default) or normalized constant-tenor reconstructed history; normalized requires start/end instead of days.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / start
      Added value: +{
+  "default": null,
+  "description": "Normalized range start YYYY-MM-DD; SPY/QQQ, completed dates only.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / tenor_days
      Added value: +{
+  "default": null,
+  "description": "Normalized IV tenor in calendar days: 30, 60 or 90.",
+  "type": [
+    "integer",
+    "null"
+  ]
+}
  3. Changed4 schema fields changed
    • addedInput schema / properties / apiKey / default
      Added value: +null
    • changedInput schema / properties / apiKey / description
      Previous value: -"Your FlashAlpha API key"New value: +"FlashAlpha API key. Omit when calling via /mcp-oauth (OAuth flow); required on /mcp."
    • changedInput schema / properties / apiKey / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / required
      Previous value: -[
-  "symbol",
-  "apiKey"
-]New value: +[
+  "symbol"
+]
  4. Added

TDQS

A3.5/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, so the description's main added value is disclosing the returned series. It says nothing about pagination, the 366-day/series-mode limits, or the legacy-vs-normalized behavior — those live only in the schema — so behavioral context beyond annotations is thin.

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?

A single front-loaded sentence with the verb first and the payload enumerated compactly; no filler, hedge, or redundancy. Every clause maps to actual returned data.

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?

With no output schema, enumerating the returned series is genuinely necessary and done well, but the description omits the legacy-vs-normalized series distinction and the release-pending 503 state (present only in the schema) and does not resolve ambiguity against get_historical_vrp. For a 7-parameter tool with several overlapping siblings, 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 100%, so the baseline is 3; every parameter (start/end/days/series/tenor_days/apiKey) is documented in the schema itself. The description adds no syntax, format, or default guidance beyond what the schema already supplies, though it does echo the realized-vol windows returned.

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?

States a specific verb and resource ('Get historical VRP time series') and enumerates the returned series (ATM IV, realized vol windows, VRP, straddle price, expected move), so an agent knows exactly what data comes back. However, it does nothing to distinguish itself from the near-identical siblings get_vrp and get_historical_vrp, which risks mis-selection.

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?

'for charting and backtesting' hints at the intended use case, which is more than most siblings offer. But there is no explicit when-not guidance and no routing to the obvious alternatives (get_vrp for a current snapshot, get_historical_vrp for the other historical variant), leaving the agent to guess between overlapping tools.

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

All FlashAlpha toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources