Estimate what a small business is worth and search plain-English valuation guides. Read-only.
Scored across 3 tools
Each tool has a clearly distinct role: search_guides discovers content, get_page retrieves a full page from a known slug/URL, and estimate_value_range performs a calculation. The descriptions make the search-then-retrieve workflow explicit, so there is no realistic confusion.
All three tools use snake_case with a verb_noun pattern: search_guides, get_page, and estimate_value_range. The convention is predictable and consistent throughout.
Three tools is on the low end for a 'dashboard' but each earns its place without redundancy: search, retrieval, and estimation. It is slightly thin for a server that might also offer browsing or comparison, but still reasonable for the apparent scope.
The surface covers the core lifecycle of discovering guides, reading a page, and estimating value. Minor gaps exist, such as no direct way to browse all guides or fetch industry multiples without a search, but agents can work around these.
Return an indicative value range for a small private business from its yearly earnings and industry, using publicly reported average sale multiples. Earnings should be seller's discretionary earnings (profit before tax plus owner pay, interest and depreciation) for owner-operated businesses, or EBITDA for larger ones. Not a formal valuation.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Industry or sector, for example "hvac", "dental", "restaurant", "manufacturing". Optional. | |
| annual_earnings | Yes | Yearly earnings in US dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes beyond that by flagging the heuristic nature of the output ('indicative', 'publicly reported average sale multiples') and the important caveat 'Not a formal valuation', which manages expectations about result reliability—context annotations cannot provide.
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?
Three tightly packed sentences: purpose first, then the critical definition of the earnings input, then the disclaimer. Every sentence earns its place with no 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?
Given only 2 params, full schema coverage, no output schema and a read-only annotation, the description covers purpose, input semantics and reliability caveat. It could say more about how the range is reported (currency, spread, confidence), but the essentials for correct invocation are present.
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 baseline is 3, but the description adds meaning beyond the schema: it defines what 'annual_earnings' should represent (SDE: profit before tax plus owner pay, interest and depreciation; or EBITDA for larger firms) and that 'industry' is used to select the multiple. This disambiguates a genuinely ambiguous input field.
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 (Return) and resource (indicative value range for a small private business) plus the inputs it draws on (yearly earnings, industry, public sale multiples). An agent can immediately tell what the tool produces and how it is derived.
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 implies when to use it (valuing a small owner-operated or larger private business) but never states exclusions or names alternatives. The sibling tools are unrelated (get_page, search_guides), so there is no routing conflict, but no explicit when/when-not guidance is given either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full text of one BizValueDash page. Pass a slug or URL from search_guides.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Page slug or full URL, for example "sde-vs-ebitda". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that it returns 'full text' (suggesting no truncation), but says nothing about auth requirements, rate limits, or error behavior on a missing page.
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, zero filler, and the core action is front-loaded ahead of the prerequisite for the argument.
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 single-parameter read tool with annotations covering safety and no output schema, the definition supplies the key workflow link to search_guides. It stops short of describing the shape or size of the returned 'full text', which is a minor remaining gap.
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 already documents the slug as 'Page slug or full URL' with an example. The description repeats the same slug-or-URL fact without adding syntax, normalization, or precedence rules, 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?
States a specific verb and resource ('Return the full text of one BizValueDash page') and names the sibling tool that produces valid inputs, so an agent can distinguish it from search_guides without opening either 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?
Clearly routes the agent: obtain a slug or URL from search_guides, then call this. The implied workflow (search first, fetch after) is explicit, though there are no stated exclusions or edge cases (e.g., what happens on an invalid slug).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BizValueDash guides, glossary and pages about what a small business is worth, valuation multiples, SDE and EBITDA, what raises or lowers business value, and formal valuations. Returns the best matching pages with a short excerpt.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What to look for, in plain words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine value beyond that by disclosing the return shape ('best matching pages with a short excerpt'), which matters because there is no output schema. It stops short of describing ranking behavior or result-count semantics.
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, purpose front-loaded, with the return behavior trailing. The long topical enumeration is slightly listy but each term earns its place by improving query matching. No filler or restated name/title.
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 two-parameter read-only search with no output schema, the description covers purpose, domain, and return format, which is nearly everything an agent needs. It lacks only routing guidance against siblings and any note on result ordering or empty-result behavior.
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 50%: the required 'query' parameter is documented ('What to look for, in plain words'), while 'limit' is self-documenting via default=5, min=1, max=10. The description adds no parameter-level detail (e.g., how limit interacts with ranking or excerpt length), so it neither compensates for nor worsens the partial coverage.
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 a specific verb (Search) and resource (BizValueDash guides, glossary and pages) and enumerates the exact topic domain — valuation multiples, SDE/EBITDA, value drivers, formal valuations. That scope makes it clearly distinguishable from the sibling get_page (retrieval of a known page) and estimate_value_range (computation) without opening either 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 by the topic list: an agent can infer this is the tool to reach for when it needs conceptual/glossary content rather than a specific page or an estimate. However, there is no explicit statement of when to use this versus get_page or estimate_value_range, and no exclusions or prerequisites.
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_value_rangeget_pagesearch_guidesFree SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
Read-only tools for finding where a small business leaks deals, time, and cash.
Read-only public-company financials, KPIs, benchmarks, filings, and insider activity.
Read-only value-investing fund, holdings, financial, options, and insider research.
Add one secure layer between your agents and this server.
