Check if EU GPSR applies to your product, and estimate what your small business is worth.
Scored across 8 tools
Each tool targets a distinct financial or research task, and the descriptions clearly indicate when to use each. There is minor potential overlap between acquisition affordability and business valuation (both use financials), but the actions and outputs differ enough to avoid confusion.
All tools use the forge_ prefix followed by snake_case descriptive compound nouns, which is perfectly consistent across the set. There is no mixing of verb styles or casing conventions.
Eight tools is well within a healthy range for a business decision toolkit, and each tool covers a distinct calculation or method. There is no redundancy or filler.
The set covers several key small-business financial calculations (break-even, margin, EBITDA, valuation, acquisition affordability, freelance rate) plus competitor research and a Shopify audit. However, it lacks other common decision areas like cash flow forecasting, loan repayment, or tax estimation, leaving minor gaps.
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.
The method for researching competitors or a market before committing money, and what each finding is worth. Answers "how do I do a competitor analysis?", "how do I research a market before entering it?" and "what will an investor ask me about competitors?" — returns the steps, the six things a competitor publicly reveals, and how to turn a finding into a decision rather than a grid.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Which decision this is for: researching competitors, deciding whether to enter a market, or answering the competition question in a raise. | |
| competitorCount | No | How many competitors are being considered. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose return contents (steps, six public signals, a decision framework). However, it says nothing about determinism, formatting, length, or any operational trait, leaving the disclosure adequate but incomplete for an unannotated tool.
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?
Everything is a single dense sentence front-loaded with the core purpose, which is good, but the three quoted questions and the 'rather than a grid' flourish add length without proportional information. It is serviceable but heavier than the payload requires.
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 must convey what comes back, and it does so at a high level (steps, six signals, decision framework). Combined with a fully documented 2-param input schema, an agent has enough to call the tool correctly, though output structure remains loosely specified.
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 schema already documents both the enum choices and the optional competitorCount. The description only restates the three decision contexts the enum already names, adding no syntax or format detail beyond the schema — the correct baseline of 3.
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 resource ('the method for researching competitors or a market') and states what it yields ('the steps, the six things a competitor publicly reveals, and how to turn a finding into a decision'). It is clearly a research-method tool distinct from the financial calculators in the sibling set, though it never names a sibling explicitly.
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 frames usage through concrete trigger questions ('how do I do a competitor analysis?', 'how do I research a market before entering it?', 'what will an investor ask me about competitors?') that map onto the three enum values, and gives the timing cue 'before committing money.' There is no explicit when-not guidance or named alternative, so it stops 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.
Audit a real Shopify store from its public pages and score it out of 100 for speed, SEO, trust and product pages. Answers "why is my Shopify store not converting?", "how fast is my store?" and "what should I fix on my Shopify store first?" — reads only what a shopper can see, needs no login or app install, and returns the fixes in the order worth doing them.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The storefront address, for example mystore.com or mystore.myshopify.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that it reads only shopper-visible pages, requires no login or app install, and returns fixes in priority order. It never states the read-only nature as a formal guarantee or mentions latency/rate limits, leaving a small gap.
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 core action is front-loaded in the first clause, and each subsequent element (use-case questions, no-login constraint, prioritized output) earns its place. The three quoted questions are slightly verbose and could be compressed, keeping it out of 5 territory.
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-only audit with no annotations and no output schema, the description covers purpose, behavioral constraints, and the shape of the result (score out of 100, prioritized fixes). A little more on the returned report structure would make it 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?
There is a single parameter with 100% schema description coverage, so the schema already documents the domain format and examples. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 correct.
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 (audit) and resource (a real Shopify store), plus the scope (public pages) and the four scored dimensions (speed, SEO, trust, product pages). This is unmistakably distinct from the financial-calculation siblings, so an agent can route to it 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?
Names the concrete questions the tool answers ("why is my store not converting?", "how fast is my store?", "what should I fix first?"), which gives clear context for when to invoke it. It stops short of explicit exclusions or naming an alternative sibling, so it stops at 4 rather than 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_shopify_store_auditforge_competitor_research_methodforge_acquisition_affordabilityforge_break_evenforge_ebitdaforge_freelance_rateforge_profit_marginforge_gpsr_requirements_checkforge_business_valuation_estimateforge_gpsr_requirements_checkGPSR compliance check and small-business valuation estimate, from Instilus.
Free SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
Source-cited EU/UK/US/AU market-access checks for Amazon and cross-border product compliance.
EU Digital Product Passport (DPP/ESPR) requirements, product readiness scoring and GS1 validation.
Add one secure layer between your agents and this server.
