Yes — if it is connected to the simulation engine rather than just asked about it. Through ModelRisk MCP, an AI assistant works directly on the live workbook in Excel: it builds the risk model, fits distributions to your data, runs the Monte Carlo simulation in ModelRisk, and reads back the results. Every number comes from the engine, not from the language model.
That distinction — between prompting an AI about risk modelling and connecting one to the modelling software — is the difference between advice and work, and it runs through everything in this article. Advice you must re-type and re-check saves some thinking time; an assistant that operates the actual tool saves the afternoon. ModelRisk MCP is, to our knowledge, the first shipping implementation of the connected approach for Monte Carlo simulation in Excel — open source, free, and published on GitHub.
The prompting workflow is by now familiar: ask a chat assistant to suggest risks your register might be missing, propose a distribution for an uncertain input, or sanity-check the assumptions in a model — then carry its answers into your spreadsheet by hand. Used carefully, it is genuinely helpful, and nothing here argues against it. But three structural limits are built into that pattern, and no amount of clever prompt writing removes them.
First, a language model answering from memory must be double-checked — every time. Chat assistants generate plausible text; they do not compute. Ask one for the 95th percentile of a lognormal distribution with given parameters and you receive a fluent, confident answer that may or may not be correct — and nothing in the answer tells you which. The same applies to statements about which functions and methods a piece of software supports. Careful practitioners therefore re-verify every claim before it enters a model, which claws back much of the time the assistant saved.
Second, advice has to be transcribed. A suggested distribution is only a suggestion until someone types it into a cell; a model structure sketched in a chat window still has to be rebuilt, formula by formula, in the workbook. Transcription costs time, introduces its own errors, and means the AI never actually touched the model that runs — so nothing it said is guaranteed to describe what was finally built.
Third, the data problem. To get useful advice you must paste model contents, figures and context into the chat — with all the anonymisation effort and policy caution that rightly follows. The more useful you make the conversation, the more of your model leaves the workbook.
The Model Context Protocol (MCP) — the open standard for connecting AI assistants to software through defined, typed tool interfaces — addresses all three limits at once. Instead of recalling facts about simulation software, the assistant calls the software; instead of describing a model, it builds one; instead of you carrying your spreadsheet to the conversation, the conversation reaches into the spreadsheet through a controlled interface. The assistant stops being a well-read colleague with no hands, and becomes an operator of the actual tool.
ModelRisk MCP exposes the working surface of ModelRisk as 57 tools the assistant can call — against the live workbook, with results flowing back for the assistant to reason over and act on. The capabilities group into five stages of real modelling work:
Behind the tools sits knowledge the assistant consults as it works: the full catalogue of over 1,400 ModelRisk functions, distribution-selection guidance, and a methodology reference that keeps the assistant's practice aligned with sound quantitative risk analysis — risk events modelled as risk events, correlation through copulas, fits made with parameter uncertainty. Guided workflows are built in as slash commands, from /build-risk-model (a nine-step guided build) to /audit-model, /interpret-results, /add-uncertainty and /import-legacy-model.
/build-risk-model
/audit-model
/interpret-results
/add-uncertainty
/import-legacy-model
The end product of every stage is a normal Excel workbook with ModelRisk functions in cells — readable, auditable, and exactly what you would have built by hand, minus the hours. Ask for a P80 and the P80 you get was computed by a simulation you can re-run yourself, in a workbook you can hand to a reviewer. The following examples show what this feels like in practice.
A cost engineer comes out of a risk workshop with notes: a capital estimate of eight line items, workshop ranges for the five uncertain ones, two discrete risk events (a permitting delay with roughly one chance in four, and possible ground-condition rework), and a warning that the three site-works items tend to move together. Turning those notes into a working simulation is normally an afternoon of careful, mechanical Excel work.
Connected to ModelRisk MCP, the assistant takes the notes as the brief. It plans the model and shows the plan; proposes a distribution for each uncertain item with its reasoning ("the workshop gave an asymmetric range — low 90, likely 100, high 135 — suggesting a right-skewed distribution such as a PERT"); writes the distributions into the estimate as ModelRisk functions; adds the two risk events with their probabilities and impact ranges; correlates the site-works items; marks total cost as the simulation output; runs the simulation; and reports back — the P50 and P80 of total cost, the contingency each implies against the base estimate, and a tornado chart ranking what drives the spread.
The engineer's role in this is judgement, not typing: challenge a range, reject a proposed distribution, ask "what happens to the P80 if we mitigate the permitting risk?" — and the assistant re-runs and answers with fresh engine output. Every choice it made is visible in the cells, so the review is a normal model review.
An analyst has three years of incident data — monthly counts and individual loss amounts — and wants next year's total-loss distribution for budgeting and insurance decisions. This is the classic frequency-severity problem, and it is exactly the kind of task where chat-window statistics are least trustworthy: fitting requires computation, not recollection.
Through MCP, the assistant points ModelRisk's fitting engine at the data: candidate frequency distributions fitted to the counts and ranked by information criteria, candidate severity distributions fitted to the loss amounts the same way — with the assistant explaining what the ranking means and where the fits disagree. It then composes the two into an aggregate loss distribution using ModelRisk's aggregate methods (Monte Carlo, Panjer or FFT as appropriate), simulates, and reports the budget-relevant numbers: expected annual loss, the 90th and 99th percentiles, and how much of the tail comes from loss frequency versus loss size.
The analyst gets in minutes what is normally a specialist's task — with the specialist's tools doing the mathematics, and the fitted parameters sitting in the workbook for an actuary to inspect.
Every team has one: the business-critical risk model built by someone who left, quietly feeding numbers into decisions nobody fully trusts. Auditing it by hand means tracing formulas cell by cell for a day — so it rarely happens.
Connected to the workbook, the assistant runs ModelRisk MCP's audit — 17 methodology and integrity checks — and reports what it finds: the structure of inputs and outputs, hard-coded constants sitting where uncertain inputs should be, risks folded into ranges where they should be discrete events, inconsistencies worth a human look. Ask it to go further and it proposes distributions for the inputs that should be uncertain, re-runs the simulation, and shows how the modelled picture changes. The /import-legacy-model workflow packages this whole path for models arriving from other tools or older practices.
An audit that never happened because it cost a day now happens because it costs a question.
A finance analyst has a store-expansion business case in Excel: revenue build-up, cost lines, an NPV at the bottom. It says €3.1M, and everyone in the approval meeting knows that number is somewhere between a hope and a commitment — without knowing which. The analyst has never run a Monte Carlo simulation.
With the workbook open, the analyst tells the assistant which cells they are unsure about and what they know about each ("footfall could be 20% below plan in year one; fit-out costs have come in up to 30% over on past sites"). The assistant turns each into an appropriate distribution — explaining its choice in plain language as it goes — wires the NPV as the output, simulates, and reports what the deterministic case never could: the probability the expansion loses money, the P10–P90 range of NPV, and which two assumptions drive most of the risk. The business case goes to the meeting with its hidden number on the table.
For an analyst new to simulation this doubles as training: every function the assistant wrote is visible, named and explained, and the methodology guidance it works from is the same guidance a specialist would apply.
Boards rarely ask for percentiles. They ask questions like: what would have to go wrong for this project to breach €50M? Answering that by hand means hunting through simulation output for the combinations of inputs that produce bad outcomes — tedious enough that the answer is usually an educated guess.
ModelRisk MCP makes it a direct question: the assistant runs a reverse stress test on the model, identifying which input combinations drive outcomes past the threshold, and reports the storyline — "breaches of €50M almost always involve the permitting delay occurring and site productivity in its bottom quartile; neither alone is sufficient." Follow-ups are conversational: sweep scenarios to compare mitigation strategies, decompose the remaining uncertainty into its sources, or backtest the model's earlier forecasts against what actually happened — each answered with engine output, not opinion.
When the meeting is tomorrow morning, the assistant assembles the drivers and executive reports from the current simulation — charts and findings generated from the model as it stands, not as it stood when someone last had time to update the deck.
The deepest problem with chat-only risk advice is that a language model generates plausible statistics; it does not compute them. Through MCP that failure mode is structurally removed for the numbers that matter: the assistant calls ModelRisk's functions, ModelRisk computes, and the assistant reports what the engine returned. Fitting results carry the engine's statistics; percentiles come from actual simulation samples; sensitivity rankings come from the actual runs.
The assistant can still be wrong in its judgements — a proposed range can be naive, a suggested distribution debatable — which is precisely why the analyst stays in charge and why everything the assistant does lands where judgement can see it: as functions in cells. A model built through conversation is not a conversation. It is a workbook, reviewable by exactly the process your models are reviewed by today. If the analysis matters enough to defend to a board, a regulator or a client, the artefact you defend is the same artefact it always was.
Letting software write into models raises fair governance questions, and ModelRisk MCP is engineered around them with nine layers of protection. The ones that matter most in practice: changes are previewed by default — the assistant shows what it intends to write before committing anything; every modification joins Excel's undo stack, so Ctrl+Z works exactly as you expect; bulk writes require explicit confirmation; the server never saves the workbook itself — saving stays a human act; it refuses to overwrite your existing non-ModelRisk formulas; and every write is recorded in an append-only audit log from which individual cells can be restored even after the undo history is gone.
For review-only situations there is a read-only mode that disables building and simulation entirely. And architecturally, everything runs locally: the server is a local process on your machine with no telemetry, the workbook stays in Excel, and the code itself is MIT-licensed open source on GitHub — your IT security team can read every line of what sits between the assistant and your spreadsheet.
Hours become minutes on the mechanical span. The work between judgements — writing distributions into cells, wiring outputs, re-running fits, regenerating charts, assembling the report — compresses to review time. The risk workshop stays; the transcription of its conclusions into a working model largely disappears. Teams that ration simulation to the biggest decisions because of the effort can afford to apply it to the next tier of decisions too.
The entry barrier drops without the standards dropping. A finance analyst who has never built a simulation can describe a forecast's uncertainties in plain language and get a correctly-constructed ModelRisk model to learn from — every function visible, every choice explained, and the methodology guidance built into the server keeping the construction honest. The assistant is a patient tutor that happens to produce working models; the example model library gives it and the analyst shared reference points.
Models stay current instead of decaying. Re-running an analysis after the estimate changes — historically the update that never happens — becomes a sentence: "update the model with the revised quantities and tell me what moved." Reports regenerate from the fresh run, not from last quarter's copy-paste.
Documentation happens by construction. Because the assistant works in the workbook, the workbook is always the single source of truth: assumptions as functions, fits with their statistics, outputs wired to the simulation, and the audit log recording who changed what. The gap between "the model" and "what we said about the model" — a classic audit finding — closes by itself.
Everything that made risk analysis credible before AI still does: deciding which risks are in scope, whether ranges reflect how similar work actually went, whether the correlations are causally plausible, and whether the results support the decision being taken. Those judgements are the reason a contingency or a P80 finish date can be defended, and no tool — AI or otherwise — supplies them.
Our advice to teams adopting the connected workflow is the same discipline we recommend everywhere: ranges and risks come from the people who own the work; the assistant's proposals are starting points to be challenged, not conclusions to be accepted; and the final model gets the same review it would get if a colleague had built it. The difference is that the review now starts an afternoon earlier.
Monte Carlo simulation is not the only analysis that benefits from a connected assistant. ModelChoice MCP — a separate open-source server, also on GitHub and installable with pip install modelchoice-mcp — gives the same treatment to decision analysis with ModelChoice: describe the decision — the choices, the uncertainties, the payoffs — and the assistant builds the decision tree directly on the worksheet, rolls it up, and runs the analyses that turn a tree into a decision: risk profiles, sensitivity, expected value of perfect information (EVPI), robustness and multi-criteria analysis.
pip install modelchoice-mcp
Because ModelChoice draws and manages the tree on the worksheet itself and re-solves it on every change, the assistant's edits are your edits: change a probability, add a branch, and the tree you see is always the tree that was solved. Paired with ModelRisk MCP in the same conversation, uncertain payoffs in the tree can come from simulated distributions — the two products, and the two connections, are designed to work together.
ModelRisk MCP is available now, free and open source (MIT licence). The quickest route on a machine with Python 3.11+ is two commands — pip install modelrisk-mcp then modelrisk-mcp install, which detects Claude Desktop or Claude Code and registers the server automatically. Prefer clicks to commands? Download the one-click .mcpb extension from the latest release and open it in Claude Desktop's extension settings; a standalone executable and manual configuration are also documented for other MCP-compatible clients such as Cursor and Zed. It runs on Windows 10/11 with Excel 2019 or newer and the ModelRisk add-in — the current ModelRisk version is recommended so the assistant can read simulation results directly.
pip install modelrisk-mcp
modelrisk-mcp install
.mcpb
Learning it is deliberately easy. The 15-minute quick-start tutorial takes you from installation to your first simulated model; the user manual covers each capability in depth; and the scenario recipes map common problems to conversations. A gallery of fifteen demo workbooks — store-expansion NPV, demand fitting, correlated costs, aggregate loss, reverse stress testing, board reporting — comes with step-by-step prompts; start with the first workbook and work along. And the simplest first session needs no preparation at all: open any workbook with ModelRisk functions and ask the assistant to "summarise the active workbook's risk model — inputs, outputs, distributions."
For the modelling methods themselves, the Monte Carlo simulation guide, the cost contingency guide and the frequency-severity guide cover the ground the assistant works on. The MCP server is free; it drives ModelRisk, which costs at most €1,550 per user per year with the complete feature set in one paid edition — and the fully functional 15-day free trial includes everything needed to try the whole workflow on your own models.
Yes — through ModelRisk MCP an assistant builds the model, fits distributions, runs the simulation in ModelRisk and reads back the results, all on the live Excel workbook. Every number comes from the engine, not the language model.
An open standard that lets AI assistants connect to software through defined, typed tool interfaces. Instead of answering from memory, the assistant calls real functions and reasons over the verified results they return.
Chat-only workflows produce advice that must be re-typed and re-verified, because models answering from memory can misstate statistics. Through MCP the work is executed in ModelRisk itself, the model stays a readable workbook, and there is nothing to transcribe.
Yes — the MCP server is free, open source (MIT) and published on GitHub and PyPI. It drives ModelRisk, which is licensed separately (at most €1,550 per user per year; 15-day free trial available).
No. Scope, ranges, correlations and decision judgements stay with the analyst — the assistant removes the mechanical work between them, and everything it does lands in an auditable workbook the analyst reviews.
It is engineered not to: changes are previewed before committing, every write joins Excel's undo stack, bulk writes need explicit confirmation, the server never saves the file itself, existing non-ModelRisk formulas are protected, and an append-only audit log allows cell-level restore. A read-only mode exists for review-only use.
The workbook stays in Excel on your machine; the MCP server runs locally with no telemetry, and the assistant works through its tool interface rather than ingesting the spreadsheet. The assistant sees what the tools return, so organisational AI policies still apply — but the paste-your-model-into-a-chat pattern is gone.
Yes — ModelChoice MCP (a separate free, open-source server) builds and edits decision trees directly on the worksheet, rolls them up, and runs risk-profile, sensitivity, EVPI, robustness and multi-criteria analyses, and it pairs with ModelRisk MCP in the same conversation.
pip install modelrisk-mcp then modelrisk-mcp install — or the one-click extension from the GitHub releases page for Claude Desktop. Windows 10/11, Excel 2019+ and the ModelRisk add-in are required; the 15-day free trial of ModelRisk includes everything needed to try it.
Connect your AI assistant to the simulation engine: describe the model, review what gets built, and read results the engine actually computed — starting with the 15-day free trial.