Click on "Install 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., "@risk-analytics-mcp-server Compute 99% VaR for a 60/30/10 equity/bond/gold portfolio."
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.
An MCP server that gives AI agents quantitative risk tools.
Any MCP client (Claude Code, Claude Desktop, or your own agent) gets seven tools backed by two real engines — market-risk-engine and credit-risk-model:
Tool | What it does |
| Portfolio VaR & Expected Shortfall four ways — historical, parametric-normal, Cornish-Fisher, Monte Carlo — so the agent can compare methods, not just get a number. |
| GARCH(1,1) fit by maximum likelihood (no |
| Walk-forward VaR backtest with Kupiec POF, Christoffersen independence / conditional-coverage tests, and the Basel traffic-light zone. |
| Preset crisis-shock library (GFC equity crash, 2020 pandemic, +200bp rates, flight to quality, USD squeeze) + the portfolio's own worst historical windows. |
| Peaks-over-threshold GPD tail fit; EVT VaR/ES for the 99.5%+ region where empirical quantiles run out of data. |
| 12-month PD, scorecard points and letter rating from a WoE logistic scorecard (PDO points scaling). |
| The scorecard's held-out AUROC/Gini/KS and per-feature Information Values. |
Every market tool works with no data at all — omit the returns and it
runs on a seeded 4-asset synthetic demo book (EQUITY/BOND/GOLD/FX, ~5
trading years), so an agent can explore the tools fully offline. Pass your
own daily returns (fractions, 0.01 = 1%) to analyze a real portfolio.
VaR/ES are reported as positive daily loss fractions.
The credit scorecard is trained once per process on the engine's seeded synthetic 12k-loan book and cached; the methodology (monotonic WoE binning, logistic regression, points scaling, ratings) is the production pattern, the score itself is a demo.
pip install git+https://github.com/chenxi-bot21/risk-analytics-mcp-server.gitClaude Code:
claude mcp add risk -- risk-mcpClaude Desktop / any MCP client (stdio transport):
{
"mcpServers": {
"risk": { "command": "risk-mcp" }
}
}Or without installing, via uv:
{
"mcpServers": {
"risk": {
"command": "uvx",
"args": ["--from", "git+https://github.com/chenxi-bot21/risk-analytics-mcp-server.git", "risk-mcp"]
}
}
}Related MCP server: Black-Litterman Portfolio Optimization MCP Server
"What's the 99% VaR of a portfolio that's 60% equity, 30% bonds, 10% gold? Compare methods — do the tails look fat?"
"Backtest a 99% historical VaR on these returns and tell me which Basel zone it lands in." (paste returns)
"Score this applicant: 24 years old, $25k income, $30k loan at 26%, DTI 42, utilization 130%, 4 delinquencies…"
src/risk_mcp/
├── market.py # JSON-friendly wrappers around marketrisk (pure functions)
├── credit.py # cached synthetic-trained WoE scorecard + scoring
└── server.py # FastMCP registration shim — no logic of its ownThe wrappers are plain functions with plain-type signatures, so the whole surface is unit-tested (19 tests) without a running server; one test drives a tool through the actual MCP protocol layer.
python -m unittest discover -s tests -t .MIT.
Walk-forward VaR backtest (no look-ahead): Kupiec proportion-of-failures,
Christoffersen independence/conditional-coverage tests, and the Basel
traffic-light zone. method is 'historical' or 'parametric'. Needs more
than window+30 observations; omit returns to use the demo portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | ||
| method | No | historical | |
| window | No | ||
| returns | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions no look-ahead, required data length, and demo portfolio behavior. However, with no annotations, it lacks details on side effects, permissions, or error handling.
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 sentences with no redundancy; essential information is front-loaded and each sentence adds value.
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?
Lacks output description for the backtest results (e.g., what the tests return). With no output schema, this is a notable gap.
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?
Explains method values ('historical' or 'parametric'), window in context of data requirement, and returns usage. But alpha is not described despite 0% schema coverage.
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 tool as a walk-forward VaR backtest with specific statistical tests and the Basel traffic-light zone. It uses strong verbs and distinguishes from siblings like compute_var_es and stress_test.
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?
Provides a prerequisite (needs > window+30 observations) and a shortcut (omit returns for demo portfolio), but does not explicitly contrast with sibling tools or state when to use this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Portfolio VaR and Expected Shortfall by four methods (historical,
parametric-normal, Cornish-Fisher, Monte Carlo) at confidence alpha.
asset_returns maps asset name -> equal-length list of daily returns;
weights defaults to equal. Omit both to use the demo book. Divergence
between historical and normal VaR is the fat-tail signal.
| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | ||
| weights | No | ||
| asset_returns | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It explains the computation methods, input constraints (equal-length return lists, default weights, demo book fallback), and hints at output interpretation (divergence as fat-tail signal). It does not detail return format, but given the tool's computational nature, the description provides sufficient transparency for appropriate use.
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 extremely concise, consisting of three short sentences. The first sentence establishes the core purpose, the second specifies input structure, and the third adds an interpretive note. Every sentence adds value with no redundancy or 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?
Given the tool's moderate complexity (four methods, portfolio inputs) and lack of output schema, the description covers inputs, defaults, methods, and even provides an interpretation hint. It does not describe the return format, which would be helpful, but overall it provides enough context for an agent to understand how to invoke and interpret results.
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?
Input schema has 0% description coverage, yet the description fully explains all three parameters: alpha as confidence level (default 0.99), asset_returns as object mapping asset names to equal-length return arrays, and weights defaulting to equal allocation. It also explains the demo book behavior when both are omitted. This adds substantial meaning beyond the raw schema types.
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 states it computes VaR and Expected Shortfall by four named methods (historical, parametric-normal, Cornish-Fisher, Monte Carlo) at a specified confidence level. It distinguishes itself from sibling tools like backtest_var, evt_tail_risk, and garch_volatility by focusing on standard VaR/ES computation rather than backtesting, extreme value theory, or volatility modeling.
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 explains the tool's function and input requirements but does not explicitly state when to use this tool over alternatives. It implies usage for portfolio risk measurement but lacks guidance on when to choose this method over other risk tools among siblings. The note about divergence as a fat-tail signal offers some interpretive context but not usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadata for the credit scorecard: held-out AUROC/Gini/KS, per-feature Information Values, and the valid categorical inputs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the tool returns metadata but does not explicitly confirm it is read-only or non-destructive. Given the tool's nature, it is likely safe, but the description lacks explicit statements about side effects, authentication, or rate 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, well-structured sentence that front-loads the key concept ('Metadata for the credit scorecard') and then lists specific metrics. Every part adds value, and there is no redundancy or waste.
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 tool has zero parameters, no output schema, and no annotations, the description provides adequate context by listing the key output components (held-out AUROC/Gini/KS, per-feature IV, valid categorical inputs). It does not specify the output format, but the list is sufficient for an agent to understand what the tool returns.
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?
The input schema has zero parameters, and schema coverage is 100% (trivially). With 0 parameters, the baseline is 4. The description does not need to add parameter details, but it implicitly explains the output content which is the tool's purpose.
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 states the tool provides metadata for a credit scorecard, listing specific metrics (AUROC, Gini, KS, Information Values) and valid categorical inputs. It uses a specific verb-resource combination and distinguishes itself from sibling tools which focus on risk measures and scoring.
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 usage context by naming the specific metrics, but does not explicitly state when to use this tool versus siblings like 'score_credit_application' or 'backtest_var'. No guidance on prerequisites or alternatives is provided, though the tool's self-contained nature (no parameters) reduces the need for extensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extreme-value tail analysis: fit a Generalized Pareto to losses beyond
the threshold_q quantile (peaks-over-threshold) and report EVT VaR/ES at
alpha (use for 99.5%+ where empirical quantiles run out of data).
| Name | Required | Description | Default |
|---|---|---|---|
| alpha | No | ||
| returns | No | ||
| threshold_q | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It describes the statistical method but does not mention whether the tool is read-only, computationally intensive, modifies state, or requires specific permissions. The agent lacks information about side effects or prerequisites.
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, well-structured sentence with no extraneous words. It front-loads the core purpose and method, making it easy to parse.
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 description explains the method and outputs (EVT VaR/ES) but does not describe the return format or structure. Given the tool is a statistical analysis with three parameters and no output schema, more detail on the output (e.g., vector, data frame) would improve completeness.
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. It explains that 'threshold_q' is the quantile threshold for fitting and 'alpha' is the confidence level for VaR/ES. However, it does not describe the 'returns' parameter or provide formatting details beyond defaults. The description adds some context but is incomplete.
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 states the tool performs 'Extreme-value tail analysis' using Generalized Pareto distribution and reports EVT VaR/ES, specifying the method and outputs. It implies differentiation from siblings by noting suitability for 99.5%+ confidence levels, but does not explicitly distinguish from sibling tools like compute_var_es.
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 provides explicit guidance: 'use for 99.5%+ where empirical quantiles run out of data'. It gives a clear context for when to apply this tool, but does not mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit GARCH(1,1) by maximum likelihood to a daily return series (>= 250
obs) and forecast volatility forecast_horizon days ahead (mean-reverting
to long-run vol). Omit returns to use the demo portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| returns | No | ||
| forecast_horizon | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the model type (GARCH(1,1)), estimation method (MLE), data requirement, forecast behavior (mean-reverting), and demo option. No annotations provided, so description fully responsible; covers key behavioral aspects.
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 sentences, front-loaded with main purpose, no redundant words. Every sentence adds value.
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?
Covers model, estimation, data requirements, and demo. Lacks explicit output format (though implied as volatility forecast). With no output schema, describing return format would improve completeness.
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?
Adds meaning beyond schema: explains `returns` as daily return series and optional demo, `forecast_horizon` as days ahead with default. Schema coverage is 0%, so description compensates effectively.
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?
Clearly states it fits GARCH(1,1) to daily returns and forecasts volatility, specifying data requirement and demo portfolio. Distinguishes from siblings like evt_tail_risk and compute_var_es.
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?
Provides context on when to use (volatility forecasting) and data prerequisites (>=250 obs). Implicitly distinguishes from siblings, but lacks explicit when-not-to-use or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a retail loan application on a WoE logistic PD scorecard: 12-month probability of default, scorecard points (higher = safer) and a letter rating. Demo model trained on a synthetic book — methodology is production-style, the score is not a production score.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | ||
| dti | Yes | ||
| purpose | No | debt_consolidation | |
| loan_term | Yes | ||
| loan_amount | Yes | ||
| annual_income | Yes | ||
| interest_rate | Yes | ||
| home_ownership | No | RENT | |
| employment_length | Yes | ||
| num_open_accounts | Yes | ||
| credit_history_length | Yes | ||
| num_delinquencies_2yr | Yes | ||
| revolving_utilization | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool is a demo, trained on synthetic data, and methodology is production-style but output is not production. This is crucial behavioral context. It does not discuss destructiveness or auth, but the tool is read-only and no destructive hint is needed.
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 sentences, front-loaded with the action and key outputs. Every word adds value; no redundancy. Perfectly concise.
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 13 parameters, no output schema, and no parameter descriptions, the description is incomplete. It omits return value format, parameter constraints, and usage examples. The demo note partially offsets, but integration still requires guessing input semantics.
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% and the description provides no meaning for any of the 13 parameters (11 required). It does not explain units, valid ranges, or how parameters map to the scorecard. This is a critical gap for correct invocation.
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 uses a specific verb 'Score' with a clear resource 'retail loan application' and explicitly lists outputs (probability of default, scorecard points, letter rating). It distinguishes from sibling tools which focus on portfolio-level risk metrics like VaR, ES, or stress testing.
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 states it's a 'demo model' and 'not a production score', providing context on when to use (scoring single applications) and when not to rely on it (production decisions). It does not list explicit alternatives, but sibling tools are sufficiently different to imply usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stress the portfolio two ways: a preset crisis-shock library (GFC-style
equity crash, 2020 pandemic, +200bp rates, flight to quality, USD squeeze)
and the portfolio's own worst horizon-day historical windows.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| horizon | No | ||
| weights | No | ||
| asset_returns | No |
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 states the stress methods but fails to disclose side effects, data requirements, or whether the tool is read-only. For a risk calculation, more transparency is needed.
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 sentence, concise and front-loaded, but omits important details like parameter explanations and output format. It is not wasteful, but its brevity compromises completeness.
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 tool has 4 parameters with no output schema and no annotations, the description is highly incomplete. It does not explain how parameters relate, what the output represents, or prerequisites like historical data format.
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%. The description only mentions 'horizon' with backticks, leaving 'top', 'weights', and 'asset_returns' unexplained. This adds no meaningful parameter semantics beyond the schema's type information.
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 states the tool 'stresses the portfolio' using two specific methods: preset crisis shocks (e.g., GFC, pandemic) and historical worst windows, distinguishing it from sibling tools like compute_var_es or backtest_var.
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 usage for stress testing but does not explicitly contrast with sibling tools or provide when-to-use vs. when-not-to-use guidance. The two methods are described, but no exclusions or alternatives are mentioned.
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. Dates show when Glama detected each change.
v0.1.0backtest_varcompute_var_escredit_model_summaryevt_tail_riskgarch_volatilityscore_credit_applicationstress_testEach tool targets a distinct area of risk analytics: VaR computation, backtesting, credit scoring, EVT, GARCH, stress testing, and credit model metadata. No two tools overlap in purpose.
All names use lowercase with underscores, but some follow a verb_noun pattern (e.g., backtest_var, compute_var_es) while others are noun phrases (e.g., credit_model_summary, garch_volatility). This minor inconsistency does not hinder readability.
Seven tools cover the core risk analytics workflow without being excessive. Each tool earns its place, covering computation, backtesting, credit risk, and stress testing.
The set covers key risk functions: VaR/ES estimation, backtesting, volatility modeling, tail risk, credit scoring, and stress testing. Missing features like data ingestion or portfolio optimization are minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build, backtest, and deploy quantitative trading strategies from your AI agent.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
45 AI data tools for agents — crypto, DeFi risk, audits, equities, energy, and more.
Market intelligence for AI agents. Real-time data, cross-market analysis, and regime detection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chenxi-bot21/risk-analytics-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
