Query a Barra-style US equity factor risk model for portfolio risk, factor exposures, stress tests, coverage, and model build metadata.
Get model info: version, as-of date, factor list, coverage count, and available horizons (medium or short).
Compute full portfolio risk: total/factor/specific vol, factor exposures, top factor and asset risk contributions; supports an optimized flag for Shepard second-order correction.
Retrieve per-asset factor exposures and total/factor/specific vol for a list of tickers.
Run stress tests: estimate portfolio P&L under factor shocks (e.g., {"market": -0.10, "momentum": -0.05}).
Check coverage: determine which tickers the current model build covers.
List published model versions: release tag, model version, publish date, available horizons, and artifact download URLs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@riskprism stress test my portfolio against a market crash"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Decompose US equity portfolio risk into its factor spectrum.
Explorer: https://risk-prism-production.up.railway.app · Agent model card: /model.md
An open-source, Barra-style fundamental factor risk model built to be usable by AI agents out of the box: a Python library, an MCP server, and weekly-published model artifacts covering most liquid US common stocks.
9 style factors (size, value, growth, momentum, beta, volatility, liquidity, quality, leverage — value, quality and leverage are multi-descriptor composites, volatility is beta-orthogonalized residual volatility) + 30 industries (Fama-French scheme) + a market factor
Free, redistributable data chain: fundamentals and SIC codes from SEC EDGAR (public domain), prices from pluggable providers
Hybrid distribution: precomputed artifacts (exposures, factor covariance, specific risk) are published on a weekly schedule, and the full pipeline is open so anyone can reproduce or extend them
Disclaimer: research software, provided as-is. Nothing here is investment advice.
The live deployment serves a JSON API over the newest weekly build — interactive docs at /api/docs:
curl -s -X POST https://risk-prism-production.up.railway.app/api/v1/portfolio-risk \
-H 'content-type: application/json' \
-d '{"weights": {"AAPL": 0.4, "MSFT": 0.4, "XOM": 0.2}}'Endpoints: GET /api/v1/meta · GET /api/v1/factors ·
GET /api/v1/assets/{ticker} · GET /api/v1/funds/{ticker} (ETF
look-through) · GET /api/v1/coverage?tickers=… ·
POST /api/v1/portfolio-risk · POST /api/v1/stress-test ·
GET /api/v1/registry (catalog of published builds). Same surface
as the MCP server; self-host it with pip install ".[api]" && riskprism-api
(artifacts auto-download from the latest release at boot). Details in
docs/API.md.
Related MCP server: Portfolio Rotation MCP Server
Hosted — no install, serving the newest weekly build:
{
"mcpServers": {
"riskprism": {
"type": "http",
"url": "https://risk-prism-production.up.railway.app/mcp"
}
}
}Or local, from the installed package and downloaded artifacts:
{
"mcpServers": {
"riskprism": {
"command": "riskprism-mcp",
"env": { "RISKPRISM_ARTIFACTS": "/path/to/artifacts" }
}
}
}Tools exposed: get_model_info, get_portfolio_risk, get_etf_risk,
get_factor_exposures, stress_test, check_coverage,
list_model_versions. Weights are portfolio weights (shorts negative);
volatilities are annualized decimals.
ETFs and mutual funds work through holdings look-through: a fund ticker resolves to its latest SEC N-PORT filing, and the risk math runs on the constituents the model covers (docs/DECISIONS.md §17). When the model covers less than half of a fund's holdings — bond funds, international funds — no estimate is given, by policy.
pip install riskprism
python -c "from riskprism.registry import download_artifacts; download_artifacts()"This resolves the newest model-* release and unpacks its artifacts
into ./artifacts (any historical build downloads by tag the same way).
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})
# ETF look-through (fetches N-PORT holdings from SEC EDGAR):
# export RISKPRISM_EDGAR_UA="your-project (you@example.com)"
from riskprism import fund_risk, portfolio_risk_lookthrough
fund_risk(model, "IVV") # one fund
portfolio_risk_lookthrough(model, {"VTI": 0.7, "AAPL": 0.3}) # mixedpip 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_KEYThe weekly GitHub Action runs exactly this and publishes the artifact
directory; see .github/workflows/build-model.yml.
A zero-backend static site (served on Railway, re-rendered by each weekly build) for exploring the model: cumulative factor returns, factor vol and correlations, a client-side portfolio risk sandbox with stress-test sliders, per-stock factor profiles, and a visual methodology walkthrough. All math runs in the browser on the embedded artifacts.
Agents get a plain-markdown mirror of every build at /model.md
(indexed by /llms.txt): model card, factor definitions, correlations,
and the full coverage list — no DOM parsing required.
Render everything locally:
riskprism-site --artifacts artifacts --out site # index.html + model.md + llms.txtComponent | Choice |
Horizon | Medium — weekly formation, daily estimation (annualized outputs) |
Estimation | Daily cross-sectional WLS (√cap weights) against Friday-formed exposures, cap-weighted industry constraint |
Factor covariance | EWMA on daily factor returns — vol half-life 84d, correlation 252d (~730 effective observations) — with Newey-West variance adjustment, correlation regularization, PSD repair, and a Volatility Regime Adjustment multiplier |
Specific risk | EWMA residual vol (NW-adjusted) blended with a structural (characteristic-based) prior by history length, Bayesian-shrunk toward size-decile means (q=0.1), with its own VRA multiplier |
Universe | Estimation: price ≥ $2, ADV ≥ $1M, 26w+ history · Coverage: everything alive ≥ $1, priors fill the gaps |
History | Capture-forward: weekly builds append to the prior release; delistings imputed, survivorship bias decays out |
Validation | Recomputed from full history every build: bias statistics, Mincer–Zarnowitz, realized-vol ratios — on market/style/industry/random baskets, six real factor ETFs, and portfolios optimized against the model itself |
Full methodology in docs/METHODOLOGY.md; design decisions and their rationale in docs/DECISIONS.md.
MIT for code. Published model artifacts are derived data built from SEC EDGAR (public domain) and third-party price providers — see docs/DECISIONS.md for the data-licensing discussion.
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.
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.
7-factor stock scoring MCP server. US/HK/CN, 74 stocks. Free + Premium (USDC/Base). x402 ready.
