Raziel Calculators

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this a safe, idempotent, closed-world read, so the description rightly focuses on interpretation: the output band, the rule-of-thumb provenance, and the period-matching requirement. It omits what happens in edge cases, notably the schema-permitted negative net new ARR, which would produce a nonsensical negative multiple — a meaningful gap for a ratio 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?

Front-loaded with the formula, then interpretation bands, then the alternative tool, then the reference link — a sensible funnel with no filler. The band enumeration is long but is genuinely the useful part of the answer.

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 the description does compensate by saying it returns the multiple plus a band, including the band thresholds. The main unresolved behavior is the negative-ARR path, which an agent could plausibly hit given the schema explicitly allows it.

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 value by insisting both inputs cover 'the same period (a quarter or a year)', which constrains how the two numbers must be chosen together. It does not restate the sign conventions, but those are already 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 specific metric and its exact formula ('net burn divided by net new ARR over the same period'), plus directionality ('lower is better'). It differentiates from the closest sibling by naming rule_of_40 for the adjacent growth-vs-profitability question.

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?

Explicitly routes the agent away to rule_of_40 when the question is growth versus profitability, which is a real disambiguation. It does not cover the other efficiency siblings (runway, ltv_cac, cac_payback), so the routing is clear but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a read-only, idempotent, non-destructive, closed-world calculation, so the safety profile is covered. The description adds useful behavioral context beyond annotations by stating the formula, the output unit (months), and investor benchmark ranges.

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 metric and formula are front-loaded, followed by practical input guidance, a benchmark, a related tool, and a guide link. The description is compact and every sentence contributes to correct selection or invocation.

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 read-only calculator with no output schema, the description provides the formula, required and alternative inputs, output unit, benchmark context, and a relevant sibling tool. An agent has enough information to invoke it correctly without needing additional behavioral or return-value details.

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, but the description adds meaning by showing how parameters relate in the formula and by clarifying the alternative CAC input path using spend and new customers. It does not add much beyond the schema for arpa_monthly_usd and gross_margin_pct, but the relationship between inputs is made explicit.

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 metric and formula: months of gross profit needed to recover CAC, calculated as CAC / (monthly revenue per account x gross margin). It also distinguishes the tool from the related ltv_cac sibling, so an agent can identify both what it computes and where it fits among alternatives.

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 clear input alternatives: provide cac_usd directly, or provide sales_marketing_spend_usd and new_customers for the same period. It also points to ltv_cac when lifetime value is also needed, but it does not explicitly state when not to use this tool or contrast it with every relevant sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description needn't restate them. It adds scope context and a link to an interactive version, but says nothing about the computation itself — e.g. whether the result is annualized as (end/start)^(1/years)-1, or how a start value of zero or a decline is handled.

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 plus a link, zero waste. The definition is front-loaded and the disambiguation follows immediately, which is the right order for routing.

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 should describe what comes back (a rate — decimal or percentage?), and it does not. For a simple three-parameter, fully-documented calculator the rest is adequate, but the return-value gap leaves an agent guessing at the result format.

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 three parameters are already documented with units, bounds, and exclusivity. The description adds only the interpretive frame (a single value's growth), not syntax or format detail beyond the schema — baseline 3 is correct here.

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 computation (compound annual growth rate) with its exact inputs (start value, end value, years), so the agent knows precisely what it produces. The second sentence names the sibling tools it is not (irr, xirr), making it distinguishable without opening the 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?

Gives an explicit selection rule: single-value growth (revenue, asset price) goes here, multiple cash flows go to irr or xirr. Both the when and the when-not are stated with the named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine value by disclosing the computation and the NOI derivation fallback, plus a note about the interactive version. It does not state output formatting (percent vs. decimal), which is the remaining 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?

Three short sentences, front-loaded with the core computation and followed by input guidance and the sibling routing. The external URL is the only arguably extraneous element.

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, the description carries the return-value burden and does enumerate the three results, which is enough to call the tool correctly. Minor gap: it never says what units the cap rate is expressed in or how the results are shaped.

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 every parameter is already documented, including the NOI fallback rule. The description's either/or phrasing of noi_usd versus gross/expenses restates schema semantics rather than extending them. 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?

Names the specific metric and its formula (net operating income / property value), plus the two secondary outputs (gross rent multiplier, price per unit). It also explicitly distinguishes itself from the sibling cash_on_cash, so an agent can route 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?

"Give noi_usd directly or gross income and operating expenses" gives explicit input paths, and "Use cash_on_cash when financing matters" names an alternative with the selecting condition. It does not address other valuation siblings (irr, moic, startup_valuation), but the key fork is covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's job is to add model-level context, which it does: it discloses that this is the whole-fund convention and that outcomes include net-of-fee drag. It stops short of stating anything about defaults actually applied (e.g., that catch_up defaults to full and hurdle to 8%), which would materially change results.

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?

One dense, front-loaded sentence that packs the full waterfall sequence, followed by a link to an interactive version. No filler, though the URL is of marginal use to an agent invoking the tool.

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 twelve parameters and no output schema, the agent needs some sense of the return shape; the description names the headline figures (LP net multiple, gross-to-net drag) but not the structure of the response. It also doesn't explain the mode switch's effect on which inputs become relevant, which is the main invocation risk here.

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 twelve parameters, including the mode enum and step-down fields, are already documented in structured data. The description adds no parameter-level meaning beyond that, 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?

Names the specific resource and model: a European (whole-fund) distribution waterfall, enumerating its stages (fees, return of capital, hurdle, GP catch-up, carry split) and its outputs (LP net multiple, gross-to-net drag). That clearly separates it from metric-only siblings like moic, irr, or tvpi_dpi, even without naming them.

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 'European (whole-fund)' qualifier implicitly tells the agent this is the whole-fund waterfall rather than a deal-by-deal one, which is a real scoping signal. But there is no explicit when-to-use statement, no mention of which sibling to pick for a plain multiple (moic) or an IRR, and no prerequisites noted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=true, idempotent=true, destructive=false, so safety needs no restating. The description adds real value by disclosing the computed outputs (including DSCR and break-even occupancy, which a caller could not guess from the name) and by implying a defaulted model rather than a data fetch. It does not spell out the assumption set behind those metrics, which keeps it below 5.

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 compact sentences front-load the outputs and place the sibling routing second, which is the right order. The trailing marketing URL is not essential to invocation and is the only wasted element.

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, the description compensates by naming the returned metrics, so an agent knows what a call yields. For a stateless 8-parameter calculator with full annotation coverage, that is nearly sufficient; only the modeling assumptions (e.g. how vacancy and operating expenses feed NOI) are left implicit.

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 defaults and ranges documented for all 8 parameters, so the schema carries parameter meaning fully. The description names conceptual inputs (NOI, mortgage payment) but adds no syntax, units, or interaction detail beyond the schema — baseline 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?

Names the resource (leveraged rental property returns) and enumerates exactly which metrics are produced: mortgage payment, NOI, annual cash flow, cash on cash return, DSCR, break-even occupancy. It also explicitly positions itself against the sibling cap_rate, so an agent can separate the two 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?

"Use cap_rate for an unlevered view of the same property" gives an explicit alternative plus the condition that selects it, which is the key routing decision here. It does not cover other plausible alternatives (irr, xirr, moic) or state when a leveraged analysis is inappropriate, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot: results are researched and sourced, and 'Facts are as of the research date in the result,' warning the agent about staleness. This is real added value beyond structured fields.

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?

One dense sentence, front-loaded with the verb and resource, followed by the return-contents summary and the 'list' escape hatch. The long platform enumeration is bulky but earns its place as a vocabulary list that lets the agent match user phrasing to valid inputs. Slightly overlong but no wasted 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 must convey what comes back, and it does: pricing, feature coverage, key differences, competitor strengths, and sources. Combined with the research-date caveat and the 'list' affordance, an agent has everything needed to call this correctly on the first try.

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% and the schema already documents the competitor parameter with examples. The description adds meaning beyond the schema by stating that the literal value 'list' returns every platform, a sentinel behavior not obvious from the parameter's example-only description.

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 ('Researched, sourced comparison of Raziel with another investing or startup platform') and enumerates the exact scope: pricing, feature coverage, key differences, where the other platform is stronger, and sources. This is unmistakably distinct from the sibling calculator tools (irr, runway, moic, etc.), none of which perform comparisons.

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 concrete usage path for discovery ('Pass "list" to see every platform'), which tells the agent how to resolve an unknown competitor name. It does not explicitly state when-not-to-use or name alternatives, but no comparable sibling exists, so the context is clear if not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that this is a read-only, idempotent, non-destructive calculator. Beyond that, the description usefully enumerates what the calculation covers, including interest accrual, cap-vs-discount conversion pricing, shares, and effective discount. It does not describe rounding, error behavior, or output structure in detail, but it adds meaningful behavioral context for a calculator.

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 short and front-loaded, starting with the core calculation and output dimensions. The SAFE alternative and interactive URL are placed after the essential purpose, and there is no wasted wording.

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 an eight-parameter calculator with fully described inputs and read-only annotations, the definition is complete enough to invoke correctly. It also compensates for the absence of an output schema by naming the key computed outputs: accrued interest, conversion price, shares received, and effective discount.

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 input schema already explains the parameters, including principal, round price per share, cap, discount, years, interest rate, and interest mode. The description does not add parameter-specific syntax or constraints beyond the schema, so the 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 financial calculation: how a convertible note converts in a priced round, including accrued interest, conversion price, shares received, and effective discount. It also explicitly distinguishes this tool from the SAFE conversion sibling, so an agent can identify the resource and scope without inspecting the 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 directly says to use safe_conversion for SAFEs because they have no interest, which is an explicit alternative and condition. For the convertible-note case, the purpose sentence itself supplies the context for when this calculator applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds what those annotations cannot: the response includes a link to the Raziel guide or calculator, and the special "list" mode returns the full term set. It omits what happens for an unrecognized term.

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 purpose, then the two operational rules. The ~50-item parenthetical is long, but it earns its place by communicating exactly which terms will resolve; trimming it would cost coverage signal.

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-param lookup with no output schema, the description covers what is returned (a definition plus a guide/calculator link), the list mode, and where to go for depth. The one real gap is unknown-term behavior, which an agent would want to know before calling.

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% and the schema's own description already documents the "list" escape hatch with examples, so the description's restatement adds little. The term enumeration indicates the accepted vocabulary (including abbreviations like 83(b) and 409A), but supplies no matching or normalization rules.

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 ('Plain-English definition of a private-market, venture or fund term') and enumerates the exact term space covered, which lets an agent judge coverage without guessing. It also names search_guides as the sibling handle for longer explanations, so it is distinguishable from alternatives.

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 two concrete usage rules: pass "list" to enumerate every term, and use search_guides for longer explanations. It does not address the more likely confusion with the calculator siblings (pro_rata, qsbs, liquidation_preference, tvpi_dpi), which cover the same vocabulary but compute values rather than define them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe, read-only, idempotent calculator, so the description does not need to repeat safety. It adds useful behavioral context by noting that option-pool top-ups happen before each round, which affects how dilution flows through founders. It stops short of explaining the sequence of calculations or the exact result shape.

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 plus an optional link, with the core capability front-loaded and the sibling routing in the second sentence. No sentence is wasted.

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 rich schema coverage and the absence of an output schema, the description is largely complete: it conveys the multi-round model, pool top-ups, and ownership output. It could be stronger by mentioning that results are per round or how existing investors are treated, though the schema covers the latter.

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 founders_pct, option_pool_pct, and every round field. The description adds only the high-level notion of pool top-ups before each round; it does not add syntax or detail beyond the schema, so 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 outcome (founder and investor ownership) over a specific scope (several future funding rounds with option-pool top-ups). It clearly distinguishes itself from option_pool and startup_valuation, so an agent can identify the right tool without opening the 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 explicitly routes single-round pool questions to option_pool and simple single-round valuations to startup_valuation, leaving this tool for the multi-round case. The alternatives and their selecting conditions are named directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the yearly-period assumption and a pointer to an interactive version. It omits failure behavior (e.g. no real IRR / non-convergence / multiple roots), which is the one meaningful 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?

Front-loaded with the definition, then the sibling routing rule, in two tight sentences. The interactive URL is a minor extra that does not help an agent invoke the tool, but it costs little and does not obscure the actionable content.

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 two-parameter read-only calculation the definition is nearly sufficient, and the schema covers inputs fully. However, there is no output schema, so the description should say what comes back (decimal vs. percentage, error when no IRR exists) — that return-shape ambiguity is left unresolved.

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 both parameters are already documented with sign conventions and year-0/year-1 ordering. The description's phrase 'evenly spaced yearly' reinforces the timing convention but adds no syntax or format detail the schema does not already carry, 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 metric and the exact input convention it expects: IRR for evenly spaced yearly cash flows after an initial investment. It immediately distinguishes itself from the sibling xirr, so an agent can pick the right one 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?

Explicitly names the alternative (xirr) and the exact condition that selects it: cash flows with specific dates or irregular timing. That is a textbook when/when-not routing rule with nothing left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/non-destructive, so the description needn't restate safety. It does add real behavioral context: the conversion election rule ('Each series converts to common when that pays more') and the semantics of stacked vs pari passu payout ordering. It does not mention input limits (max 10 series) or how the result is presented, which keeps it from a 5.

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 core purpose and with the human-facing link relegated to the end. The second sentence is dense with comma-separated enumeration, but every item earns its place by naming a supported modeling option.

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 is the only place an agent could learn what comes back — yet it never says whether the result is a per-series dollar breakdown, per-share price, or totals. For a four-parameter financial model with edge cases (zero exit value, proceeds insufficient to cover preferences), that omission is a meaningful 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 coverage is 100%, so every parameter including participation, preference_multiple, and seniority is already documented inline. The description's enumeration of the same concepts ('preference multiples, non-participating, participating or capped participation, and stacked or pari passu seniority') largely echoes the schema rather than adding new semantics, 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?

Opens with a specific verb-free but unambiguous statement of function: an exit waterfall splitting sale proceeds between preferred series and common. It enumerates the exact model variants it handles (preference multiples, non-participating/participating/capped, stacked vs pari passu), which sharply separates it from siblings like dilution, moic, or safe_conversion.

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 domain naming — an agent can infer this is the tool for exit/sale-proceeds allocation. However, there is no explicit statement of when to pick this over related tools (e.g., convertible notes or SAFEs on conversion) and no preconditions called out beyond the model description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/closed-world, and the description correctly frames this as a deterministic calculation. With no output schema, it usefully enumerates the three returned values and the benchmark interpretation. It does not discuss edge behavior (e.g., low-churn sensitivity), which is only partly covered by the schema's exclusiveMinimum on churn.

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?

Formulation, outputs, benchmark, and sibling routing are all front-loaded across four tight sentences with no redundancy. The trailing guide link is short and optional rather than diluting the core.

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-required-parameter calculator with no output schema, the description supplies the formula, the return fields, and a result-interpretation threshold – everything needed to call it correctly and read the output.

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. The description adds real value by spelling out the formula that combines arpa_monthly_usd, gross_margin_pct, and monthly_churn_pct, giving the agent a mental model of how inputs interact rather than just their definitions.

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 the exact computation (monthly revenue per account x gross margin / monthly churn) versus CAC, plus the three return values. This is clearly distinguishable from siblings such as cac_payback or burn_multiple because the inputs and outputs are named 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?

Explicitly routes the agent: 'Use cac_payback when you only need the payback period,' which names the alternative and the condition that selects it. It also supplies an interpretation benchmark (3:1) and a guide link, so an agent knows both when to call it and how to read the result.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true and non-destructive, so safety burden is low. The description adds the meaningful behavioral detail that annualization only occurs when a holding period is supplied, which is context beyond the annotations. It doesn't mention edge cases like a zero/negative return, so not a 5.

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 definition and formula are front-loaded in one dense sentence, with usage routing second. The trailing promo URL is wasted tokens for an agent but doesn't obscure the core content.

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, the description still tells the agent what comes back: an MOIC multiple and, when years is given, an implied annualized return. For a simple 3-parameter read-only calculator this is close to sufficient; only edge-case behavior is left implicit.

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 earns above that by explaining that 'years' drives the implied annualized return and defining value_returned as distributions plus current holdings value in the context of the MOIC formula. It adds interpretive meaning rather than repeating 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 the exact metric and its formula ('total value returned (distributions plus current value) divided by the amount invested'), a specific computation an agent can match to a user request. It also explicitly distinguishes itself from the sibling tvpi_dpi by scoping that one to fund-level LP multiples.

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 tvpi_dpi for fund-level LP multiples' routes the agent to the correct alternative, and the mention of 'implied annualized return when a holding period is given' signals the deal-level use case. It lacks an explicit when-not statement (e.g., use irr/xirr for cash-flow-timed returns), so it falls short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds the computation formula and an interpretation rule ('Above 100% NRR means existing customers grow on their own'), but it never explains how GRR is derived (implicitly NRR without expansion) or what the response contains, despite no output schema.

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 definition and formula are front-loaded, the interpretation sentence earns its place, and the exclusion rule is appended efficiently. The external guide URL is marginal but not disruptive.

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 four-parameter calculator with no output schema, the description covers definition, formula, and interpretation. It leaves two meaningful gaps: whether GRR is returned alongside NRR and how GRR is defined, which an agent calling a tool titled 'Net and gross revenue retention' would reasonably expect.

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 all four parameters with defaults and minimums. The formula in the description maps each input to a term (expansion, contraction, churn, starting revenue), which reinforces the semantics but adds little beyond the per-parameter descriptions. 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 the specific metric computed (NRR and GRR) for a defined cohort over a period and gives the exact formula, so an agent knows this is a retention-metric calculator. It is clearly distinguishable from siblings like burn_multiple or rule_of_40 by naming the resource and the calculation. It stops just short of an explicit 'computes/returns' verb.

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?

'Exclude revenue from new customers' is a genuine input constraint, and 'usually 12 months' gives period guidance for the cohort. However, it never names alternatives or states when to choose NRR/GRR over sibling calculators, so usage is implied rather than directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds that the tool is a pure calculator returning three derived metrics and points to an interactive reference implementation, but says nothing about units, rounding, or edge-case behavior (e.g. when target_pool_pct is below existing_pool_pct).

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?

A single dense sentence that front-loads the tool's identity and then lists outputs, followed by a reference URL. No filler, though the sentence is long and the three output clauses are packed rather than bulleted.

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, the description carries the burden of explaining return values, and it does name all three computed results. What is missing is output units/format and how the 'founder ownership cost' comparison is expressed (percentage points vs dollars), which would fully close the gap for a six-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 every parameter is already documented in the schema. The description does hint at the conceptual distinction between pre-money and post-money pool percentages, which reinforces the schema's target_pool_pct wording, but adds no syntax, units, or interaction details beyond it. 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 named computation (the 'option pool shuffle' for one round) and enumerates the three results it produces: required pool growth, effective pre-money, and founder cost of a pre- vs post-money pool. This is far more specific than a name restatement, though it never names the sibling tools (dilution, pro_rata, safe_conversion) that an agent might confuse it with.

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 by the phrase 'for one round' — an agent can infer this is for modeling a single priced round's option pool. There is no explicit when-to-use/when-not guidance, no statement of prerequisites, and no routing to alternatives such as dilution or startup_valuation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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. The description adds useful behavioral context by disclosing that same-class holdings are aggregated and that the output includes a diversification score and concentration read. It does not explain input limits or return format details, but the annotations cover the safety profile.

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 short and front-loads the core purpose, asset classes, and aggregation behavior. The interactive URL and repeated class list are mildly extraneous but do not obscure the main message.

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 one required parameter, full schema coverage, and rich annotations, the description is nearly sufficient for correct selection and invocation. Because no output schema exists, it could more fully describe the return structure, but naming the diversification score and concentration read provides adequate context for this simple 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 parameter and nested fields are already well documented. The description adds meaningful processing semantics by stating that holdings in the same class are summed, which goes beyond the schema's per-holding definitions.

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 clearly states that the tool analyzes portfolio allocation across named asset classes and returns a diversification score and concentration read. It also explains that holdings in the same asset class are summed. It does not explicitly differentiate from siblings, but no sibling is similarly scoped.

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 intended use is implied by the name and description: analyzing a portfolio's asset-class allocation. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that this is a read-only, idempotent, non-destructive calculation. The description adds useful context about what results are produced, but does not disclose calculation assumptions, rounding, or edge-case behavior beyond what the annotations and schema imply.

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 compact, front-loads the target user and the three outputs, and avoids unnecessary repetition. The external interactive link is optional and slightly extraneous for tool invocation, keeping it from a full 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?

With no output schema, the description appropriately explains the three main outputs. It is nearly complete for a calculation tool, though it would benefit from stating key assumptions such as fully diluted ownership treatment or rounding conventions.

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 in detail. The description helps frame what the inputs produce, but it does not add syntax or semantic detail beyond the schema fields themselves.

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 clear specific purpose: calculating pro rata check size, post-round ownership, and stake value for an existing investor in a new round. It does not explicitly distinguish this from related sibling tools such as dilution or convertible_note, 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?

It gives a clear usage condition: 'For an existing investor in a new round.' However, it does not say when not to use the tool or name alternatives for related calculations like dilution or startup_valuation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing the modeled rules (tiered 3/4/5-year exclusions, $15M cap, post-July 4 2025 acquisition split) and the qualifying-stock assumption, though it says nothing about the output or precision of the estimate.

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 tight sentences plus a link, with the core purpose and rule vintage front-loaded and the caveat immediately after. Nothing is wasted and nothing is buried.

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, the description should say what comes back (exclusion amount, tier applied, taxable remainder), but it does not. The modeling scope and assumption are well covered, so it is adequate but leaves the agent guessing at the return shape.

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 five parameters are already documented, making 3 the baseline. The description adds only indirect meaning — the July 4 2025 acquisition cutoff and the $15M lifetime cap hint at how acquired_date and prior_gain_usd interact — but gives no explicit parameter guidance.

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 (estimates) and a precisely scoped resource (US federal capital gains exclusion for QSBS under IRC Section 1202), plus the rule vintage it models. An agent can tell this apart from siblings like tax_deadlines or startup_valuation without opening the 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?

The clause 'Assumes the stock otherwise qualifies' sets an important precondition, implying this is a computation tool rather than a qualification checker. However, no alternative tool is named and there is no explicit when-not guidance, so routing is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower, and the description still adds real value: it explains the semantics of the combined score and the 40-point interpretation threshold that no annotation conveys. It does not say whether the returned value is the raw sum or a pass/fail verdict, which keeps it off a 5.

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 short sentences, front-loaded with the operation itself, then the interpretation threshold, then the alternative routing and reference link. Nothing is redundant and nothing is buried.

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-input pure calculator with full annotation coverage and a rich schema, the description covers formula, units, interpretation, and alternatives. The only gap is the shape of the return value, which matters slightly more here because there is no output schema to fall back on.

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 both parameters documenting units, sign conventions, and bounds, so the schema already does the heavy lifting. The description's note that profit margin is "usually EBITDA or free cash flow margin" is a modest addition rather than new information, 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?

The description opens with a precise verb-resource statement: it 'adds revenue growth rate and profit margin' into a single score, which is exactly what this calculator does. It also differentiates itself from the sibling burn_multiple by name, so an agent can pick between them 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?

It gives an explicit alternative route ("Use burn_multiple for capital efficiency instead") plus the interpretive threshold of 40 for a healthy software company, which tells the agent what context this metric belongs to. It stops short of stating the inverse condition — when Rule of 40 is the right choice — leaving that to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered without the description's help. The description adds value beyond that by disclosing what the computation returns — the break-even month and a 'default alive within 10 years' verdict — which the agent could not infer from the annotations or input schema. It still omits behavior at edge cases (a monthly burn of 0, infinite runway), so not a 5.

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 computation and packed into a single dense sentence with no filler; the mode distinction appears early enough to orient the agent. It is slightly overstuffed, stacking outputs and a URL into the same sentence rather than separating them.

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 8 parameters fully documented in the schema, no output schema, and annotations covering side effects, the description supplies the missing piece — what the result contains (runway months, break-even month, default-alive flag). A brief note on how modes interact with the optional growth parameters would make it fully 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% and each parameter already carries a mode-tagged explanation plus defaults and bounds, so the schema does the heavy lifting. The description only reiterates the mode split and does not add cross-parameter semantics such as which fields are ignored in burn mode versus pl mode, leaving it at the baseline 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?

States a specific computation (months of cash runway) with its two input regimes named explicitly ('burn' mode vs 'pl' mode), plus the outputs it produces. This clearly separates it from siblings like burn_multiple or rule_of_40, which measure ratios rather than runway length.

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 tells the agent how to choose between the two modes based on what data it has (net burn vs. revenue + expenses), which is genuine selection guidance. However, it never says when to reach for this tool instead of a sibling such as burn_multiple, nor does it state preconditions or exclusions (e.g., zero burn, negative runway).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds what the computation produces – conversion price, which of cap/discount applies, shares issued, post-round ownership and pool top-up – which is real behavioral context beyond the annotations. It doesn't flag edge cases (no cap and no discount, or both provided) but is otherwise informative.

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 front-loaded sentences with zero filler, plus a single supplementary link. The core purpose and the sibling distinction come before the optional URL.

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, the description carries the burden of telling the agent what comes back, and it does list the calculated result fields. It's slightly thin on tie-breaking rules (cap vs discount) and default-behavior edge cases, but covers what an agent needs to call the tool.

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 each parameter (including safe_type enum and discount_pct semantics) fully documented, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides.

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: converts a YC-style SAFE (post- or pre-money) in a priced equity round, and enumerates the outputs (conversion price, cap-vs-discount, shares issued, post-round ownership, option pool top-up). It also names the sibling convertible_note as the tool for a different instrument, so an agent can separate the two without opening schemas.

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?

Explicitly routes interest-accruing notes to convertible_note, which is a real alternative in the sibling list. The scope condition 'in a priced equity round' is stated. No explicit when-not beyond the note distinction, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is free. The description adds real context on top: the size and nature of the corpus (549 articles) and the shape of the return (titles, URLs, summaries, matching section headings), which is what makes the closedWorldHint credible. Ranking behavior and empty-result handling are unstated.

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 sentences, front-loaded with the verb and corpus, then the return shape, then the alternative. Every sentence carries distinct information and nothing is repeated from 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?

There is no output schema, and the description compensates by enumerating the returned fields, so an agent knows what it will get. For a two-parameter read-only search over a fixed corpus, nothing needed 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 coverage is 100% — both query and limit are documented in-schema with defaults, bounds and an example. The description adds no constraint or format detail beyond that, 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 (search 549 Learn articles) plus the exact subject domain — SAFEs, cap tables, K-1s, QSBS — so an agent can tell this is a content search, not one of the many calculator siblings. It also names the sibling it is not (define_term).

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?

Explicitly routes the one-line-definition case to define_term, which is the most likely confusion point among the siblings. It does not address when to prefer a calculator sibling (e.g. safe_conversion, qsbs) over searching an article, so it stops short of full when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so safety needs no restating. The description goes beyond them by enumerating the computed results (discounted sale price, fees, net proceeds, gain over cost basis, implied valuation), which is the main behavioral thing an agent needs since there is no output schema. It says nothing about unit assumptions or error cases, so not a 5.

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?

One front-loaded sentence that lists outputs, plus one short reference link – no filler. It is a slightly dense run-on list, but every clause carries real 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?

With no output schema, the description correctly spends its words describing the return values, and all eight parameters are documented in the schema. Missing only minor context: that shares_sold is the sole required input and which inputs are conditioned on the other (valuation basis).

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 every parameter including the price_basis enum is already documented. The description only echoes a few field concepts (discount/premium, fees, cost basis) without adding syntax or cross-parameter rules such as valuation basis requiring fully_diluted_shares. 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?

Opens with a specific verb+resource ("Proceeds from selling private company shares on the secondary market") and enumerates exactly which quantities it computes, so an agent can tell this is a proceeds/gain calculator rather than a valuation or dilution tool. It does not name a sibling it differs from, keeping it just short of 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?

The phrase "selling private company shares on the secondary market" implies the situation, and the trailing link points to a richer interactive version. But there is no explicit when-to-use/when-not guidance and no mention of adjacent siblings like startup_valuation or dilution that an agent might otherwise pick.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive and openWorld=false, so the safety profile is covered. The description adds what a calculator needs to add: it is a pure deterministic math operation and it spells out which quantities get computed plus the ownership formula. It stops short of stating assumptions like the pool being carved from founders' shares or behavior at the 30% pool cap, which the schema only partially covers.

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 dense sentences: outputs first, then routing, then an optional interactive link. No restatement of the title, no filler, and the most decision-relevant information is front-loaded.

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, the description correctly compensates by naming the return values, and the sibling routing closes the main ambiguity for a family of overlapping finance calculators. Remaining gaps are minor: no statement of what happens at the pool maximum or of the pre-money/share-price inputs' assumptions, but the tool is simple enough that this is close to 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%, so all four parameters are already documented, including the founders'-share note on option_pool_pct. The description mentions founder dilution and the investment/post-money formula, which adds light context but no syntax or edge-case guidance 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?

States a specific computation (pre-money to post-money for a single priced round) and enumerates exactly what it returns: post-money, price per share, new shares issued, investor ownership, founder dilution. That verb+resource+output framing makes it immediately distinguishable from sibling calculators.

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?

Explicitly scopes usage to a single priced round and routes the agent elsewhere for other cases: 'Use dilution for several rounds and option_pool for pool math.' Both alternatives and the condition selecting them are named, leaving no inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only and idempotent annotations, the description discloses the actual calculation rules: the 30-day 83(b) deadline with business-day rolling, and the QSBS 3/4/5-year exclusion milestones with a July 4, 2025 acquisition cutoff. These details materially help an agent understand the tool's behavior and trust its outputs.

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 front-loaded with the core purpose and then compactly explains each date parameter. Every sentence carries substantive information, including the sibling-tool routing and calculator link, with no filler.

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 low-complexity date calculator with full schema coverage and clear annotations, the description is largely complete. The only notable gap is that it does not describe the return format or output shape, which is not covered by an output schema.

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 all three parameters. The description still adds useful semantic depth for `stock_grant_date` and `qsbs_acquired_date` by explaining the exact deadlines and milestones each date triggers, though it does not add anything about `as_of_date` beyond 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?

The description states that the tool returns key US equity tax dates, specifically 83(b) election and QSBS holding-period milestones. It distinguishes itself from the sibling `qsbs` tool by directing agents to use `qsbs` for the dollar exclusion on a sale, making the boundary clear.

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 explicitly says to provide either or both date parameters and names the alternative `qsbs` tool for a different purpose. This gives an agent clear routing guidance between this date calculator and the QSBS dollar-exclusion tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 fully covered structurally. The description adds domain semantics (DPI is realized, RVPI unrealized) but nothing about the result shape, the extra called-percentage output from commitment_usd, or unit conventions. With annotations doing the heavy lifting, this is adequate rather than rich.

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 tight sentences: the first defines the outputs, the second routes to alternatives, and a reference link trails at the end. Zero filler and the core purpose is front-loaded.

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, the description usefully tells the agent that TVPI, DPI and RVPI are the returns, which is enough to interpret results. The one omission is that commitment_usd also produces a called percentage, so an agent cannot anticipate that secondary output without reading the schema.

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 every property documented (including the exclusiveMinimum on paid_in_usd and commitment_usd's 'used only for the called percentage'). The description adds no parameter-level detail beyond the metric definitions, 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 resource (fund performance multiples for an LP or fund) and enumerates the exact metrics computed — TVPI, DPI, RVPI — with parenthetical expansions. It also explicitly separates itself from moic (single deal) and xirr (time-weighted returns), so an agent can choose it 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?

Names two concrete alternatives with the condition that selects each: moic for a single deal, xirr for time-weighted returns. It does not say when TVPI/DPI is the wrong choice versus irr or cash_on_cash, but the routing guidance it does give is explicit and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds the computational semantics (annualized, date-driven), but omits material behavior: XIRR requires at least one negative and one positive flow to converge, and can fail to converge — neither the schema nor the description warns of that, so an agent could pass two same-signed flows and get an error it cannot anticipate.

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 plus a link, front-loaded with the definition and immediately followed by the disambiguation. The interactive-calculator URL is marginally promotional but plausibly useful for a human, and no sentence is wasted.

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 one-parameter, read-only, no-output-schema tool, the description says what comes back (an annualized return) and how it differs from the sibling. The only real gap is the undisclosed convergence/sign requirement, which matters for a numerically solved function.

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% and the schema already documents sign convention, date format, ordering and the 2–500 item bounds. The description adds only the notion of irregular timing, which is already implied by the per-item dates, so it sits at the baseline rather than adding meaning.

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 computation (annualized return / XIRR) over a specific resource (dated cash flows) and anchors it to a familiar reference ('like Excel XIRR'). It also explicitly distinguishes itself from the sibling tool irr, so an agent can pick correctly 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?

Gives explicit when-to-use ('real investments with irregular timing — capital calls, distributions, follow-ons') and an explicit when-not with the named alternative ('use irr only for evenly spaced yearly flows'). This is the routing information an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.