Skip to main content
Glama
vosesoftware

ModelRisk MCP

Official
by vosesoftware

reverse_stress_test

Identify inputs driving extreme output outcomes by partitioning simulation data into breach and no-breach sets, then reporting mean shifts and tail concentrations to reveal stress scenarios.

Instructions

ModelRisk: Reverse stress test — start from a BAD output outcome and work back to the joint input state that produces it. Partitions the simulation's iterations into breach / no-breach (output above/below a threshold, given directly or as a percentile), then for each input reports how far its mean shifts inside the breach set (in its own standard deviations) and how concentrated breaches are in its tail — a breach-driver tornado — plus the mean input vector as a concrete named stress scenario. This is the Solvency II / PRA 'reverse stress test' and is only possible with the engine's recorded per-iteration joint sample matrix (requires a completed simulation).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_nNoMax samples per variable to pull. Default 100000.
directionNoBreach side: 'above' (default) or 'below' the threshold.above
thresholdNoBreach threshold on the output. Omit to use threshold_percentile.
output_nameYesVoseOutput name to stress.
workbook_nameNoWorkbook name. Omit for the active workbook.
threshold_percentileNoBreach threshold as an output percentile (0-1), e.g. 0.95. Used when `threshold` is omitted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
driversYesInputs ranked by how far they shift in the breach set.
scenarioNoThe mean input vector over the breach iterations.
directionYes'above' or 'below' — the breach side of the threshold.
thresholdYes
iterationsYes
output_nameYes
breach_countYes
breach_probabilityYes
Behavior4/5

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

No annotations are provided, so the description carries full burden. It describes the behavior: partitioning iterations into breach/no-breach, reporting mean shifts and tail concentrations, and producing a tornado and mean input vector. It does not mention side effects, but given the read-only nature, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is densely packed with information and front-loaded with the key action. It is slightly verbose but every sentence adds value. It could be trimmed slightly, but generally well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool, the description covers inputs (threshold, percentile, direction, etc.) and outputs (tornado and mean input vector). It also explains the statistical approach and prerequisites. An output schema exists, so explanation of return values is not needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds minimal extra meaning beyond the schema. The description explains the overall partition logic but not details of individual parameters beyond what is already in the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Reverse stress test — start from a BAD output outcome and work back to the joint input state that produces it.' It expands on the method and distinguishes it from sibling tools by mentioning the specific Solvency II / PRA requirement and the need for a completed simulation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the prerequisite: 'requires a completed simulation.' This provides clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vosesoftware/modelrisk-mcp'

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