For agents & agentic teams
Built for the deal team — and its agents.
The people who model deals increasingly work alongside AI agents that read documents, draft memos, and pull data. Merger Waterfall gives those agents the waterfall engine as a tool: a stateless REST API and a remote MCP server that compute the exact, audited answer and keep nothing.
AI connector
Your deals, inside the assistant you already use.
Opening soon on every plan. Connect Claude, ChatGPT or any MCP client to Merger Waterfall, sign in, and ask about your deals.
What it can do
Opening soon · every plan- list_deals — The deals you can see, with each one's latest Net Equity Proceeds.
- get_deal_terms — A deal's current terms, each with when it last changed and its source document.
- list_runs — The deal's runs, which are locked, and how many terms changed since each.
- get_run_distribution — Who receives what in a run, by class and by holder, at closing or in total.
- compare_runs — What moved between two runs and which terms changed in between.
- explain_run — A plain-English walk through how proceeds flowed, from the engine's own trace.
- run_waterfall (adds a run) — A new run with the deal's current terms. Adds a run; changes no term, removes nothing.
Connect
- ClaudeAdd a custom connector with https://studio.mergerwaterfall.com/api/mcp, then Connect and sign in with your Merger Waterfall account.
- Claude Codeclaude mcp add --transport http merger-waterfall https://studio.mergerwaterfall.com/api/mcp
- ChatGPTAdd a connector (developer mode) with https://studio.mergerwaterfall.com/api/mcp and sign in.
- Cursor and other MCP clientsPoint the client at https://studio.mergerwaterfall.com/api/mcp; it opens the Merger Waterfall sign-in.
What you can rely on
- ▸ Sign in with your Merger Waterfall account (OAuth); no keys to paste.
- ▸ It sees only the deals your account can see, with your role on each: viewers read, editors can also run.
- ▸ Holders appear as codes unless the deal's owner turns names on for that deal.
- ▸ Every number comes from the deterministic engine's saved runs; the assistant never recomputes payouts.
- ▸ It can't edit terms, lock or close a deal, delete anything or share links.
The pattern
Context, compute, confirm.
Agents are good at gathering and drafting. The waterfall is exact math. People own the calls that matter. Merger Waterfall is built so each does the part it's best at.
Context
Agents read how the model works
An agent grounds itself in how the waterfall is actually computed — seniority, participation, caps, the conversion election — instead of guessing. The site is agent-legible today through llms.txt.
Compute
Agents call the engine
Hand Merger Waterfall the consideration, the bridge, and the cap table; get back a deterministic, fully-audited waterfall. A language model shouldn't do preference arithmetic — it should call something that does it the same way every time.
Confirm
Humans sign off on what matters
The inputs the deal turns on — the term-sheet reading, the caps, the escrow and earnout terms — are confirmed by a person before the numbers go out. Agents draft and assemble; people confirm the critical data. Every figure keeps its trail.
Why a tool, not a guess
The waterfall is math, not a judgment call.
Liquidation preferences, capped participation, and the as-converted election are exact, iterative calculations. Get one tier wrong and every number below it is wrong — quietly.
That's a poor fit for a model that predicts the next token, and a good fit for an engine that solves the stack the same way every time and shows its work. When an agent calls Merger Waterfall, the answer is reproducible and traceable to the tier it came from — the same engine, and the same number, a person gets in Studio.
What the agent gets back
- ▸ Deterministic per-class and per-holder proceeds
- ▸ MOIC per holder, and which classes convert
- ▸ A balance check and the full step-by-step audit trace
- ▸ With escrow: the payout at close and after each release
A realistic flow
One deal, an agent and its human, end to end.
The critical inputs stay human-confirmed. The exact math stays in the engine. The agent does the rest.
An agent reads the term sheet and draft cap table, and pulls out the consideration mix, the bridge items, and each class's terms.
It hands those inputs to Merger Waterfall's engine, which computes the waterfall deterministically — preferences, participation, caps, conversions — with a full audit trail.
A person confirms the figures the deal turns on: the preference multiples, the caps, the escrow and earnout terms.
The agent drafts the stakeholder summary and the board exhibit — every number traceable to its tier, and shareable as a read-only link.
On the $15.00M example, the engine returns $11.85M distributed across four classes with zero converting — the same result the how-it-works walkthrough shows a person building by hand.
Ways to plug in
Four surfaces, clearly labeled.
The connector is built and opens soon, on every plan; llms.txt is live; the API and MCP compute tools are built and open soon, as part of Enterprise. We'd rather tell you exactly where each stands than imply more than ships today.
AI connector
Your own deals inside Claude, ChatGPT and other assistants: sign in with your Merger Waterfall account and ask about terms, runs and who receives what. Holders stay codes by default.
How the connector works →llms.txt
A plain-text map of the site, the methodology, and the canonical deal — for any agent that reads it.
Read /llms.txt →MCP server
A remote MCP server (Streamable HTTP) with four tools: compute_waterfall, get_input_schema, validate_captable and explain_result. Point Claude, or any MCP client, at it with an API key.
Setup for Claude, ChatGPT and custom agents →REST API
One POST computes a waterfall from JSON. Described in OpenAPI 3.1, generated from the same contract the engine validates against.
OpenAPI document →Connect
Endpoints, keys and limits.
Enterprise includes 10,000 compute calls a month, shared by every key on the account. Keys are created in Studio and shown once.
Endpoints
- POSThttps://studio.mergerwaterfall.com/api/v1/waterfall/compute
- POSThttps://studio.mergerwaterfall.com/api/mcp
- GEThttps://studio.mergerwaterfall.com/api/v1/schema
- GEThttps://studio.mergerwaterfall.com/api/v1/openapi.json
MCP tools
- compute_waterfall — Run the engine on a cap table and proceeds: per-class and per-holder payouts, MOIC, balance check, audit trace.
- get_input_schema (free) — The input JSON Schema, engine version and size limits.
- validate_captable (free) — Check a cap table against the contract and flag modeling problems, without running it.
- explain_result (free) — Walk through a result step by step from its audit trace. Deterministic; no language model.
Claude Code, in one line
claude mcp add --transport http merger-waterfall https://studio.mergerwaterfall.com/api/mcp \ --header "Authorization: Bearer $MW_API_KEY"
What you can rely on
- ▸ Stateless: the deal you send is computed and returned; it is not stored, and request bodies are never logged.
- ▸ Deterministic: the same input always returns the same result, with a step-by-step audit trace.
- ▸ Only a valid computation is metered; malformed input, schema, validation and explanation calls are free.
- ▸ Seniority: lower rank = more senior; equal ranks share a shortfall pro rata (pari passu).
- ▸ Use codes (S-001) for holders and no personal data needs to leave your side.
Per call: up to 200 classes, 5,000 holders, 50,000 issuances and 50 escrow tranches; body up to 1 MB. Full developer docs →
Building with agents?
The MCP server and API open soon, as part of Enterprise. Get on the list and we'll bring you in first.