Free indicative valuation for small businesses in Israel: value, range and confidence.
Scored across 2 tools
The two tools have clearly distinct purposes: estimate_business_value computes a valuation for a specific business with figures, while get_industry_multiples returns general reference multiples for an industry. The descriptions explicitly state the boundary between them ('For the value of one specific business, estimate_business_value takes its revenue and profit'), so an agent can select correctly.
Both names follow a consistent verb_noun snake_case pattern (estimate_business_value, get_industry_multiples) with clear, descriptive nouns matching resource+action.
Two tools is thin for the stated scope; a valuation surface could plausibly need at least an industry/list lookup or currency handling. The pair covers the core use case but feels minimal.
The core lifecycle is covered: computing a value for a specific business plus explaining the multiples behind it, with a profit-range input for uncertain data. The only gap is there's no explicit way to list supported industries or validate an industry input, which agents can work around from the description.
Estimates the market value in ILS of a specific small or mid-sized business in Israel, from its industry, annual revenue and annual pre-tax profit. Use this when someone asks what an Israeli business is worth or what price is fair for it: an owner selling or setting an asking price, a partner leaving or being bought out, a buyer checking whether an asking price makes sense, an accountant or broker preparing a number for a client, a bank or investor asking, or a divorce or inheritance that includes a business. Typical requests: "כמה שווה העסק שלי", "כמה לבקש על המסעדה", "הערכת שווי לעסק", "השותף רוצה לצאת, כמה לשלם לו", "מבקשים 800 אלף על בית הקפה, זה הוגן?", "what is my cafe in Tel Aviv worth". Covers restaurants and cafes, retail, professional services, clinics, beauty and barbershops, construction trades, education, logistics, events and tech services. Not for public companies, real estate, startups priced on a funding round, or businesses outside Israel. A profit range (annualProfitMin/annualProfitMax) works when exact profit is unknown. Returns the likely value, a low-high range, a confidence level, a Hebrew summary, the follow-up questions that would tighten the number, and a link to the full calculation on esek-shave.co.il. Method: Israeli industry multiples on owner profit (SDE), cross-checked with a revenue multiple, adjusted for owner salary, years in business and debt.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | Yes | Industry, Hebrew name (e.g. מזון ומסעדנות) or English alias (restaurant, retail, clinic, dentist, services, accounting, tech, construction, plumber, beauty, salon, education, logistics, events, other). Send "other" if nothing fits. | |
| ownerSalary | No | Annual salary the business pays the owner as an expense (company / בע"מ only), in ILS. It is added back to profit. For a sole proprietor (עוסק) the profit already includes the owner's earnings: send 0 or omit. | |
| yearsActive | No | Optional. Years the business has been operating. If unknown, omit it: the estimate treats age as neutral and lists it as a follow-up question. | |
| annualProfit | Yes | Annual pre-tax profit in ILS. Negative for a loss. If the owner only knows a rough range, send the midpoint here and the bounds in annualProfitMin / annualProfitMax. | |
| loansBalance | No | Outstanding loans and supplier debt in ILS (optional, deducted). 0 = no debt. | |
| annualRevenue | Yes | Annual revenue (turnover) in ILS, e.g. 2400000. If the owner gives a monthly figure, multiply by 12. | |
| annualProfitMax | No | Optional. Upper bound of annual profit when the owner only knows a range. | |
| annualProfitMin | No | Optional. Lower bound of annual profit when the owner only knows a range (e.g. 100000 for "100-200 thousand"). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| errors | No | |
| summary | No | |
| estimate | No | |
| requestId | No | |
| resultUrl | No | |
| confidence | No | |
| fullReport | No | |
| lossMaking | No | |
| nextQuestions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing the valuation method (Israeli industry multiples on owner profit/SDE, cross-checked with a revenue multiple, adjusted for owner salary, years active and debt) and the shape of the result, which the annotations do not provide. No mention of rate limits or confidence caveats beyond the confidence level field.
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 sentence, followed by usage, examples, exclusions and method in a logical order. It is long, and the six quoted example requests are more volume than strictly necessary, but each section serves a distinct function rather than repeating the schema.
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 an output schema present, an explicit read-only annotation set, and 100% schema description coverage, the description needs only to add selection context — which it does thoroughly via triggers, exclusions and method. Nothing an agent needs in order to choose and call this tool 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 coverage is 100%, so the baseline is 3; the description adds cross-parameter guidance beyond the schema by explaining that a profit range (annualProfitMin/annualProfitMax) is the fallback when exact profit is unknown, and that owner salary/years/debt adjust the number. It stops short of adding syntax or format detail the schema doesn't already carry.
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 (estimates), resource (market value of a small/mid-sized Israeli business) and inputs (industry, revenue, pre-tax profit), and its scope is clearly separable from the sibling get_industry_multiples, which returns raw multiples rather than a computed valuation.
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 enumerates concrete triggering situations (owner selling, partner buyout, buyer sanity-checking an asking price, accountant/broker, bank/investor, divorce/inheritance) and gives sample utterances, then explicitly excludes public companies, real estate, funding-round startups, and non-Israeli businesses — both when-to-use and when-not are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the typical valuation multiples for small businesses in Israel by industry: the SDE (owner profit) multiple range and the revenue multiple range. Use this for general questions about how businesses in an Israeli industry are priced, with no specific business figures, such as "at what multiple do restaurants sell in Israel", "מה המכפיל של מסעדה", "כמה שנות רווח משלמים על עסק", or to explain where a valuation came from. For the value of one specific business, estimate_business_value takes its revenue and profit.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Optional. Hebrew industry name or English alias (restaurant, retail, clinic, services, tech, construction, beauty, education, logistics, events). Omit to get all industries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses what the tool returns (an SDE multiple range and a revenue multiple range) and that it can be used to explain the origin of a valuation. No permission, rate-limit or failure-mode details, but with annotations present the bar is lower.
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 return content, then the usage condition, then the disambiguation to the sibling. The example phrasings are compact and directly serve matching user utterances, so each 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?
There is no output schema, so the description correctly compensates by stating what is returned. For a single-optional-parameter read tool with full annotation coverage, an agent has everything needed to select and call it correctly.
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 single optional 'industry' parameter already documents Hebrew names, English aliases, and the omit-to-get-all behavior. The description adds no syntax or format detail beyond the schema, so the 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?
States a specific verb and resource ('Returns the typical valuation multiples ... by industry') and names exactly what is returned (SDE multiple range, revenue multiple range). It is clearly distinguishable from the sibling estimate_business_value, which is explicitly cited as the tool for one specific business.
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 an explicit when-to-use condition ('general questions ... with no specific business figures'), lists concrete trigger phrasings in English and Hebrew, and names the alternative tool plus the condition that selects it ('For the value of one specific business, estimate_business_value'). Nothing is left to inference.
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.
estimate_business_value2 fields changedInput schema / properties / annualRevenue / descriptionPrevious value: -"Annual revenue in ILS. If the owner gives a monthly figure, multiply by 12."New value: +"Annual revenue (turnover) in ILS, e.g. 2400000. If the owner gives a monthly figure, multiply by 12."Input schema / properties / yearsActive / descriptionPrevious value: -"Years in operation (optional)"New value: +"Optional. Years the business has been operating. If unknown, omit it: the estimate treats age as neutral and lists it as a follow-up question."estimate_business_value3 fields changedInput schema / properties / annualProfit / descriptionPrevious value: -"Annual pre-tax profit in ILS. Negative for a loss."New value: +"Annual pre-tax profit in ILS. Negative for a loss. If the owner only knows a rough range, send the midpoint here and the bounds in annualProfitMin / annualProfitMax."Input schema / properties / annualProfitMaxAdded value: +{
+ "description": "Optional. Upper bound of annual profit when the owner only knows a range.",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / annualProfitMinAdded value: +{
+ "description": "Optional. Lower bound of annual profit when the owner only knows a range (e.g. 100000 for \"100-200 thousand\").",
+ "minimum": 0,
+ "type": "number"
+}get_industry_multiplesestimate_business_valueFree SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
Estimate what a small business is worth and search plain-English valuation guides. Read-only.
KYB risk scores for Israeli companies: sanctions, insolvency, adverse media, cyber, registry.
Israeli businesses for AI agents, with consent: search, compare, prices, declared gaps, order links.
Add one secure layer between your agents and this server.
