Monte Carlo cash-flow simulator for a small services business: odds of running short, and why.
Scored across 3 tools
list_presets is clearly a static reference, while rank_levers and simulate_cash_year are distinguished by comparative ranking versus single-scenario simulation. However, both simulation tools could be selected for a 'what if' question, creating mild overlap.
All tools use snake_case with a consistent verb_noun pattern: list_presets, rank_levers, simulate_cash_year. The naming is predictable and readable.
Three tools is lean but well-suited for the server's simulation purpose: one reference, one baseline simulation, and one sensitivity analysis. Each tool earns its place without redundancy.
Core workflows are covered: presets, baseline simulation, and lever ranking. A minor gap exists in directly comparing arbitrary custom scenarios side-by-side, though agents can work around it by calling simulate_cash_year multiple times.
List the six built-in business presets (excavation and septic, plumbing and drain, heating and cooling, landscaping and snow, roofing, and a general small services business) with every default input in the exact field names a simulation accepts, and the revenue, costs and profit each makes at its own averages. Static reference: no network access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description reinforces this with 'Static reference: no network access' and adds that results include precomputed averages (revenue, costs, profit), which is behavioral context beyond the annotations.
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?
Front-loaded with the verb and resource, and the trailing 'Static reference: no network access' fragment is a useful, cheap addition. The parenthetical enumeration of all six presets is long but arguably earns its place by telling the agent the exact coverage.
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?
With no output schema and no parameters, the description carries the return-value burden itself and does so: it names the presets, the default inputs, and the computed metrics returned. Nothing an agent needs in order to call this correctly is missing.
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 tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly implies no inputs are needed and instead describes the shape of what comes back.
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?
States a specific verb ('List') and resource ('the six built-in business presets'), then enumerates exactly which presets and what data accompanies them (default inputs, revenue, costs, profit). An agent can distinguish this from simulate_cash_year and rank_levers without opening any schema.
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?
Usage is only implied: 'in the exact field names a simulation accepts' hints this is a reference to consult before simulating, but there is no explicit when-to-use or when-not-to-use statement and no sibling is named. 'Static reference' gives some context but not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test nine single changes a small business owner can make and rank them by how much each lowers the chance of running short of money in the next 52 weeks, with the change in year-end money as a tiebreak. The levers: take a third up front, take 15 days off payment terms, raise prices 5 percent, take a fifth less owner draw for six months, cut overhead 10 percent, raise the credit line by half, run one crew lighter, add a crew, and buy three more enquiries a week. Each lever and the baseline run 3,000 simulated years with the same seed, so the difference is the lever and not the luck. Takes the same business description as a cash year simulation: a preset plus any overridden inputs. Pure arithmetic: no network access, nothing stored.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Business name, used only to label the result. | |
| seed | No | Seed for the random draws. The same inputs and seed always return the same answer. Default "dry-run". | |
| crews | No | Crews (or technicians, or production units) working in parallel. One crew delivers one crew-week a week. | |
| preset | No | Starting template: excavation, plumbing, hvac, landscaping, roofing, or general for any other small services business. Every field below overrides it. Default general. | general |
| leads_cv | No | Week to week spread of enquiries. Default 0.35. | |
| tax_rate | No | Share of profit set aside for tax, paid quarterly. | |
| job_types | No | The kinds of work sold. Replaces the preset list. | |
| surprises | No | Random setbacks such as a machine breakdown or someone quitting. Replaces the preset list. | |
| close_rate | No | Share of enquiries that become jobs, as a fraction. | |
| credit_apr | No | Annual interest on the drawn balance, as a fraction. 0.11 is 11 percent. | |
| start_cash | No | Money in the bank on the day the year starts, in dollars. | |
| credit_line | No | Size of the line of credit, in dollars. 0 for none. | |
| fixed_costs | No | Monthly fixed bills such as rent, insurance and equipment notes. Replaces the preset list. | |
| seasonality | No | Twelve multipliers on enquiry volume, January first. 1 is an average month. | |
| start_month | No | Month the simulated year starts, 1 for January. Default: the current month. | |
| credit_drawn | No | How much of the line is already drawn, in dollars. | |
| bad_debt_rate | No | Share of invoiced balances never collected, as a fraction. | |
| leads_per_week | No | Enquiries in an average week before seasonality. | |
| overhead_weekly | No | Weekly overhead that runs whether or not anyone works: office, software, admin wages. | |
| collection_shape | No | How disciplined customers are about paying on time: 2 is ragged with a long tail of late payers, 6 is disciplined. | |
| crew_cost_weekly | No | Fully loaded weekly cost of one crew: wages, burden, fuel, vehicle. | |
| owner_draw_weekly | No | What the owner takes out each week. | |
| opening_receivables | No | Work already invoiced and not yet paid on day one, in dollars. | |
| opening_backlog_weeks | No | Crew-weeks of work already sold and waiting to start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld=false, but the description adds real method context: every lever and the baseline run 3,000 simulated years on the same seed, so differences come from the lever, not luck. It also notes the computation is pure arithmetic with nothing stored. It stops short of flagging cost/runtime for ~30,000 simulated years, but the disclosure is well beyond the annotations.
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?
Front-loaded with the core action and ranking criterion, with no filler. The long lever enumeration earns its place because it defines the exact scope of what is tested, and the methodology rationale is compressed into two tight sentences.
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?
No output schema exists, so the description carries the return-value burden, and it does describe what is produced (a ranking of levers by shortfall probability with a money tiebreak). It lacks detail on the result's shape or the baseline row, but for a 24-parameter, zero-required tool it is otherwise complete.
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 100% with 24 fully documented parameters, so the schema does the heavy lifting and a 3 is the baseline. The description only adds a framing sentence ('a preset plus any overridden inputs'), which is a minor structural hint rather than new meaning about individual fields.
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?
States a precise verb+resource ('Test nine single changes ... and rank them') plus the exact ranking metric (lowering the chance of running short over 52 weeks) and tiebreak (change in year-end money). It enumerates all nine levers and explicitly frames itself against the sibling simulation ('Takes the same business description as a cash year simulation'), so it is distinguishable from simulate_cash_year without opening any schema.
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?
It establishes clear usage context by tying itself to the cash-year simulation inputs, implying it is the comparison counterpart to that tool. However, it never explicitly names simulate_cash_year or states when to prefer a single simulation over the lever ranking, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate the next 52 weeks of a small services business 10,000 times (Monte Carlo) and report the chance it runs short of money, the week that is most likely to happen, reachable money (bank balance plus unused credit) week by week at the 10th, 50th and 90th percentile, the drivers that separated the futures that ran short from the ones that survived, and the profit the business makes at its own averages. Start from a trade preset (excavation, plumbing, hvac, landscaping, roofing, or general) and override any input: cash, credit line, money owed to the business, work already sold, crews and their weekly cost, overhead, owner draw, monthly bills, enquiries, close rate, seasonality, job types with value, materials, deposit and payment terms, bad debt, tax, and random setbacks. Money is in dollars and rates are fractions (0.3 is 30 percent). The same inputs and seed always return the same answer. Pure arithmetic: no network access, nothing stored.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Business name, used only to label the result. | |
| seed | No | Seed for the random draws. The same inputs and seed always return the same answer. Default "dry-run". | |
| crews | No | Crews (or technicians, or production units) working in parallel. One crew delivers one crew-week a week. | |
| preset | No | Starting template: excavation, plumbing, hvac, landscaping, roofing, or general for any other small services business. Every field below overrides it. Default general. | general |
| leads_cv | No | Week to week spread of enquiries. Default 0.35. | |
| tax_rate | No | Share of profit set aside for tax, paid quarterly. | |
| job_types | No | The kinds of work sold. Replaces the preset list. | |
| surprises | No | Random setbacks such as a machine breakdown or someone quitting. Replaces the preset list. | |
| close_rate | No | Share of enquiries that become jobs, as a fraction. | |
| credit_apr | No | Annual interest on the drawn balance, as a fraction. 0.11 is 11 percent. | |
| start_cash | No | Money in the bank on the day the year starts, in dollars. | |
| credit_line | No | Size of the line of credit, in dollars. 0 for none. | |
| fixed_costs | No | Monthly fixed bills such as rent, insurance and equipment notes. Replaces the preset list. | |
| seasonality | No | Twelve multipliers on enquiry volume, January first. 1 is an average month. | |
| start_month | No | Month the simulated year starts, 1 for January. Default: the current month. | |
| credit_drawn | No | How much of the line is already drawn, in dollars. | |
| bad_debt_rate | No | Share of invoiced balances never collected, as a fraction. | |
| leads_per_week | No | Enquiries in an average week before seasonality. | |
| overhead_weekly | No | Weekly overhead that runs whether or not anyone works: office, software, admin wages. | |
| collection_shape | No | How disciplined customers are about paying on time: 2 is ragged with a long tail of late payers, 6 is disciplined. | |
| crew_cost_weekly | No | Fully loaded weekly cost of one crew: wages, burden, fuel, vehicle. | |
| owner_draw_weekly | No | What the owner takes out each week. | |
| opening_receivables | No | Work already invoiced and not yet paid on day one, in dollars. | |
| opening_backlog_weeks | No | Crew-weeks of work already sold and waiting to start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, openWorld=false, non-destructive), and the description reinforces it with 'Pure arithmetic: no network access, nothing stored'. Beyond that it adds genuinely new behavioral facts: 10,000 draws, the exact reported metrics, determinism ('the same inputs and seed always return the same answer'), and the unit convention (dollars, fractions like 0.3 = 30 percent). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what the tool returns, then inputs, then units, then determinism and side-effect guarantees — a sensible order. It is long, and the exhaustive input enumeration partly duplicates the schema's 24 parameter descriptions, which is the only thing keeping it from a 5.
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?
For a 24-parameter tool with no output schema and zero required parameters (presets supply defaults), the description carries the necessary weight: it explains the returned metrics, the preset-plus-override model, determinism, units, and the absence of side effects. Nothing an agent needs to invoke it correctly is missing.
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 100%, so the baseline is 3, but the description adds real value beyond the schema: it confirms every preset field is individually overridable, lists the overridable domain (cash, credit line, receivables, backlog, crews, overhead, owner draw, monthly bills, enquiries, close rate, seasonality, job types, materials, deposit/payment terms, bad debt, tax, setbacks), and fixes the unit convention globally. That global units statement is not repeated in the schema.
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?
States a precise verb and resource plus method and scope: 'Simulate the next 52 weeks of a small services business 10,000 times (Monte Carlo)'. It immediately enumerates what the simulation reports (shortfall probability, worst week, percentile cash bands, drivers, profit), which no sibling tool does. An agent can distinguish this from list_presets and rank_levers without opening a schema.
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?
Usage is implied rather than stated: 'Start from a trade preset (excavation, plumbing, hvac, landscaping, roofing, or general) and override any input' tells the agent how to configure a run, and the preset names hint at list_presets. However, no sibling tool is named, there are no when-not conditions, and no guidance on when a Monte Carlo cash simulation is the right call versus rank_levers.
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.
list_presetsrank_leverssimulate_cash_yearMonte Carlo tools: three-point cost estimation and an educational retirement drawdown simulator.
Monte Carlo ranges for uncertain plans: project cost, budget, timeline, capacity, NPV/IRR/payback.
Deterministic what-if & scenario simulation for AI agents: projections, sensitivity & break-even.
Deterministic US financial planning: retirement Monte Carlo, Roth conversion, RMD, tax, IRMAA, SS
Add one secure layer between your agents and this server.
