米国株式ポートフォリオのリスクを、そのファクタースペクトラムに分解します。
エクスプローラー: https://risk-prism-production.up.railway.app · エージェント用モデルカード: /model.md
オープンソースのBarraスタイルのファンダメンタルファクターリスクモデルで、AIエージェントがそのまま使えるように設計されています。Pythonライブラリ、MCPサーバー、そして最も流動性の高い米国普通株式をカバーする週次公開のモデルアーティファクトを提供します。
7つのスタイルファクター（size、value、momentum、volatility、liquidity、quality、leverage）+ 12業種（Fama-Frenchスキーム）+ マーケットファクター
無料で再配布可能なデータチェーン: SEC EDGAR（パブリックドメイン）からのファンダメンタルズとSICコード、プラグイン可能なプロバイダーからの価格
ハイブリッド配布: 事前計算されたアーティファクト（エクスポージャー、ファクター共分散、固有リスク）は週次スケジュールで公開され、さらにパイプライン全体がオープンなので、誰でも再現または拡張できます
免責事項: 研究用ソフトウェアであり、現状のまま提供されます。ここに記載されている内容は投資助言ではありません。
{
"mcpServers": {
"riskprism": {
"command": "riskprism-mcp",
"env": { "RISKPRISM_ARTIFACTS": "/path/to/artifacts" }
}
}
}公開されているツール: get_model_info、get_portfolio_risk、get_factor_exposures、stress_test、check_coverage。ウェイトはポートフォリオのウェイトです（空売りはマイナス）。ボラティリティは年率換算の小数です。
Related MCP server: Portfolio Rotation MCP Server
from riskprism import RiskModel
model = RiskModel.load("artifacts")
report = model.portfolio_risk({"AAPL": 0.4, "MSFT": 0.3, "XOM": 0.3})
print(report["total_vol"], report["factor_var_contributions"])
model.stress_test({"AAPL": 1.0}, {"market": -0.10, "momentum": -0.05})pip install -e ".[dev]"
export RISKPRISM_EDGAR_UA="your-project (you@example.com)" # SEC fair-access policy
riskprism-build --max-names 3000 --out artifacts # yahoo prices, no key needed
riskprism-build --prior artifacts_prev --out artifacts # append new weeks to a prior build
riskprism-build --provider tiingo ... # licensed data, needs TIINGO_API_KEY週次のGitHub Actionはまさにこれを実行し、アーティファクトディレクトリを公開します。.github/workflows/build-model.yml を参照してください。
モデルを探索するためのバックエンド不要の静的サイト（Railwayでホストされ、週次のビルドごとに再レンダリングされます）。累積ファクターリターン、ファクターのボラティリティと相関、ストレステスト用スライダー付きのクライアントサイドのポートフォリオリスクサンドボックス、銘柄別のファクタープロファイル、そして手法を視覚的に解説するウォークスルーを備えています。すべての計算は、埋め込まれたアーティファクト上でブラウザ内で実行されます。
エージェントは、各ビルドのプレーンMarkdownミラーを /model.md（/llms.txt によってインデックス化）で取得できます。モデルカード、ファクター定義、相関、完全なカバレッジリストが含まれており、DOM解析は不要です。
すべてをローカルでレンダリング:
riskprism-site --artifacts artifacts --out site # index.html + model.md + llms.txtコンポーネント | 選択 |
期間 | 中期（週次リターン、年率換算の出力） |
推定 | クロスセクションWLS（√時価総額ウェイト）、時価総額加重の業種制約 |
ファクター共分散 | EWMA — ボラティリティ半減期13週、相関半減期26週、PSD修復済み |
固有リスク | EWMA残差ボラティリティを、履歴の長さに応じて構造的（特性ベース）事前分布とブレンド |
ユニバース | 推定: 株価≥$2、ADV≥$100万、26週以上の履歴 · カバレッジ: 存続中の全銘柄で株価≥$1、事前分布がギャップを補完 |
履歴 | キャプチャーフォワード: 週次ビルドは前回リリースに追記。上場廃止は補完され、サバイバーシップバイアスは時間とともに減衰 |
完全な手法はdocs/METHODOLOGY.mdに、設計上の決定とその根拠はdocs/DECISIONS.mdに記載されています。
コードはMITライセンスです。公開されているモデルアーティファクトは、SEC EDGAR（パブリックドメイン）およびサードパーティの価格プロバイダーから構築された派生データです。データライセンスに関する議論はdocs/DECISIONS.mdを参照してください。
Which of the given tickers the current model build covers.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only states the nominal result (which tickers are covered) and gives no indication of side effects, error conditions, or what happens with invalid or unknown tickers. For a tool without annotation safety hints, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It communicates the core idea in eight words. It is slightly awkward grammatically ('the current model build covers') but remains compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), a brief description is acceptable. However, the absence of any detail about the return format or expected ticker format makes it minimally viable rather than complete. An agent could call it correctly with reasonable assumptions, but the margin for misinterpretation is non-trivial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond the schema. It mentions 'given tickers' but does not explain what constitutes a valid ticker, case sensitivity, or how to interpret coverage. The parameter name and type are obvious from the schema, but the description contributes little additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the query action: it identifies which tickers are covered by the current model build. Though phrased as a fragment rather than an imperative verb, the resource (tickers, model build) is clear and distinct from sibling tools like get_factor_exposures or stress_test. It could name the outcome more explicitly, but it is far from tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings. No context suggests that this should be called before factor exposure or risk computations, and no alternatives are mentioned. An agent must infer the use case from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look-through risk report for one ETF or mutual fund: the latest
SEC N-PORT holdings resolve to model tickers and the portfolio math
runs on those weights. Reports total/factor/specific vol, factor
exposures, top contributions, and the fund block with the holdings
date and coverage. Returns an error dict when the ticker locates no
fund, or when the model covers less than half of the holdings (bond
and international funds). Needs RISKPRISM_EDGAR_UA (an identifying
User-Agent, per SEC fair-access policy) for the EDGAR fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| horizon | No | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so well: it discloses the return shape (error dict under two named conditions), the coverage limitation for bond and international funds, and the RISKPRISM_EDGAR_UA credential requirement tied to SEC fair-access policy. An agent knows both what it gets and what can go wrong before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no filler: first the operation, then the returned quantities, then failure modes and prerequisites. The jargon is dense but each clause adds information; minor verbosity in 'the portfolio math runs on those weights' keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly enumerates return contents (total/factor/specific vol, factor exposures, top contributions, `fund` block with holdings date and coverage) and error behavior. It is nearly complete for a two-parameter tool, with the sole gap being the unexplained `horizon` argument.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 hints at the meaning of `ticker` via the error discussion, but the `horizon` parameter (default 'medium') is never mentioned — no allowed values, no effect on the output. Half the parameters remain semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — a look-through risk report for a single ETF or mutual fund — and explains the mechanism (SEC N-PORT holdings resolved to model tickers). This clearly separates it from siblings like get_portfolio_risk (arbitrary portfolios) and get_factor_exposures (factor view only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scoping phrase 'for one ETF or mutual fund' implicitly tells the agent when this tool applies versus the broader portfolio sibling, and the error conditions ('when the ticker locates no fund', low coverage on bond/international funds) signal when it will not work. There is no explicit 'use X instead of Y' routing, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-asset factor exposures and total/factor/specific vol for each ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| horizon | No | medium | |
| tickers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It does state the output fields, implying a read-only retrieval, but it does not disclose behavior around horizons, model versions, or edge cases such as missing tickers or coverage limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The key content, per-asset factor exposures and vol breakdown, is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It does not clarify the horizon parameter, the default behavior, how to interpret the vol terms, or what distinguishes this tool from the listed siblings, leaving an agent with meaningful ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for both parameters. It covers 'tickers' implicitly with 'for each ticker', but 'horizon' is completely unexplained, including allowed values or how it affects the exposures and volatility estimates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the output: per-asset factor exposures and three volatility measures for each ticker. It distinguishes itself from portfolio-level siblings like get_portfolio_risk by using 'per-asset'. However, it is a noun phrase rather than an explicit verbed statement of what the tool does, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_portfolio_risk, stress_test, or check_coverage. The only implicit hint is the 'per-asset' scope, which is not enough to route an agent reliably.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Model version, as-of date, factor list, and asset coverage count.
horizon: "medium" (default) or "short" — the responsive variant with
halved risk half-lives, when available.
| Name | Required | Description | Default |
|---|---|---|---|
| horizon | No | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the kind of data returned and explains the 'short' horizon behavior as a responsive variant with halved risk half-lives. However, it does not explicitly state side-effect-free read behavior or what happens if the short horizon is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the returned contents, and the second sentence explains the only parameter. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the main response contents and the parameter variants. Minor gaps remain around fallback behavior when the short horizon is unavailable, but overall it is sufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the single parameter `horizon` with its default 'medium', the alternative 'short', and its behavioral meaning. This adds genuine value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: get_model_info returns model version, as-of date, factor list, and asset coverage count. This is specific and actionable, though it does not explicitly distinguish itself from the sibling list_model_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_model_versions or check_coverage. The horizon parameter is explained, but the description does not state preferred scenarios, exclusions, or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full risk report for a portfolio: total/factor/specific vol, factor
exposures, top factor variance contributions, and top asset risk
contributions. weights maps ticker -> portfolio weight. ETF and
mutual fund tickers expand into their filed holdings before the math
runs (set lookthrough=false to disable); funds the model cannot
cover are reported in lookthrough.notes. Set optimized=true if
the weights came from optimizing against this model: reported vols
then include the Shepard second-order correction (optimizers exploit
covariance estimation noise, so raw forecasts understate an optimized
portfolio's risk). horizon: "medium" or "short" (responsive
variant, when available).
| Name | Required | Description | Default |
|---|---|---|---|
| horizon | No | medium | |
| weights | Yes | ||
| optimized | No | ||
| lookthrough | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden and it does: it discloses that ETF/mutual fund tickers are expanded into filed holdings before computation, that uncoverable funds surface in lookthrough.notes, and that optimized=true applies the Shepard second-order correction because optimizers exploit covariance noise. It lacks any note on cost, latency, or failure behavior for malformed tickers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The output summary is front-loaded in the first sentence and each subsequent sentence covers one parameter, so the structure is easy to scan. It is dense with parentheticals and slightly long for four parameters, but nearly every clause carries non-obvious information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by naming the returned sections (total/factor/specific vol, factor exposures, top variance and asset risk contributions, lookthrough.notes). Combined with the semantics for all four parameters and the nested weights object, an agent has enough to call this correctly; only error/edge behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for all four parameters and it does: weights is defined as ticker -> portfolio weight, lookthrough and optimized each get their effect and default implication, and horizon is given its allowed values ('medium' or 'short'). No parameter is left for the agent to guess at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full risk report for a portfolio') and enumerates the report's contents, so an agent knows exactly what comes back. It never names or contrasts against siblings like get_etf_risk or get_factor_exposures, so sibling differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives real conditional guidance for options ('set lookthrough=false to disable', 'set optimized=true if the weights came from optimizing against this model'), which is genuine when-to-use information. However it never says when to pick this tool over get_etf_risk, get_factor_exposures, or stress_test, so routing between siblings remains inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catalog of published model builds (the versioned registry): release tag, model version, publish date, available horizons, and artifact download URLs. The hosted server always serves the latest build; any historical build can be downloaded by its tag's asset URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden; it does disclose the meaningful server behavior (latest build served by default, historical builds accessible via tag-asset URLs) and implies a non-mutating read. It does not discuss auth/rate limits, but for a read-only catalog that is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences: the first front-loads what the tool returns, the second adds the necessary behavioral nuance about latest vs historical builds. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description enumerates the return fields and clarifies how historical artifacts are associated with tags, which gives an agent a clear picture. The only real gap is the unaddressed `limit` parameter, but that is minor for an optional single-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverrage at 0%, the description needed to clarify the optional `limit` parameter, but it never mentions it. The meaning is only inferable from the parameter name and default value, which is weak compensation for a low-coverrage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource (published model builds / versioned registry) and enumerates the returned fields, making it distinct from get_model_info and the other siblings. Though 'Catalog' is nominal rather than a verb, the intent to list is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when a caller needs the roster of model versions or historical artifact URLs, but it never explicitly states when to choose it over get_model_info or any other sibling. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate portfolio P&L under factor shocks (return units: -0.10 = -10%). Example: {"market": -0.10, "momentum": -0.05}. Use get_model_info for valid factor names.
| Name | Required | Description | Default |
|---|---|---|---|
| horizon | No | medium | |
| weights | Yes | ||
| factor_shocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful context by specifying return units (-0.10 = -10%) and giving an example input. However, it does not mention whether the operation is read-only, whether invalid factor names cause errors, or any other side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, with the core purpose front-loaded. Every sentence adds value: the units clarification prevents misinterpretation, the example shows the exact input shape, and the get_model_info pointer gives a necessary prerequisite. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, nested objects, and zero schema description coverage, so the description must be more complete. It gives a good example for factor_shocks but omits the meaning of weights and horizon, and never describes the result structure or behavior when inputs are invalid. An agent would likely need to inspect other sources or make unsafe assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for all parameters. It explains factor_shocks reasonably through the example and return units, but it leaves 'weights' and 'horizon' completely unexplained. Weights is required and its mapping semantics are not described at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Estimate portfolio P&L under factor shocks.' It is specific enough to separate this from generic risk tools, but it does not explicitly name or distinguish itself from siblings like get_portfolio_risk or get_factor_exposures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case through the phrase 'under factor shocks' and provides a concrete example, but it does not explicitly state when to prefer this tool over alternatives. It does instruct the agent to 'Use get_model_info for valid factor names,' which is a useful prerequisite but not a when-not-to-use guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.9.2get_etf_riskget_portfolio_risk1 field changedInput schema / properties / lookthroughAdded value: +{
+ "default": true,
+ "title": "Lookthrough",
+ "type": "boolean"
+}v0.9.1check_coverageget_factor_exposuresget_model_infoget_portfolio_risklist_model_versionsstress_testScored across 7 tools
Most tools target distinct actions: check_coverage checks ticker coverage, get_factor_exposures returns per-asset exposures, get_portfolio_risk returns a full portfolio report, and stress_test applies factor shocks. However, get_model_info also reports asset coverage count, which slightly overlaps with check_coverage, and get_portfolio_risk duplicates some get_factor_exposures output. Descriptions clarify boundaries, so misselection is unlikely.
All names use snake_case with a verb_noun pattern (check_coverage, get_factor_exposures, list_model_versions, etc.). stress_test is the only minor deviation from the get_* prefix but still fits the verb_noun convention. Consistent and predictable throughout.
Seven tools is well-scoped for a risk-model analytics server. Each tool addresses a distinct capability—coverage, exposures, metadata, versions, portfolio risk, ETF look-through, and stress testing—without redundant endpoints.
Core workflows are covered: coverage checks, model metadata/versions, per-asset exposures, portfolio/ETF risk, and stress testing. Minor gaps include no direct factor covariance/correlation retrieval or historical backtesting, though these are mostly available indirectly or outside the stated scope.
Production MCP server for US equity and options intelligence: real-time IV radar, Monte Carlo simulation, options pressure, strategy backtesting, AI prediction, pre-trade risk analysis, and automated stock research reports.
Portfolio risk analytics — VaR, Monte Carlo, optimization, options Greeks, stress testing.
HPSILab Quant finance MCP for US stocks, ETFs, options, Monte Carlo, backtesting, and risk analysis.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
