Rahul D Sarker: Marketing & RevOps Tools

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that scoring is weighted across five checks and produces a 0-100 verdict, but it omits any detail on determinism, how partial answers are weighted, or what the response payload contains.

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 first sentence is dense and front-loaded with the graded criteria and output scale. The second sentence is a marketing pointer to an external site that does not help an agent call the tool, a minor but real waste.

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 five required enum parameters fully documented in the schema and no output schema, the description supplies the missing piece by stating the output is a 0-100 clarity verdict. It stops short of describing sub-scores or verdict bands, but nothing essential to invoking it correctly is absent.

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 of the five enum parameters already documents its weight in the schema. The description's parenthetical list mirrors those same check names without adding syntax or interpretation beyond what the schema provides, 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 a specific verb (Score) and resource (a hero section's five-second clarity), enumerates the five weighted checks, and states the output form (0-100 verdict). It implicitly separates itself from near-neighbors like cta_visual_hierarchy_tester and value_prop_strength_grader, but never names or contrasts with them 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?

There is no statement of when to reach for this tool versus the many sibling graders, no prerequisites, and no exclusions. The only additional context is a link to an external 'full version,' which is promotional rather than routing guidance.

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. The description adds that the result includes relative uplift and statistical confidence, which is genuinely useful given there is no output schema, but it omits test assumptions and any caveats about validity.

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 short sentences, with the core operation and outputs front-loaded before the external link. The second sentence contributes little to invocation correctness, but the total length is small enough that waste is minimal.

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 pure four-number computation with fully documented parameters and clear safety annotations, the description is sufficient: it names the test performed and the two result values returned. Only the absence of statistical assumptions or a hint at the response format keeps it from being 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 of the four parameters is documented as visitors/conversions for control vs test variants. The description adds no additional parameter meaning, so the baseline of 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 precise statistical operation (two-proportion z-test) on a specific input domain (an A/B test) and names its outputs (relative uplift, statistical confidence). No sibling tool performs significance testing, so the name and verb effectively distinguish it, though the description never says so 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?

There is no guidance on when to use this versus other calculators, no prerequisites (e.g., minimum sample size, one- vs two-tailed test), and no exclusions. The trailing external link is promotional rather than a routing cue.

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 destructiveHint=false, so the safety profile is covered. The description adds that the output concerns revenue concentration and per-customer averages, which is useful context, but says nothing about determinism, units, or the shape of the result. Adequate but not 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?

The first sentence is dense and front-loaded with the core purpose. The second sentence is a promotional link to an external calculator site, which does not help an agent invoke the tool and dilutes an otherwise efficient definition.

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, annotation-covered computation with no output schema, the description conveys what is computed but not what the result looks like or how it should be interpreted. It covers the essentials without fully compensating for the missing 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 description coverage is 100% and all four parameters (smbCount, smbAcv, entCount, entAcv) are individually documented in the schema. The description adds no syntax, unit, or format detail beyond that, so the baseline of 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 (break ARR down by SMB vs enterprise) plus the purpose of the output (revenue concentration, per-customer averages). This clearly distinguishes it from sibling ratio tools like mrr_to_arr_calculator or arr_multiple_calculator, 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?

There is no when-to-use guidance, no prerequisite, and no routing to alternatives such as mrr_bridge_planner or arr_multiple_calculator. A reader must infer from the description alone that this is for segment-weighting analysis.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, covering the safety profile. The description adds no behavioral context beyond what annotations provide—no note about rate limits, output format, or authentication needs. It merely restates the purpose.

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 first sentence is front-loaded and directly states what the tool does. The second sentence is a promotional link to an external calculator website, which does not help an agent invoke the tool and slightly detracts from conciseness.

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 a simple calculator with three numeric parameters, full schema coverage, and no output schema, the description does mention the key outputs: days until fatigue and the date to have fresh creative ready. It could be slightly more explicit about the return format, but it is largely complete for this tool's complexity.

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 fully documents each parameter with meanings like 'fatigue frequency ceiling' and 'audience / reach size'. The description adds no additional parameter context, so the baseline of 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?

The description states a specific verb (forecast) and resource (days until ad audience hits fatigue frequency ceiling, and date for fresh creative). It is clear what the tool computes, but it does not explicitly differentiate itself from similar siblings like ad_frequency_risk_checker or creative_testing_duration_forecaster.

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 no guidance on when to use this tool versus alternatives. It does not state prerequisites, exclusions, or name any sibling tool that could be used instead. Usage is only implied by the tool's purpose.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds that the tool classifies frequency into healthy/caution/fatigue territory, which is useful output behavior beyond annotations. It doesn't detail auth or rate limits, but none are expected 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 first sentence is front-loaded and compact, but the second sentence is a promotional link that does not help an agent invoke the tool and therefore does not earn 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 simple two-parameter calculator with no output schema, the description states the calculation and the output categories. Annotations cover safety. It is largely complete, though it does not define the numeric thresholds for the healthy/caution/fatigue classification.

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 parameters are fully documented in the schema. The description names impressions and reach but adds no syntax or format beyond what the schema already provides; 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 verb (Calculate) and resource (average ad frequency from impressions and reach), and specifies the output classification (healthy/caution/fatigue). An agent can distinguish it from sibling ad_creative_fatigue_forecaster, which forecasts creative fatigue rather than frequency risk.

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?

No explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Usage is merely implied by the tool name and calculation.

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 fully covered. The description adds the scope of the calculation (fraud + tracking/attribution leakage) but says nothing about output shape or that it is a purely deterministic arithmetic 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?

The first sentence is a tight, front-loaded purpose statement. The second sentence is a promotional link to an external calculator site and does not help an agent decide or invoke the tool, so it does not earn 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 stateless 3-param calculator with no output schema and covering annotations, the definition is adequate but thin: it never indicates the form of the result (a currency amount of wasted spend) or its deterministic, side-effect-free nature beyond what annotations imply.

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 all three parameters (monthlySpend, fraudPct, leakagePct) are documented in the schema itself. The description adds no extra meaning, 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 states a specific verb and resource: estimating monthly ad budget lost to fraud and tracking/attribution waste. It is clearly distinct from most siblings (e.g. roas_calculator, competitor_ad_spend_benchmarker) by naming the two loss sources. It stops short of explicitly differentiating itself from near-neighbors such as cpa_to_cac_scalability_matrix.

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?

There is no statement of when to use this tool, when not to, or what alternative to pick if the user wants ROAS or CPM-style analysis. Usage can only be inferred from the name and description's subject.

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 as a safe, read-only, idempotent, non-destructive, closed-world calculation, so the safety profile is fully covered structurally. The description adds that it outputs a quantified loss figure derived from four hand-off dimensions, but says nothing about response shape, units, or assumptions. With annotations carrying the safety burden, a 3 is appropriate.

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: the first front-loads the purpose and scope, the second is a promotional link. The core description is tight and well-ordered, though the URL line is marketing rather than functional guidance for an agent.

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 7-required-parameter calculator with no output schema, the description conveys the inputs' intent and the modeled outcome, but never indicates what the result actually contains (meetings lost, revenue lost, both, breakdowns). The scenario is covered but the computed output remains unspecified.

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 all seven parameters (including the four enums and three numerics) are individually documented, so the schema does the heavy lifting. The description names the four qualitative dimensions that map to the enum parameters but adds no ranges, units, or format guidance beyond the schema. 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 ('Quantify') and the exact resource/outcome ('meetings and revenue lost'), plus the failure mode it models (SDR-to-AE hand-off inconsistency) and the four contributing dimensions. It does not name or differentiate from close siblings like lead_routing_delay_cost_calculator or mql_to_sales_disconnect_analyzer, 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?

The usage context is implied by the framing ('when the SDR-to-AE hand-off is inconsistent'), which is enough to infer when to reach for it. However, there is no explicit when-to-use statement, no prerequisites, and no alternative siblings named for adjacent analyses, leaving the guidance implicit.

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 fully covered. The description adds value by spelling out the input-to-output computational chain, which is the only behavioral trait a pure calculator has. It does not add edge-case or error behavior, but none is really needed here.

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, calculation purpose front-loaded, zero wasted preamble. The trailing promotional URL is a minor cost but takes little space and is clearly separable.

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, and the description does state the output ('traffic and leads needed per month'), covering the essential return expectation. For a deterministic single-result calculator with full annotation and schema coverage, this is adequate; a note on output units or format is the only missing piece.

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 (revenueGoal, acv, leadToCustomerPct, visitorToLeadPct) are already documented in the schema. The description mentions ACV and close rates in prose but adds no format, unit, or range detail beyond the schema (e.g., that percentages are 0-100). 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?

The description names a specific verb ('work backwards') and describes the exact computation chain: from annual revenue goal through ACV and close rates down to monthly traffic and leads. An agent can tell this is a reverse-funnel planning calculator. It stops short of explicitly differentiating itself from the many closely related funnel/ACV siblings, so not 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?

No when-to-use guidance and no named alternatives despite a dense sibling field (acv_weight_planner, pipeline_velocity_equation_engine, conversion_funnel). Usage is only implied by the calculation described. Nothing tells the agent when this back-calculation is preferred over a forward-planning 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds only that it computes an implied valuation range, which is modest additional context beyond what the annotations provide, so a 3 is appropriate.

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 first sentence is efficient and front-loaded with the core action and result. The second sentence is an external marketing link that adds little for an agent, but overall the description is short and not padded.

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 five fully documented parameters and no output schema, the description gives enough context: it names the multiple types, states the input (ARR implicitly via schema), and describes the output as an implied valuation range. It could be slightly more explicit about the output format, but it is largely 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 all five parameters (arr, conservativeMultiple, marketMultiple, premiumMultiple, customMultiple) are documented in the schema. The description mentions the multiple types but adds no syntax, format, or constraint details beyond the schema, so the baseline of 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 states a specific verb ('Apply') and resource ('ARR multiples') and explains the outcome ('see the valuation range they imply'). It is clear but does not differentiate from sibling valuation tools such as saas_valuation_multiple_predictor or mrr_to_arr_calculator.

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?

There is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The purpose implies use for valuation range estimation, but it does not tell an agent when this tool is the right choice over similar siblings.

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 destructiveHint=false, so the safety profile is covered. The description adds the behavior that the calculation reports both the delayed revenue and a halved-delay recovery scenario, which is useful, but it says nothing about units, currency handling, or what the result contains.

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 tightly written sentence front-loads the core computation. The trailing promotional URL is the only wasted token, but it does not obscure the purpose.

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 read-only calculator with full schema coverage and no output schema, the description conveys what is computed and the dual output (delay cost plus halving benefit). It is complete enough to invoke correctly, with only minor gaps around output units.

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 acv, delayWeeks, and dealsPerYear are each documented in the schema itself. The description adds no unit, range, or format detail beyond that, so the baseline of 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 a specific verb ('Estimate') and a precisely scoped resource: revenue delayed by the onboarding gap between signature and go-live, plus the recovery from halving it. This distinguishes it from near-neighbors like lead_routing_delay_cost_calculator and contract_redline_duration_predictor without needing to open 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?

There is no statement about when to reach for this tool versus the many other cost/delay calculators in the sibling list, nor any prerequisites or exclusions. The only extra guidance is an outbound link, which does not tell the agent when this model 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 declare this is a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is covered. The description adds that a break-even exit value is derived, but says nothing about currency assumptions, how dilution is treated, or what the comparison is normalized to. It adds some context without rich behavioral detail.

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 purpose is front-loaded in one efficient sentence. The trailing promotional line pointing to an external URL is not functional guidance for invoking the tool, so the definition is slightly padded rather than waste-free.

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 does at least name the two outputs an agent should expect (take-home comparison and break-even exit value). For a fully specified, read-only four-parameter calculator that is reasonably complete, though it stops short of describing result structure or assumptions.

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%, with all four required parameters individually described (exit value and ownership percentage per path). The description restates the two paths but adds no format, unit, or range guidance beyond the schema, so the baseline of 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?

Specific verb (compare) plus two named resources (bootstrapped exit vs venture-backed, diluted exit) and a concrete derived output (break-even exit value). This is clearly distinguishable from sibling calculators like arr_multiple_calculator or saas_valuation_multiple_predictor 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?

The implied use case (a founder weighing bootstrapping vs raising) is easy to infer, but there is no explicit when-to-use, no conditions that select it over a sibling, and no exclusions. Usage is implied rather than stated.

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 destructiveHint=false, so the safety profile is covered. The description adds real context by citing the Binet & Field research as the basis and calling the output a 'directional guide,' which warns the agent the result is heuristic rather than a precise model. It does not describe the shape of the result or any precision caveats beyond that single word.

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 sentence is front-loaded, single-purpose, and free of filler, which is well sized for a two-parameter calculator. The trailing external URL is mild promotional noise that does not help an agent invoke the tool, but it costs only a clause.

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 tool with full schema coverage and no output schema, the description is nearly adequate. However, with no output schema present, it should say what comes back (allocation percentages, dollar splits, or an explanation) – 'directional guide' only partially fills that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the stage enum is fully enumerated with inline meanings, so the schema carries the parameter burden. The description contributes nothing beyond 'based on company stage,' which restates what the schema already documents. 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 names a specific verb and resource: it splits a marketing budget into brand and performance spend, and pairs that with the Binet & Field long/short framing, which is a distinctive methodology. It is enough to distinguish it from generic budget tools like cross_channel_ad_spend_allocator or marketing_budget, though it never explicitly names a sibling.

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: 'based on company stage' hints that the tool is for stage-appropriate allocation decisions, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent would have to infer that this is for strategic brand/performance mix rather than channel-level allocation.

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 closed-world, so the safety profile is covered. The description usefully adds that the computation is a month-by-month forward simulation producing two specific results, but it omits any horizon cap or assumption about how far the simulation runs.

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 capability is front-loaded in the first sentence with zero preamble. The trailing promotional link to the full web calculator adds little for an agent and is the only wasted text.

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 results and does so: months to gross-profit coverage plus bridging cash. For a deterministic four-parameter calculator with full schema coverage this is close to sufficient, missing only simulation-horizon or assumption caveats.

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 all four parameters (revenue, growthRatePct, fixedBurn, grossMarginPct) documented in the schema itself. The description references growth rate, gross margin and fixed burn narratively but adds no units, ranges, or interpretation beyond the schema, so the baseline of 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 gives a specific verb (simulate month by month) plus the resource and even the computed outputs: months until gross profit covers fixed burn and the cash needed to bridge the gap. That is far more concrete than a tautology, though it never names or distinguishes itself from near siblings like growth_runway_extension_simulator or rule_of_40_sandbox.

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 states the input conditions (given revenue growth rate and gross margin) but gives no when-to-use framing, no exclusions, and no pointer to any alternative runway/forecast sibling. An agent must infer the use case from the purpose alone.

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 destructiveHint=false, so the safety profile is covered. The description adds that CAC is treated as fully-loaded and that results are computed on two bases, which is modest value, but it discloses nothing about output shape, rounding, or edge cases like zero gross margin.

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 sentence is front-loaded, precise, and wastes no words. The trailing URL is a self-promotional line that does not help invocation, costing it a perfect score.

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?

A small three-parameter calculator with full schema coverage and no output schema, so the description need not explain returns. Still, it never states what the tool produces (months per basis) or how the two bases are reported, leaving an agent to infer 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 in the schema; baseline is 3. The description hints at the role of grossMarginPct through the gross-margin-basis framing but adds no format or unit detail 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?

States a specific verb and resource: calculating months to recover fully-loaded CAC, and distinguishes two computation bases (gross-margin vs raw-revenue). It does not differentiate itself from nearby siblings such as ltv_cac_calculator or cpa_to_cac_scalability_matrix, so an agent must infer the boundary.

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?

There is no statement of when to use this tool versus the many CAC/LTV-adjacent siblings, nor any prerequisites or exclusions. The only routing context is an external promotional link, which does not help an agent choose between 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered and the description cannot contradict it. The description adds that this is a pure what-if calculation producing a loss and recovery figure, but says nothing about output format, units, or assumptions behind the estimate (e.g., whether recovery applies to all abandoned carts).

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 first sentence is front-loaded and efficient, naming both computed quantities in one clause. The trailing URL is mildly promotional filler but short and clearly separated from the functional statement.

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, annotation-covered calculator with no output schema, the description conveys what the tool returns (lost revenue and recovery upside) and the schema documents every input. Only the absence of usage context and any note on assumptions keeps it from being fully self-sufficient.

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 per-field descriptions including a useful benchmark (industry average near 70%), so the schema carries the parameter semantics. The description adds no unit, range, or format guidance beyond what is already structured, matching the baseline 3 for a fully documented 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 verb and two concrete outputs: revenue lost to cart abandonment and the win-back opportunity from a recovery flow. That is far more informative than a tautological restatement of the name, though it never contrasts itself with near siblings such as mobile_checkout_friction_tester or conversion_funnel.

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 no when-to-use framing, no prerequisites, and no alternatives; the second sentence is only a promotional link. An agent can infer this is an ecommerce revenue calculator, but nothing routes it here over a sibling 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description's only behavioral addition is the compounding-inflation model, which is useful context but not a disclosure of assumptions, edge cases, or how the projection behaves when CPA is already above the max.

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 first sentence is well-formed and front-loads the purpose, but the second sentence is a marketing link that does not help an agent decide or invoke the tool. Roughly half the description is non-functional for the caller.

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 3-parameter numeric calculator with no output schema, the description should say what comes back (a month count, a boolean crossover flag, or 'never' when inflation is zero/negative). It leaves the return shape and the compounding assumption implicit, which is a real gap even though the tool itself is simple.

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 in the schema, establishing the baseline of 3. The description adds no format, unit, or range detail (e.g., percentage as 5 vs 0.05) beyond what the schema 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?

The description states a specific computation: projecting how many months until compounding CPA inflation crosses a max viable CPA. That verb+resource pairing is clear and distinguishable from siblings like cpa_to_cac_scalability_matrix or ad_creative_fatigue_forecaster, but it never explicitly names or rules out any sibling, which keeps it 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?

There is no statement of when to use this tool versus the many other CPA/unit-economics calculators, no prerequisites, and no exclusions. The only extra sentence points to an external web page, which is promotional rather than guidance.

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/openWorld/non-destructive, so the safety profile is covered. The description adds genuine context beyond that: each returned time carries a link that opens the booking form with the time pre-selected, and the actual confirmation/booking happens on the site, not through this tool. That clarifies the read-only boundary of the call.

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 core action before the mechanics and the usage condition. Each sentence earns its place, though the consultant credential aside ('fractional CMO and RevOps consultant') is mildly promotional rather than operational.

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 returns, and it does so adequately by describing the shape of each entry (a time plus a booking link). Combined with fully documented optional params and read-only annotations, an agent has what it needs to invoke and interpret 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 days (1-21), timezone (IANA), and meetingType fully documented in the schema. The description adds no parameter-level meaning of its own, so the baseline 3 is correct given 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+resource ('List open times for a free call with Rahul D Sarker') with the source of truth ('live from his calendar'). This is instantly distinguishable from the entire sibling set, which is calculators and graders rather than availability lookups.

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 usage contexts: 'Use when someone wants to talk to Rahul, get help with their marketing or RevOps, or book a consultation.' Clear triggering conditions, though it names no alternatives or when-not-to-use condition (none of the siblings overlap, so this is a minor gap).

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It usefully discloses the core assumption that spend ≈ share of voice within the same auction, which is real behavioral/interpretation context. It stops short of noting sensitivity, caveats, or what is returned.

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 short sentences, front-loaded with the actual operation before the assumption. The marketing URL is mild noise that does not help an agent select or invoke the tool, keeping it from a 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?

For a stateless three-input calculator with full schema coverage and safe annotations, the essentials are present. However, with no output schema the description never states what it returns (a single estimated spend figure) or any accuracy caveat, leaving a gap an agent might want when interpreting results.

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% (each of the three parameters is documented, including that competitorSovPct can come from an auction-insights tool), so the schema carries the load and a 3 is the baseline. The description adds the auction-matching assumption but no unit/format nuance 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?

States a specific verb (Estimate) and resource (a competitor's ad spend) plus the input basis (share-of-voice data), so the agent knows exactly what it computes. It does not, however, differentiate itself from near-neighbors like google_search_impression_share_value_estimator or impression_share_opportunity_matrix. Clear but no explicit sibling routing.

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?

There is no 'use this when…' guidance and no alternative tool is named or excluded. The description hints at the methodology (spend maps to share of voice in the same auction) but says nothing about prerequisites, e.g. that the three inputs must come from the same auction/category, or when another spend tool would be preferable.

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 fully covered. The description adds no behavioral context beyond the predictions themselves (no auth, rate limits, or operational constraints), leaving it purely output-oriented.

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 and efficient: the first sentence states the core value proposition, and the second is a brief link. The link is arguably promotional noise for an agent, but the overall text is tight and well-structured.

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 gives a high-level list of what is predicted but does not specify return format (e.g., days, probability, dollar amount). For a six-parameter calculator, this is adequate but leaves an agent guessing about output structure.

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 fully documents all six parameters, including the 'paper' enum with its 1.8x multiplier note. The description adds no additional meaning, 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 (predict) and three concrete outputs: redline duration, quarter-end slip risk, and revenue at risk. This clearly distinguishes it from generic calculators, though it doesn't name any sibling for contrast.

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?

No when-to-use guidance, no prerequisites, and no alternatives mentioned. The agent must infer from the name alone that this is for legal redline duration forecasting, with no help on when to pick it over similar siblings like sales_cycle_length_forecaster.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is already covered. The description adds that it computes two outputs (conversion rate and traffic needed), but does not disclose return format, precision, or assumptions.

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 with the core function front-loaded. The external link to a full version is extra but brief and does not bury the essential 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?

No output schema exists, so the description should cover return values; it names the two computed results. For a simple calculator with complete parameter docs and clear annotations, this is sufficient, though it omits assumptions such as linear extrapolation.

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 documented in the schema. The description references target and traffic needed but adds no syntax, format, range, or constraints beyond what the schema 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: calculate conversion rate and the traffic needed to hit a target number of conversions at that rate. Clear, but does not distinguish it from many sibling calculators such as cpl_cpa_calculator or roas_calculator.

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?

Implies a conversion-funnel or target-planning context but gives no explicit when-to-use versus alternatives, no exclusions, and no prerequisites. No sibling tool is named to route the agent.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows it's a safe, pure calculation. The description adds nothing beyond that—no mention of output format, error behavior, or assumptions. With annotations covering safety, a 2 reflects minimal added behavioral context.

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 a single sentence and a URL. The first sentence is concise and front-loads the key function. However, the URL is extraneous to tool invocation and adds noise. It's adequately sized but not optimally structured for an agent.

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 3-parameter read-only calculator with full schema coverage and no output schema, the description is adequate but minimal. It doesn't explain the output (e.g., what the matrix contains) or assumptions, which could be helpful since there's no output schema. It's minimally 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 the schema already documents all three parameters (cpa, spend, decayPct) with clear descriptions. The description doesn't add any parameter-specific semantics beyond what the schema provides. Baseline 3 is appropriate when schema fully covers parameters.

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 projection task: projecting CPA/CAC inflation at double and triple spend given a decay rate. It's clear what the tool does, but it doesn't distinguish itself from sibling tools (e.g., cpl_cpa_calculator, ltv_cac_calculator) or explain how its output differs from them. No sibling differentiation lowers the score.

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 offers no guidance on when to use this tool versus alternatives like cpl_cpa_calculator or ltv_cac_calculator. It also doesn't state prerequisites or assumptions (e.g., constant decay rate). It merely describes the action without context.

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 fully covered structurally. The description adds the input-to-output mapping (spend + leads + convPct → CPL/customers/CPA), but says nothing about the formula used, rounding, units, or edge cases like zero leads.

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 sentence is well-formed and front-loaded, but the trailing marketing link to an external site consumes space without helping an agent decide or invoke the tool. Roughly half the text is actionable.

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 does name the three computed results, which gives some return-value signal. It stops short of describing result structure, units, or failure behavior for a tool with three required numeric inputs.

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% with all three parameters documented in the schema, so the baseline is 3. The description does clarify that convPct is a lead-to-customer conversion rate, which mirrors the schema rather than extending it, and adds no format or unit guidance beyond that.

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 (calculate) and names the exact outputs (cost per lead, expected customers, cost per acquisition) plus the three inputs that produce them. It does not, however, differentiate itself from adjacent siblings such as ltv_cac_calculator, cpa_to_cac_scalability_matrix, or roas_calculator, so an agent must infer which one applies.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. The only routing hint is the sibling list itself, which the description does not exploit.

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 fully covered. The description adds only the calculation inputs, restated from the schema, with no assumptions, rounding, edge cases (e.g. zero CPA/spend), or output shape disclosed. Adequate but not 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?

The first sentence is front-loaded and functional, but the second sentence is a marketing URL that consumes space without helping an agent decide to call or how to invoke the tool. Not wasteful enough to be poor, but not tight.

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 deterministic calculator with full annotations and no output schema, the description conveys both the input model and the unit of the result ('how many days'). Only the exact return structure and formula assumptions are missing, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema itself. The description mirrors those same labels ('daily spend, expected CPA, variant count, conversions needed per variant') without adding units, ranges, or format detail, so the baseline of 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: forecast the number of days an ad creative test needs to reach a sound sample size, and names the four inputs that drive the estimate. It does not explicitly differentiate itself from near neighbors like ab_test_significance_calculator or ad_creative_fatigue_forecaster, but the purpose is clear on its own.

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?

No when-to-use guidance, no prerequisites, and no routing to or away from sibling tools such as the significance calculator or fatigue forecaster. The only extra sentence is a promotional link to an external site, which gives no invocation guidance.

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 safe-read profile is fully covered. The description adds a partial picture of what is returned (annual hours lost, revenue lost, freed capacity), which is useful since there is no output schema, but it says nothing about units, currency, or assumptions.

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 first sentence is front-loaded and states the value proposition without waste. The second sentence is a promotional link rather than invocation-relevant information, which costs a point but is harmless.

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 three-parameter, closed-world read-only calculator with no output schema, the description names the salient outputs, which is enough to call it correctly. It would be stronger with a note on assumptions or how it differs from crm_roi_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 reps, hoursWastedPerWeek, and hourlyCost are already documented in the schema. The description adds no unit or format guidance (e.g. annualized vs weekly, currency) 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?

The description states a specific verb-and-resource: it quantifies rep hours and revenue lost to bad CRM data plus capacity a cleanup frees. An agent knows what the tool computes, but it is not differentiated from the very similar sibling crm_roi_calculator, which risks mis-selection in this crowded family.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as crm_roi_calculator or data_enrichment_value_predictor. The agent must infer the scenario entirely from the name.

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 disclose readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, covering the safety profile. The description adds no behavioral context beyond what annotations provide, but it does not contradict them either.

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 a single, front-loaded sentence followed by a URL. It is efficient and free of filler, though the external link is not directly useful for tool 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?

Given the simple calculator nature, fully documented parameters, and comprehensive annotations, the description is nearly complete. It does not explain the return format, but without an output schema this is a minor gap for a calculation 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?

The input schema has 100% description coverage for all six parameters, so the schema supplies full semantics. The description adds no additional parameter meaning, making the baseline of 3 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 action ('weigh') and resources ('CRM subscription and implementation cost against the win-rate lift it buys'), making the tool's purpose clear. It does not explicitly differentiate from siblings like crm_cleanup_roi_calculator, but the name and description are specific enough.

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 offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Usage is only implied by the tool's name and purpose.

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, and non-destructive, so safety is covered. The word 'starting' hints the output is a heuristic recommendation, but the description adds essentially no behavioral context and spends its second sentence on a promotional URL rather than useful detail.

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 first sentence is tight and front-loaded. The second sentence is a bare link to an external calculator page, which is promotional rather than functional and does not earn its place in a tool definition.

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 calculator with no output schema, the description conveys the core purpose but says nothing about the shape of the returned split (percentages vs. dollar amounts), currency assumptions, or how 'starting' recommendations should be interpreted.

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?

The description restates the two schema parameters (total budget, average contract value) without adding unit, currency, or format detail beyond the 100%-covered schema. Baseline 3 is appropriate since the schema already documents both inputs.

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 (suggest) and resource (Google/Meta/LinkedIn budget split) plus the two driving inputs. An agent can distinguish it from brand_vs_performance_budget_allocator or ad_spend_waste_calculator, though the description never names a sibling to sharpen that contrast.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many adjacent budget tools. An agent must infer the use case purely from the name and inputs.

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds no behavior beyond that — no note on whether this is a pure deterministic formula, what units the result is in, or any assumption/limitation. It is not contradictory, just 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, front-loaded with the computation and free of padding. The trailing marketing URL is arguably filler rather than functional content, which keeps it from a 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?

For a 4-param calculator with no output schema, the description covers what goes in and roughly what comes out, but never states the return shape or units of the ARR estimate. Adequate but with a visible gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the four parameters are fully documented in the schema; per the baseline rule a 3 applies. The description adds no extra parameter meaning (e.g. whether percentages are 0-100 or 0-1, or whether ACV is per-customer annualized).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and result ('Estimate the expansion ARR') and a precise scenario ('cross-selling a second product into your existing single-product customer base'), which is more specific than most sibling calculators. It stops short of explicitly distinguishing itself from near-neighbors such as expansion_revenue_impact_simulator or customer_expansion_revenue_matrix, so an agent must infer the split.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative. The scenario description implies a context, but an agent choosing among ~100 growth calculators gets no routing help.

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 declare this is a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is already covered. The description adds that the scoring uses a real WCAG contrast ratio, which is useful behavioral context, but says nothing about output shape, scoring scale, or limits. With annotations carrying the main burden, a 3 is appropriate.

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 first sentence is well front-loaded, but the second sentence is pure marketing ('See the full version at ...'), consuming roughly a third of the description without helping the agent decide whether or how to call the tool. Removing it would strictly improve the definition.

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 4-param computation with a fully documented schema and read-only annotations, the description is minimally sufficient. Without an output schema, one line about what the score represents (e.g., range, pass/fail thresholds) would materially help the agent interpret results, and that 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% with enum descriptions for size and placement and hex examples for the two color params, so the description doesn't need to restate them. It adds only that contrast ratio is computed from the hex colors, which is mildly informative but not beyond the schema. Baseline 3 is 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 (score) and resource (CTA button visibility), and enumerates the inputs it uses: WCAG contrast ratio, size, and placement. Clear enough to distinguish from most siblings, though it doesn't explicitly contrast with typography_legibility_grader or above_the_fold_messaging_clarity_grader despite their adjacency.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (evaluating a CTA button's visual prominence) but gives no explicit when-to-use vs. when-not-to-use guidance and no named alternatives. In a field of 100+ sibling tools, that leaves routing 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 readOnlyHint, idempotentHint, non-destructive and a closed world, so the safety profile is covered. The description adds one genuinely useful modeling assumption — growth is expansion-only, no new logos — but says nothing about return format, units, or how the three horizons are presented.

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 and efficient: the computation and its scope come first. The trailing link to a full web version is promotional rather than operational and does not help an agent invoke the tool, which keeps 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 two-parameter, read-only calculator with full annotation coverage and no output schema, the description conveys inputs and the shape of the result (1/2/3-year compounded projections). Only the exact return structure and unit conventions are unstated.

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 both parameters (arr, monthlyExpansionPct) are already documented. The description's gloss on net expansion (upsell + cross-sell minus contraction) is a modest addition consistent with the schema text, which is the baseline-3 case.

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 — compounding net expansion revenue forward 1, 2 and 3 years from current ARR — and even defines the metric (upsell + cross-sell minus contraction). It does not distinguish itself from nearby siblings like expansion_revenue_impact_simulator or net_revenue_retention_forecaster, so it falls 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?

No when-to-use guidance, no prerequisites, and no alternatives named. The horizon and the 'no new logos' constraint imply a pure expansion-projection scenario, but the agent must infer that this is the reason to pick it over other revenue models.

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, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds only the conceptual output ('capacity utilization and the hiring gap') and does not disclose calculation assumptions, edge cases, or output format.

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 first sentence is front-loaded and efficient, stating the purpose in one line. The second sentence is a promotional URL that does not help an agent select or invoke the tool, so the definition is not perfectly waste-free.

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 full schema descriptions and read-only annotations, the description supplies enough context to understand what is computed. It omits output format details, but with no output schema the conceptual output description is largely sufficient.

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 three parameters are fully documented in the schema. The description does not add any syntax, units, or constraints 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 comparison verb and resources ('CSM account load against a healthy book size') and names the outputs ('capacity utilization and the hiring gap'). It distinguishes itself from generic financial or growth calculators by focusing on CSM capacity.

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?

No explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The implied context is CS capacity planning, but the agent must infer that from the purpose alone.

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 destructiveHint=false, so the safe, deterministic nature of the operation is covered. The description adds no behavioral context beyond the calculation itself, e.g. return format or units, but for a pure calculator with full annotation coverage this is acceptable.

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 purpose is front-loaded in the first sentence with zero filler. The trailing external URL does not aid an agent in selecting or invoking the tool, so it is mildly wasteful rather than harmful.

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, fully-specified five-input calculator with no output schema and complete annotation coverage, the description conveys enough to invoke it. Only the absence of guidance on interpreting the resulting ROI figure keeps it short of a 5.

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 inputs (reps, leads/week, minutes/lead, hourly cost, tool cost) are documented in the schema. The description adds no syntax, units, or range meaning beyond that, 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 set of actions (compare manual research cost vs enrichment tool subscription, calculate net monthly savings and ROI) on a concrete resource. An agent can tell it computes an ROI/savings figure, though it does not explicitly disambiguate from other ROI calculators in the sibling list.

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?

No guidance on when to use this versus alternatives such as crm_cleanup_roi_calculator or other ROI tools. It mentions no inputs prerequisites or scenarios, leaving the agent to infer fit from the name alone.

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/openWorld=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the schema by naming the amortization method (straight-line), which is the key assumption an agent must know and is not present anywhere in the 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?

The first sentence is well-front-loaded and dense with signal. The second sentence is a promotional pointer to an external 'full version' that does not help an agent select or invoke the tool and arguably implies the exposed tool is incomplete.

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 three trivial numeric inputs, full schema coverage, and annotations handling the safety profile, the main remaining need is what the tool returns — and the description covers that (recognized-to-date vs. remaining liability) despite no output schema. Only the vague 'full version' link leaves residual ambiguity.

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 all three required numeric parameters documented, so the baseline is 3. The description restates the concept of an upfront payment and contract term but adds no units, ranges, or edge-case handling 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?

The description states a specific verb and resource ('Straight-line an upfront payment across the contract term') plus the exact output it produces ('revenue recognized to date versus the remaining deferred-revenue liability'). This is precise enough to distinguish it from neighbors like mrr_bridge_planner or net_revenue_retention_forecaster 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?

Usage is only implied by the domain ('deferred revenue', 'contract term') rather than stated. There is no explicit when-to-use, no prerequisites, and no reference to sibling calculators, so an agent must infer applicability from the purpose sentence alone.

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 the useful economic assumption behind the calculation, but says nothing about what the result contains (profit give-away figure, breakdown, units) or how discount/term inputs are compounded, which a pure-computation tool should disclose.

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 first sentence is dense and front-loaded, but the second is a promotional external URL that does not help the agent invoke the tool. Roughly half the description is non-actionable for a tool call.

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?

All required inputs are covered by the schema and the operation is read-only per annotations, but with no output schema the description should describe the returned figure (e.g., lifetime profit forgone). That gap leaves the agent unsure what the computation yields.

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 all four parameters (listAcv, discountPct, termYears, grossMarginPct) are documented in the schema. The description adds no syntax, unit, or range information beyond that, 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?

States a specific verb ('show how much lifetime profit... gives away') on a specific resource (enterprise contract discount), and adds a modeling assumption (cost-to-serve doesn't drop with price) that clarifies what is being measured. It does not explicitly distinguish itself from near-neighbors like gross_margin_impact_calculator or pricing_elasticity_sandbox, which keeps it out of 5 territory.

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 scenario (evaluating an enterprise discount offer) is implied by the framing, but there is no explicit when-to-use, when-not-to-use, or named alternative. With many overlapping pricing/margin siblings, the agent gets no routing guidance.

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 by structured data. The description adds only that the result is an 'estimate', which is consistent but not informative beyond the annotations.

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 first sentence is front-loaded and efficient, but the trailing 'See the full version at <URL>' is promotional filler that does not help an agent invoke the tool correctly, diluting the otherwise tight prose.

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 three-parameter, read-only estimator with no output schema, the description is minimally sufficient to convey the purpose and inputs. It stops short of describing the returned output (e.g. a recommended delay in seconds) and omits any usage context, leaving gaps an agent must infer.

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 three parameters are already documented. The description names the same three inputs but adds no format, range, or unit detail beyond what the schema provides; 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 verb ('Estimate') and resource ('best time to fire a timed exit-intent popup'), and lists the inputs that drive it. It is clearly distinguishable from most sibling calculators, though it does not explicitly contrast itself with adjacent timing/friction tools.

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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. With ~120 sibling marketing calculators, an agent gets no help deciding why this model applies versus e.g. cart_abandonment_calculator or page_speed_leak_calculator.

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, openWorldHint=false, so the agent knows this is a safe, deterministic, offline computation. The description adds some value by implying two outputs (expansion ARR and the equivalent new-logo CAC), but says nothing about return format or precision. With annotations covering the safety profile, a 3 is appropriate.

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 first sentence is well front-loaded and efficiently describes the calculation. The second sentence is a marketing URL that does not help an agent select or invoke the tool, so it does not fully earn 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 read-only deterministic calculator with four fully documented required parameters and clear annotations, the description is adequate. The gaps are the absent output description (no output schema) and no guidance on units/scale of the computed result, which leaves the agent slightly short of 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 (existingCustomers, adoptionRatePct, upsellAcv, newLogoCac) are already documented by the schema. The description adds only the framing of upsell ACV versus new-logo CAC comparison, which is marginal over the schema. 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: 'Estimate expansion ARR from an upsell offer and the new-logo CAC it would take to buy the same growth.' That is far more informative than a restated title. However, it does not distinguish itself from close siblings such as customer_expansion_revenue_matrix or ltv_growth_multiplier_simulator, all of which are expansion/growth models.

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?

There is no statement of when to use this tool versus any alternative, no prerequisites, and no mention of siblings. The only secondary sentence is a promotional link to a web calculator, which gives no invocation guidance.

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 safe, read-only, idempotent, non-destructive, closed-world calculation. The description adds the key behavioral idea that results depend on a per-field conversion recovery rate, but does not describe output form, limits, or other traits beyond the annotations.

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 first sentence front-loads the core purpose and is efficient. The second sentence is a promotional external link that is not strictly needed for tool invocation, keeping it from being maximally concise.

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 six-parameter calculator with full schema coverage and clear annotations, the description states what the tool returns: extra leads and pipeline value. It does not explain output format or units, but no output schema exists and the return concept is inferable.

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 six parameters are already documented in the input schema. The description mentions trimming form fields and recovery per field, which aligns with the schema, but adds no syntax, units, or parameter-level detail beyond what the schema 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: estimate extra leads and pipeline value unlocked by trimming form fields. It is clear enough for an agent to know the calculation, but it does not explicitly differentiate itself from similar friction or conversion calculators in the sibling list.

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?

Provides no when-to-use guidance, prerequisites, or alternatives. The implied context is form-field optimization, but there is no explicit routing to or away from related tools such as friction_point_identifier or mobile_checkout_friction_tester.

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 behavior. The description adds the modeling scope—monthly/annual new ARR and lagging pipeline ARR—but does not disclose assumptions, formula behavior, limitations, or return format.

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 sentence is front-loaded and concise, covering the main modeling purpose. However, the second sentence is an external promotional link that does not help tool selection or invocation, so it does not fully earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should convey return values. It names the modeled outputs conceptually but does not specify their format, units, or assumptions, leaving output behavior somewhat underspecified.

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 all four required parameters have clear descriptions in the schema. The description adds no units, constraints, or format details beyond what the schema already provides, so the baseline of 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 the specific verb 'Model' and the resource/output well: monthly and annual new ARR from a freemium funnel, plus ARR lagging in the upgrade pipeline. This distinguishes it from generic ARR/MRR calculators, though it does not explicitly name a sibling alternative.

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?

There is no explicit when-to-use or when-not-to-use guidance. The freemium funnel framing implies the context, but it does not tell the agent how to choose this over related calculators such as mrr_to_arr_calculator or product_led_growth_feasibility_grader.

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 destructiveHint=false, so the safety profile is covered. The description adds that the input is a fixed set of 8 boolean friction flags and that the output is a derived 'flow health score', but it never discloses the score's scale, how many points map to which band, or anything about the return 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?

The first sentence is tight and front-loaded with the verb and resource. The second sentence is purely a promotional link to an external calculator, which does not help an agent decide or invoke the tool and is dead weight under a conciseness standard.

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 8-required-boolean, read-only scoring tool with no output schema, the description covers the input contract adequately. However, with no output schema and no statement of the score's range or interpretation, the agent cannot describe the result to a user, leaving a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of the 8 booleans individually documented (e.g. 'No progress indicator on multi-step flows'), so the schema does the heavy lifting. The description's '8 common conversion-flow friction points' confirms the count but adds no semantics beyond what the schema already states.

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: count 8 conversion-flow friction points and convert them into a flow health score. This is clear and concrete, but it never distinguishes itself from nearby siblings such as mobile_checkout_friction_tester, form_field_friction_cost_calculator, or ae_sdr_hand_off_friction_calculator.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives. The agent must infer from the phrase 'conversion-flow friction points' that this is a checkout/signup flow audit rather than an SDR hand-off or form-field audit, which is genuinely ambiguous among the friction-oriented siblings.

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, covering the safety and side-effect profile. The description adds only the computational outcome (missed clicks, conversions, revenue), which is more purpose than behavioral detail, and it does not discuss rate limits, auth, or response behavior. With annotations doing the heavy lifting, a 3 is appropriate.

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 two short sentences and front-loads the core function. The second sentence is a pointer to an external full version; while not strictly necessary for tool invocation, it is concise and does not obscure the primary 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?

The tool is a simple four-parameter calculator with no nested objects or output schema. The description clearly states what is estimated, which is sufficient for an agent to know what to expect as output. Annotations cover the safety profile, so nothing critical is missing for correct invocation.

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 fully documented in the schema with clear descriptions (e.g., 'Current clicks per month'). The description does not add any parameter-level semantics beyond what the schema provides, so the baseline of 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 states a specific verb ('Estimate') and resource ('missed clicks, conversions, and revenue from operating below 100% search impression share'), making the tool's core function clear. It does not, however, distinguish this tool from similar siblings like impression_share_opportunity_matrix or ppc_click_volume_predictor, so an agent must infer the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying the condition 'operating below 100% search impression share,' which tells the agent when the calculation is relevant. But it offers no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites.

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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive and a closed-world scope, so the safety profile is fully covered. The description adds no behavioral context beyond restating the inputs (no return format, no note that it is a pure deterministic calculation), so it contributes little beyond structured data.

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 first sentence is tight and front-loaded, but the second is a link to a separate 'full version' that is irrelevant to invoking the tool and dilutes the definition. One sentence earns its place, one does not.

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 deterministic calculator with full annotations and full schema coverage, the description names both the outputs and the required inputs, which is sufficient to call it correctly. It is complete even though there is no output schema, since the computed quantities are named.

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 documents all three required parameters. The description merely echoes them (revenue, infrastructure cost, support/delivery cost) without adding units, currency, or period 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?

States a specific verb (Calculate) and the outputs (gross profit and gross margin) plus the three inputs, so the purpose is unambiguous. It does not, however, distinguish itself from the mass of sibling financial calculators (e.g. performance_marketing_margin_protector, ltv_cac_calculator) by naming a scenario or alternative.

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?

There is no when-to-use guidance, no indication of when this beats a sibling margin/ROI calculator, and no prerequisites. The only extra sentence is a promotional link to a hosted version, which does not help an agent decide whether or how to call the 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 this a safe, idempotent, read-only, closed-world computation, so the safety profile is fully covered. The description adds that it is a 'how much would a cut buy you' simulation, but says nothing about output form (e.g., months of runway, delta) or how the increase is computed.

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 first sentence is front-loaded and efficient. The second sentence is purely a promotional link to an external site, which adds no selection or invocation value for an agent and does not earn 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 low-complexity, fully-specified four-parameter calculator with no output schema, the description conveys the input concept and the general output idea but not the return shape or units. It is adequate but leaves the agent guessing what the result actually represents.

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 (including burnReductionPct) are already documented in the schema. The description maps loosely to cash/burn/revenue but adds no units, ranges, or interpretation beyond what the schema provides, making the baseline 3 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 names a specific computation (how much extra cash runway a gross-burn cut buys) and the inputs it reacts to, so the agent knows the tool's function. It does not, however, distinguish itself from the closely-related burn_rate_optimization_forecaster or rule_of_40_sandbox siblings.

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 implies the scenario in which the tool applies (when you have current cash, burn, and revenue and want to model a burn cut), but offers no explicit when-to-use guidance, no exclusions, and no named alternatives among the many financial calculators.

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 non-destructive, so the safety profile is covered. The description adds the computation detail that the three scores are averaged, which is useful, but it says nothing about the ranking output order, ties, or what is returned.

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 first sentence is efficient and front-loaded, but the second sentence is purely promotional ('See the full version at https://...') and contributes nothing an agent needs to call the tool, so it does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description only implies a ranked result and never describes the return shape (ordered list, score values). For a self-contained scoring tool with strong annotations this is adequate but leaves the output under-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 description coverage is 100% and each field (name, impact, confidence, ease) is documented with its 1-10 range. The description adds only the 'averaged' aggregation rule 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?

States a specific verb (Rank) and resource (growth ideas) plus the exact scoring mechanism (ICE = Impact, Confidence, Ease averaged, each 1-10). No sibling tool does ICE prioritization of growth ideas, so an agent can route here 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?

'to decide what to run next' implies the decision context, but there is no explicit when-to-use vs alternatives guidance and no named sibling to contrast with. Usage is only implied, not stated.

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 and determinism profile is fully covered. The description adds useful context about the recommendation's output range (founder-led to full leadership team across ARR bands), but says nothing about return shape (ordered roles? rationale?) beyond that.

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 purpose in one sentence, with the ARR range qualifier immediately following. The trailing external link is promotional rather than operational, a minor waste, but the whole description remains two tight 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?

For a single-input, read-only, closed-world calculator with no output schema, the description conveys enough: what it recommends, the input dimension (ARR), and the span of outcomes. It could be fuller on the form of the returned sequence, but nothing blocks correct invocation.

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% for the single 'arr' parameter, so the schema already carries the definition. The description adds only marginal framing by tying the input to ARR bands, which is baseline-level value 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 and resource ('Recommend the right growth/marketing hiring sequence') and bounds the scope by ARR band with concrete anchors (pre-$1M founder-led through $10M+ leadership team). It is clearly distinct from neighboring planners like sdr_capacity_and_inbound_quota_planner, though it never names a sibling to route against.

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 ARR-band framing implies when the tool applies ('for your ARR band'), but there is no explicit when-to-use guidance, no prerequisites, and no statement of when to choose this over adjacent planning tools such as the SDR capacity planner or in_house_vs_fractional_cmo.

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 non-destructive behavior, so the safety profile is covered. The description adds only that scoring spans eight weighted dimensions, which the schema already enumerates, and discloses nothing further about how the score is computed or surfaced.

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. The trailing promotional URL ("See the full version at...") doesn't aid tool selection but is brief enough not to seriously harm the structure.

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 explain what the score result looks like (numeric score, dimension breakdown, etc.), and it doesn't. Inputs are fully documented, so the gap is the return-value expectation for a scoring 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 coverage is 100% with each of the eight enum parameters documented, including weights, so the schema does the heavy lifting. The description adds no parameter meaning beyond what the schema provides, which is the correct baseline at full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Score") and resource ("Google Tag Manager container health") and clarifies the scope as "eight weighted dimensions covering tag hygiene, consent, and reconciliation." An agent can tell what it does, though it doesn't explicitly differentiate itself from sibling audit tools like tech_stack_duplication_inspector.

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 offers no when-to-use guidance, no prerequisites, and no alternatives to compare against. It explains what the tool does but not when an agent should reach for it versus another auditing 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the calculation basis (annual B2B decay rate), but does not disclose return format, precision, or other behavioral details beyond that.

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 in the first sentence. The second sentence is an external link that does not help an agent invoke the tool, but it is brief and does not obscure the main point.

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 full schema coverage and no output schema, the description adequately explains what is being estimated. It could be improved by clarifying the output form (percentage vs. count), but it is complete enough to select and 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%, so all three parameters are already documented in the schema. The description mentions the same concepts at a high level and does not add syntax or format details beyond what the schema 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?

The description gives a specific verb (estimate), resource (contact database staleness), and method (annual B2B data decay rate). It is clear what the tool computes, though it does not explicitly differentiate itself from sibling calculators such as crm_cleanup_roi_calculator or data_enrichment_value_predictor.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the purpose statement.

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 destructiveHint=false, so the safety profile is covered structured-side. The description adds the framing that this is a counterfactual opportunity estimate against a 100% impression share baseline, which is useful context, but it says nothing about input assumptions, precision, or failure modes. Adequate but not 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?

The first sentence is well front-loaded and wastes nothing. The second sentence is a promotional link to an external site that does not earn its place in a tool definition, marginally diluting the otherwise efficient structure.

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 three-parameter, no-output-schema calculator, the description adequately conveys the purpose, the input conditions, and the nature of the result (missed conversions and revenue). It is complete enough to invoke, with only the sibling-routing gap remaining.

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 three simple, self-explanatory numeric parameters (conversions, impressionSharePct, valuePerConversion), so the schema carries the load and the baseline of 3 applies. The description adds no units, ranges, or baseline assumptions beyond what the schema already says.

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 outcome ('Estimate missed conversions and revenue') tied to a specific resource and condition ('operating below 100% impression share on a search campaign'). However, it offers no differentiation from the near-identical sibling google_search_impression_share_value_estimator, so an agent cannot route between the two from this text alone.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of an alternative. The second sentence only points to a web version of the calculator, which does not help an agent decide whether to call this tool versus the sibling impression-share estimator.

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 nothing beyond purpose — no indication of what the estimate returns, whether it is deterministic, or any computation caveats — so it contributes no behavioral context of its own.

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 purpose is front-loaded in a single effective sentence, but the second sentence is a promotional link to an external site that consumes space without helping the agent invoke 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?

For a simple four-input calculator with no output schema, the purpose sentence implies the returned quantities (customers and ARR at risk). Combined with full schema coverage and a clear read-only annotation set, an agent has enough to call it correctly, though return format and units remain unstated.

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 all four inputs clearly documented (activeCustomers, slowSupportSharePct, excessChurnPct, annualRevenuePerCustomer). The description adds no extra parameter meaning, 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 ('Estimate') and a concrete resource ('customers and ARR put at risk each year by slow support routing and SLA breaches'), so an agent knows exactly what the tool computes. It fails to distinguish itself from the near-identical sibling 'lead_routing_delay_cost_calculator', which covers closely overlapping routing-delay cost territory.

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 no when-to-use guidance, no prerequisites, and no mention of the closely related routing/delay sibling tools. The agent must infer usage purely from the name and purpose sentence.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds that the comparison explicitly includes ramp-up cost before impact, which is useful scope context, but says nothing about output or assumptions.

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 purpose is front-loaded in the first sentence; the second sentence is a short pointer to the full calculator. Efficient overall, though the external link is closer to promotion than task-enabling 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 calculator with no output schema, the description should ideally state what it returns (e.g., the two cost figures or a break-even point). It implies a cost comparison but leaves the actual outputs unspecified, and there is no annotation beyond read-safety to fill the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with all five required parameters individually documented (salary, loadedPct, rampMonths, recruiting, fractionalMonthly). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compare) and resource (loaded annual cost of a full-time CMO vs a fractional CMO retainer) with a clear scope that includes ramp-up cost. Against the large sibling list of calculators, the topic is distinctly identifiable 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 description gives no when-to-use or when-not-to-use guidance, and names no alternative tool for related budgeting decisions. The only extra sentence points to an external 'full version', which is a link, not usage direction.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only that the output is a prioritize/plan/deprioritize verdict; it says nothing about scoring mechanics, tie-breaking, or the score shape despite there being 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 functional sentence is front-loaded and dense, but the trailing promotional URL ('See the full version at https://...') does not help an agent decide or invoke anything and dilutes the definition.

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 five required enum parameters fully documented in the schema, the main remaining burden is the missing output schema, and the description at least communicates the verdict categories the score maps to. That covers most of what an agent needs, though the numeric score range and any thresholds remain unspecified.

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 carries an enum plus an explicit weight (30/20/20/15/15), so the schema does the heavy lifting. The description lists the same five dimensions but adds no interpretation beyond the schema, which is the baseline case.

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 clear verb ('Score') and resource ('a candidate international market') and enumerates the five scoring dimensions, so the agent knows exactly what the tool computes. It does not differentiate itself from near-neighbors like growth_strategy_prioritization_tool or total_addressable_market_estimator, which keeps it 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?

The phrase 'to decide whether to prioritize, plan, or deprioritize it' implies the decision context in which the tool is useful, which is better than nothing. However, there is no explicit when-to-use vs. when-not guidance and no named alternative for adjacent market/strategy scoring tasks.

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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that scoring uses 'five weighted criteria,' but does not disclose the output format, scoring range, or any other behavior beyond what the annotations and schema already provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is front-loaded and efficient, clearly stating the tool's purpose. The second sentence is a link to an external full version, which is concise but not directly useful for tool 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 simple input-only calculator with five required enums, no nested objects, and no output schema, the description is adequate for invocation but omits the return value shape or scoring scale. An agent can supply inputs, but cannot anticipate what the tool will return.

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 all five parameters are enum-described with their weights. The description names the same five criteria but adds no syntax, format, or nuance beyond what the schema already documents, so this meets the baseline.

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 precise verb ('Score'), a specific resource ('message-match continuity between an ad and its landing page'), and the exact dimensions being assessed. It distinguishes this tool from other graders and auditors by focusing narrowly on ad-to-page continuity.

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 offers no guidance on when to use this tool versus the many sibling scoring and auditing tools. Usage is only implied by the purpose statement, and no prerequisites, exclusions, or alternative tools are named.

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 and determinism profile is fully covered without description help. The description adds only the shape of the result (an A–F letter grade) and the distinction from behavioral scoring; it says nothing about weighting behavior, thresholds, or how partial answers affect the grade—context the schema's weight values only partially 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?

Two short sentences with the functional definition front-loaded and no padding. The trailing URL is a mild promotional element rather than agent-relevant instruction, which keeps it from a 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?

For a deterministic, single-output calculator with no output schema, the description supplies the essential contract: firmographic inputs in, A–F grade out. With 100% schema coverage on all five enum parameters and full annotation coverage, the remaining gap (how the weighted criteria combine into the grade) is minor.

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 every parameter carries an enum plus its weight (25/20/20/20/15), so the schema already does the heavy lifting. The description adds no additional parameter meaning (e.g., what "partial" means for a given criterion), 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 transformation (firmographic fit criteria → A–F lead grade) rather than restating the name, so the agent knows exactly what the tool computes. It also carves out a conceptual boundary against "behavioral lead scoring," which helps distinguish it from scoring-adjacent siblings like lead_scoring_logic_architect. It stops short of naming any sibling tool by name, so it lands at 4 rather than 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 clause "distinct from behavioral lead scoring" implies when this tool is the right choice (static firmographic fit, not engagement-based scoring), which is a useful routing hint. However, it gives no explicit when-to-use/when-not-to-use guidance and does not name alternatives such as lead_quality_intent_evaluator or mql_calculator, so the agent must infer selection.

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, closed-world operation, so the safety profile is covered. The description adds that scoring uses five weighted criteria producing a 0-100 score, but does not say whether the result includes per-criterion breakdown, pass/fail thresholds, or recommendations.

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 action and output range. The second sentence is an external marketing link that adds no invocation value, but the overall text stays short with no padding.

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 all five inputs fully documented in the schema and the return value characterized as a 0-100 score, an agent has what it needs to call the tool. No output schema exists, so the description carries the return-shape burden and does so only at a high level (no breakdown detail).

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 of the five enum parameters already documents its own meaning, accepted values, and weight. The phrase 'five weighted criteria' in the description merely restates what the schema already conveys, 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 a specific verb and resource ('Score a lead magnet's perceived opt-in value') and states the output form ('0-100 score'), which is enough to identify the tool. It does not, however, differentiate itself from adjacent sibling graders such as value_prop_strength_grader or gtm_audit_scorecard.

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?

There is no guidance on when to use this tool versus the many other scoring graders in the family, and no prerequisites or input-preparation notes. The only implied usage is that the caller already has a lead magnet to evaluate.

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 and openWorld=false, so the safety profile is covered. The description adds the computational method (segmenting by email domain and weighting close rates), which is useful, but says nothing about the shape or interpretation of the resulting 'quality score'.

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 first sentence is front-loaded and dense with the actual computation. The second sentence is a promotional link to an external calculator, which does not help the agent invoke the tool and is dead weight, but the core remains tight.

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 clarify what is returned (a score, segment breakdown, benchmark?) but only says 'score overall lead quality'. For a computational tool with four required inputs, that leaves the agent guessing about the result's form and scale.

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 (signups, corporate email share, corporate and personal close rates) are documented in the schema. The description mirrors the corporate/personal split but adds no units, ranges, or format detail beyond what the schema already provides — 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 specific actions: split signups into corporate vs personal email intent segments, apply differentiated close rates, and score lead quality. This distinguishes it somewhat from siblings like lead_grading_calculator or lead_scoring_logic_architect, though it does not explicitly name how it differs from 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?

No when-to-use guidance, prerequisites, or named alternatives are given. The agent must infer from the name and description alone that this is the right pick over the many other lead-scoring tools in the sibling list.

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 adds real behavioral context beyond them: it discloses the underlying model (conversion decays as response delay grows) and that the output is a per-month lost-deal/revenue estimate. It omits any statement of output units or sensitivity, 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?

The first sentence is front-loaded and efficient. The second sentence is a promotional link to an external site and contributes nothing to selection or invocation, which costs it a point despite the overall brevity.

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 stateless five-input calculator with fully documented parameters and a boolean-safe annotation set, this is close to sufficient. However, there is no output schema and the description doesn't say what the result contains (single lost-revenue figure, breakdown of lost deals vs. revenue, monthly vs. annual) or how the decay curve is specified, leaving the agent guessing at 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 coverage is 100% and every parameter has its own description (units, percentages), so the schema carries the semantic load. The description adds no parameter-level detail — no mention of what currentResponseMinutes vs targetResponseMinutes does to the model, or that conversionAtTargetPct is the anchor rate. 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 states a specific verb and resource: estimate deals and revenue lost per month from slow lead response, with the modeling premise (conversion decays with delay). That is clearly distinct from siblings like form_field_friction_cost_calculator or inbound_call_center_routing_auditor. It stops short of naming an alternative tool, so it lands at 4.

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 purpose ('slow lead response times' implies the user has current and target response times and wants a cost estimate), but there is no explicit when-to-use/when-not, no prerequisites, and no pointer to a sibling tool that handles an adjacent question. This is minimum-viable guidance.

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 destructiveHint=false, so the safe, repeatable read profile is covered. The description adds genuine behavioral value by disclosing the three-way routing outcome, but it does not describe the returned score, weighting math, or any rate/auth constraints. Adequate, not 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 sentences with the purpose and outcome front-loaded and no padding. The trailing external link is mildly promotional but takes only a clause.

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 it only partially does so — it names the routing categories but not the numeric score or how weighted inputs aggregate. All six required params are fully self-documented, so an agent can call it, but the response shape remains underspecified.

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% — every parameter carries an enum plus an explicit weight (e.g. highIntentAction weight 25, pricingPageVisit weight 20). The description adds nothing beyond that, so the schema already does the heavy lifting and 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 states a specific verb (score) and resource (a lead) plus the distinctive output — a routing recommendation toward sales, nurture, or disqualify. That is far more informative than a name restatement, though it never names or distinguishes itself from close siblings like lead_grading_calculator or lead_quality_intent_evaluator.

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?

There is no explicit when-to-use guidance, no prerequisites, and no routing to or away from the many sibling lead-scoring tools. Usage is only inferable from the purpose statement.

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 destructiveHint=false, so the safety profile is covered. The description adds the calculation logic (implied CAC vs. fundable max CAC) but says nothing about the returned values or units, which matters given there is 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?

Two sentences with the core computation front-loaded and no padding. The trailing external link is slightly promotional but does not obscure the purpose.

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 clarify what the tool returns; it only loosely implies an implied-CAC figure and a threshold comparison. For a deterministic five-parameter calculator this is adequate but leaves the return shape underspecified.

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 (including grossMarginPct) are already documented in the schema. The description names four of the inputs in prose and implies grossMarginPct via 'maximum CAC a contract can fund,' but adds no syntax or unit detail beyond the schema. 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+resource: it computes implied CAC from LinkedIn CPC, landing conversion, and close rate, then compares it to the maximum CAC a contract can fund. The LinkedIn channel focus distinguishes it from generic siblings like cpl_cpa_calculator or ltv_cac_calculator, though it never explicitly names those 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?

The description gives no when-to-use guidance, no prerequisites, and no exclusions relative to the many adjacent CAC/CPC calculators in the sibling list. The only 'guidance' is a pointer to an external full version, which is promotional rather than operational.

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