cashflow-mcp-server

Stress-test a contract

cashflow_run_sensitivity

Read-onlyIdempotent

Stress-test a contract against volume, price, cost, and escalation scenarios, then compare each scenario's IRR, NPV, and payback to the base case.

Instructions

Re-evaluate a contract under a set of scenarios and report each one against the base case.

Five scenarios run by default: volume -20%, volume -10%, volume +20%, no price indexation, and operating cost +10%. Pass your own scenarios to override them.

Volume is listed first on purpose: a volume forecast taken from a customer's own estimate is a negotiating position, not a measurement, and it is the assumption that breaks most often.

Args:

model (object): The contract, same shape as cashflow_evaluate_contract.
scenarios (array, optional): Custom scenarios. Each has id, label, and any of volumeFactor, priceFactor, costFactor, revenueEscalation, costEscalation.
response_format ('markdown' | 'json'): Default 'markdown'.

Returns: base (the unmodified case) and scenarios[], each with irrAnnual, npv, paybackMonth, irrDeltaPoints (percentage points against base, null when either side has no IRR) and npvDelta.

Examples:

Use when: "What happens to this deal if volume comes in 20% under plan?"
Use when: "How fragile is the return to the inflation clause?"

Input Schema

TableJSON Schema

Name	Required	Description	Default
`model`	Yes
`scenarios`	No	Custom scenarios. Omit to use the five defaults.
`response_format`	No	'markdown' for a readable report, 'json' for the full structured result. Structured data is returned either way in structuredContent.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`base`	Yes
`scenarios`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral detail: the five default scenarios, the fact that custom scenarios override them, the emphasis on volume as the most fragile assumption, and the return semantics (base case unmodified, deltas in percentage points, null IRR handling). No contradiction with annotations.

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 well-organized with Args, Returns, and Examples sections, front-loading the purpose and default behavior. The extended note about volume is somewhat digressive but still adds useful domain context. Overall, every section earns its place with minimal filler.

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

Completeness4/5

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

Given the complex nested schema and existing output schema, the description is quite complete: it covers default scenarios, override behavior, return fields, and example use cases. It stops short of explicitly routing to sibling tools or stating exclusions, which would make it fully complete.

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

Parameters4/5

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

Schema coverage is 67%, and the description compensates well. It describes the model as 'same shape as cashflow_evaluate_contract', lists scenario fields succinctly, and explains response_format options. This goes beyond the raw schema entries by clarifying the relationship to other tools and the effect of custom scenarios.

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

Purpose4/5

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

The description clearly states the tool's function: 'Re-evaluate a contract under a set of scenarios and report each one against the base case.' This is a specific verb+resource that distinguishes it from a simple single evaluation, though it does not explicitly name sibling tools to differentiate itself.

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 provides explicit 'Use when' examples, such as 'What happens to this deal if volume comes in 20% under plan?' and 'How fragile is the return to the inflation clause?'. This gives clear context for when the tool is appropriate, but it does not mention alternatives or when-not-to-use conditions.

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

Deploy Server