Six small-business calculators: valuation, EBITDA, break-even, margin, day rate, acquisition.
Scored across 6 tools
Each tool targets a distinct financial question: affordability, break-even, valuation, EBITDA, freelance rate, and profit margin. The descriptions clearly delineate outputs and inputs, so an agent can select the right tool without confusion.
All tools use a consistent snake_case convention with the same 'forge_' prefix and descriptive concept names. The pattern is predictable throughout, making the set easy to scan.
Six tools is well-scoped for a focused small-business decision toolkit. Each tool earns its place by answering a separate high-value financial question.
The surface covers core small-business financial decisions like valuation, EBITDA, break-even, affordability, pricing, and freelance rates. Minor gaps remain for related decisions such as cash-flow forecasting or loan repayment scheduling, but the core domain is well served.
Check whether a business being bought can pay for its own purchase out of profit, and what happens if it underperforms. Answers "can I afford to buy this business?" from asking price, deposit, loan terms and the annual profit of the business being bought.
| Name | Required | Description | Default |
|---|---|---|---|
| deposit | Yes | Cash paid up front. | |
| loanYears | Yes | Years to repay. | |
| askingPrice | Yes | The asking price. | |
| annualProfit | Yes | Annual profit of the business being bought, before financing. | |
| interestRatePercent | Yes | Annual interest rate on the borrowed balance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add real value by disclosing a downside/stress dimension ('what happens if it underperforms'), which is not visible in the schema. It is silent, however, on modeling assumptions (constant profit, taxes, amortization vs interest-only) and on how results are expressed, which matters for a five-input financial model.
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?
Two tightly written sentences that front-load the core computation and then the input set. No filler, no restatement of the tool name, and the affordability question is stated first.
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?
There is no output schema and no annotations, so the description is the only source of behavioral context. It explains the question being answered but not the shape or components of the answer (e.g., whether profit covers debt service, the shortfall amount, sensitivity results). Adequate to trigger the tool, thin for interpreting or trusting the result.
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 schema already defines every parameter including the key nuance that annualProfit is 'before financing'. The description restates the same four input categories at a conceptual level without adding units, defaults, or per-parameter meaning beyond the schema. Baseline 3 is appropriate.
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?
The description states a specific analytical question ('can I afford to buy this business?') and the exact inputs it reasons over: asking price, deposit, loan terms and annual profit. That is a clear verb+resource far beyond the tool name. It does not, however, reference or distinguish itself from siblings like forge_business_valuation_estimate or forge_break_even, so it stops short of a 5.
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?
Use context is implied by the phrasing 'can I afford to buy this business?', which an agent can map to an acquisition-affordability scenario. There is no explicit when-to-use/when-not statement and no named alternative among the finance siblings, so the guidance remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out how many sales a month a business needs to cover its costs, and how many to hit a target profit. Answers "what is my break-even point?" from fixed monthly costs, price per sale and variable cost per sale.
| Name | Required | Description | Default |
|---|---|---|---|
| pricePerSale | Yes | What one sale brings in. | |
| fixedCostsPerMonth | Yes | Monthly fixed costs: rent, salaries, software, anything paid whether or not you sell. | |
| variableCostPerSale | Yes | What one sale costs to deliver. | |
| targetProfitPerMonth | No | Monthly profit to aim past break-even. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It correctly conveys that this is a stateless derivation from three inputs (plus optional target profit) and that two outputs are produced, but it never states the return shape (sales counts, presumably per month), units/currency assumptions, or that nothing is persisted. For a pure calculator the risk is low, but disclosure is thin.
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?
Two sentences, no filler, and the primary output (break-even sales per month) is front-loaded before the secondary target-profit case. Every clause carries information.
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 four-parameter, no-output-schema calculation tool this is nearly complete: inputs are enumerated and the two results are named. It falls just short of full completeness because the absence of an output schema means the description should ideally pin down what the returned numbers look like (count of sales, per month) rather than leaving it to inference.
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. The description's 'fixed monthly costs, price per sale and variable cost per sale' maps cleanly onto the schema, but it adds no unit conventions, currency handling, or rounding detail beyond what the parameter descriptions already say.
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?
The description gives a specific verb+resource (compute monthly sales volume needed to cover costs / hit target profit) and frames it as the answer to a named question, 'what is my break-even point?'. This is unmistakably distinct from the sibling finance tools (profit_margin, ebitda, business_valuation_estimate, freelance_rate, acquisition_affordability).
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 implicitly tells the agent when to reach for it — when the user asks for a break-even point and supplies fixed costs, price and variable cost. However, there is no explicit when-not guidance, no statement of prerequisites, and no routing to alternatives such as forge_profit_margin for margin questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate what a small business is worth using Normalised EBITDA and typical small-business earnings multiples. Answers "how much is my business worth?" from real figures — revenue, cost of goods sold, operating expenses, owner pay and a fair-market salary for the owner role — rather than a generic rule of thumb. Produces an indicative enterprise value range, not a professional appraisal.
| Name | Required | Description | Default |
|---|---|---|---|
| ownerPay | Yes | Total owner compensation taken from the business. | |
| annualRevenue | Yes | Annual revenue. | |
| costOfGoodsSold | Yes | Annual cost of goods sold. | |
| fairMarketSalary | Yes | What it would cost to hire someone to do the owner role. | |
| operatingExpenses | Yes | Annual operating expenses, excluding owner pay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It clearly states the methodology, the input categories, and the output type (indicative enterprise value range), and includes a limitation statement ('not a professional appraisal'). It does not address edge cases or assumptions about debt/cash/working capital, but for an indicative estimator the disclosure is strong.
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?
The description is three sentences with no redundancy. It front-loads the core purpose, then supplies method, input types, and output format, including an important caveat. Every sentence earns its place.
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 five-parameter tool with no output schema, the description covers purpose, inputs, methodology, and output format (an enterprise value range). Minor gaps remain: it does not describe the exact structure of the range or the underlying assumptions for the multiples. These are non-blocking for a simple estimator, so a 4 is appropriate.
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 coverage is 100%, providing a baseline of 3. The description adds value beyond the schema by explaining how the inputs relate to Normalised EBITDA and why both owner-pay and fair-market salary are needed. The schema descriptions are minimal ('Annual revenue'), so the description's framing around real figures and owner-role cost enriches the parameter semantics.
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?
The description opens with a specific action and resource: 'Estimate what a small business is worth' and further specifies the method (Normalised EBITDA and typical multiples). It directly answers a concrete question ('how much is my business worth?') and clearly differentiates itself from generic rules of thumb and professional appraisals. The sibling tool is in an unrelated domain, so no further distinction is necessary.
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?
The description gives a clear use context: estimate business value from real financial figures rather than a rule-of-thumb approximation. It also states an exclusion: the result is indicative and not a professional appraisal. However, it does not explicitly discuss alternative tools or broader when-not-to-use scenarios, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate EBITDA and adjusted EBITDA for a small business. Answers "what is my EBITDA?" and "what is my adjusted EBITDA after add-backs?" from real figures — revenue, cost of goods sold, operating expenses, and add-backs such as owner pay above a market salary, one-off costs and personal expenses run through the business.
| Name | Required | Description | Default |
|---|---|---|---|
| addBacks | No | Total add-backs: owner pay above market, one-offs, personal expenses. Optional. | |
| annualRevenue | Yes | Annual revenue. | |
| costOfGoodsSold | Yes | Annual cost of goods sold. | |
| operatingExpenses | Yes | Annual operating expenses, including owner pay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully defines what constitutes an add-back (owner pay above market salary, one-offs, personal expenses), which is real behavioral context. But it never states that this is a pure, side-effect-free computation, nor describes the return shape or whether adjusted EBITDA is only produced when addBacks is supplied.
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?
Two sentences, front-loaded with the purpose, then the concrete inputs. The embedded question examples add a little redundancy but earn their place by anchoring business-user phrasing. No wasted preamble.
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 four-parameter calculator with no output schema, the agent is told what goes in but not what comes out — no mention of whether the result is a number, a breakdown, or both EBITDA and adjusted EBITDA. With no annotations to cover read-only/side-effect behavior, the description stops short of fully equipping the agent.
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 all four parameters are already documented, including addBacks and operatingExpenses. The description's elaboration of add-back categories largely restates the schema description rather than adding syntax, formatting, or range guidance. Baseline 3 is appropriate.
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?
The description states a specific verb and resource — 'Calculate EBITDA and adjusted EBITDA for a small business' — and names the exact figures consumed (revenue, COGS, operating expenses, add-backs). It does not explicitly differentiate itself from siblings like forge_profit_margin or forge_business_valuation_estimate, but the metric is unambiguous.
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 gives usage context via the example questions it answers ('what is my EBITDA?', 'what is my adjusted EBITDA after add-backs?'), which is stronger than nothing. However, it names no alternatives and gives no when-not guidance, so the agent must infer that profit margin or valuation questions belong to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out the hourly or day rate a freelancer or consultant needs to charge, once unbillable time is accounted for. Answers "what should I charge per hour?" from target annual income, business costs, working weeks and realistic billable hours.
| Name | Required | Description | Default |
|---|---|---|---|
| targetAnnualIncome | Yes | What you want to earn in a year, before tax. | |
| annualBusinessCosts | No | Annual business costs: software, insurance, accountant, equipment. | |
| workingWeeksPerYear | Yes | Weeks worked a year, after holiday and illness. | |
| billableHoursPerWeek | Yes | Hours a week genuinely billed, not hours worked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose the key modeling assumption that unbillable time is factored into the rate rather than ignored. It reads clearly as a stateless computation with no side effects. It doesn't state output format or currency handling, but for a pure calculator the disclosed modeling behavior is the material trait.
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?
Two sentences, front-loaded with what the tool produces and followed by the question it answers and its inputs. No filler, no restatement of the title, nothing to trim.
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 annotations and no output schema, the description must stand alone, and it does reasonably well by naming the output (an hourly or day rate) and the inputs. Minor gaps remain around units/currency and whether the rate is returned pre- or post-tax, but nothing critical for invoking a four-parameter calculator.
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 schema already defines all four inputs; the description merely re-enumerates them in prose (target annual income, business costs, working weeks, billable hours) without adding format, units, or boundary guidance. Baseline 3 applies when the schema does the heavy lifting.
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 ('work out') and a precise resource ('the hourly or day rate a freelancer or consultant needs to charge'), plus the framing question it answers. None of the sibling tools (break_even, ebitda, profit_margin, valuation, acquisition_affordability) compute a billing rate, so an agent can route to it unambiguously.
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?
Gives clear triggering context ('what should I charge per hour?' once unbillable time is accounted for) and names the input situation the tool expects (target income, business costs, working weeks, billable hours). It stops short of stating when NOT to use it or naming an alternative, but no sibling overlaps enough to require that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between profit margin and markup, and work out the price a target margin requires. Answers "what is my profit margin?", "what is the difference between margin and markup?" and "what should I charge for a 40% margin?" from cost and price.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | Yes | What the item costs you. | |
| price | No | What you sell it for. Optional if targetMarginPercent is given. | |
| targetMarginPercent | No | The margin you want, as a percentage. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a pure, side-effect-free calculation, but never states that it is read-only/deterministic or describes what the response contains. For a calculator the risk is low, but the disclosure is thin.
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?
Purpose is front-loaded in the first clause and the description is only two sentences. The three example questions are slightly redundant with the opening sentence, which is the only wasted space.
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 simple three-parameter calculator with no output schema and no annotations, the description covers the use cases and inputs adequately. The main gap is that return values (e.g., margin %, markup %, computed price) are only implied rather than stated.
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%, and the schema already explains cost, price, and targetMarginPercent, including the conditional 'optional if targetMarginPercent is given' relationship. The description only restates 'from cost and price' and a 40% margin example, adding no format, unit, or interaction detail beyond the schema, so baseline 3 applies.
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?
The description names specific verbs (convert, work out) and precise resources (profit margin, markup, required price), so an agent immediately knows this is a margin/markup calculator. It does not explicitly contrast itself with the finance siblings (break_even, ebitda, etc.), but the domain is distinct enough that confusion is unlikely.
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?
The three quoted example questions ('what is my profit margin?', 'what is the difference between margin and markup?', 'what should I charge for a 40% margin?') give concrete context for when to invoke the tool. There are no stated exclusions or named alternatives, which keeps it short of a 5.
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.
forge_acquisition_affordabilityforge_break_evenforge_business_valuation_estimateforge_ebitdaforge_freelance_rateforge_profit_marginEstimate what a small business is worth and search plain-English valuation guides. Read-only.
Money, tax & business calculators kept current with 2026 rules — plus operator insights.
Free money calculators: option expiry risk, debt avalanche, cash runway, subscriptions, invoices.
Free SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
Add one secure layer between your agents and this server.
