upGrowth Growth Toolkit

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the analytical scope (derived metrics from margin and total sales) but does not disclose output form (percent vs ratio), rounding, or behavior when optional inputs like total_sales or gross_margin_pct are omitted — relevant for a calculator with 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?

A single front-loaded sentence with no filler; every clause names a concrete output. It is efficient, though the density means nothing is expanded where clarity would help.

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

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

For a five-parameter calculator with no output schema, the description should at least indicate the shape of the result (e.g., each metric returned as a percentage) and how missing optional inputs affect output. It lists metrics but leaves the return contract and input-dependency behavior implicit.

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

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

Schema coverage is 60%, with the optional fields (total_sales for TACoS, gross_margin_pct before ad costs, currency default INR) already documented in the schema itself. The description only reinforces which inputs drive which metrics and adds no unit, format, or validation detail beyond that — 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 (Calculates) and a precise set of resources (ACoS, ROAS, break-even ACoS, profit after ads, TACoS), so an agent knows exactly what comes out. It never distinguishes itself from siblings like roas_check or break_even, which overlap on ROAS and break-even logic, so an agent cannot confidently choose between them 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?

No when-to-use or when-not-to-use guidance is present, and no alternatives are named despite roas_check and break_even covering adjacent ground. The agent must infer that this is the right tool whenever Amazon ACoS comes up.

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 safety is covered. The description adds the useful detail that the estimate is derived by chaining click cost through two conversion rates, i.e. a pure projection with no side effects, but says nothing about rounding, currency handling, or what the returned figure includes.

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

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

A single front-loaded sentence with no filler; the purpose and the input drivers arrive immediately. It is efficient, though the trailing enumeration of inputs partially duplicates what the schema already says.

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

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

For a five-parameter calculator with full schema coverage and no output schema, the description covers the purpose but not the return shape – an agent does not know whether it gets a single budget number, a breakdown by funnel stage, or implied clicks and leads. That is the main remaining gap.

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

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

Schema description coverage is 100%, so every parameter including the optional currency default is already documented in the schema. The description restates the same three inputs in prose without adding notation, units, or edge-case guidance (e.g. what happens with very low conversion percentages), so it sits at 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?

States a specific verb and resource ("Estimates the monthly ad budget") plus the exact target (new customers) and the three drivers of the calculation. An agent can distinguish it from calculators like campaign_roi or max_affordable_cac, though it never names a sibling to draw the line 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?

Usage is only implied by the described inputs (CPC, conversion rates, target customers) – an agent can infer 'use when planning paid acquisition budget against a customer goal'. There is no explicit when-not-to-use or pointer to alternatives such as ppc_forecast or max_affordable_cac, which occupy adjacent territory.

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, openWorld and non-destructive, so the safety profile is covered. The description adds the useful detail that results are categorised as allowed/restricted/blocked and names the specific bots checked, but says nothing about failure modes such as a missing robots.txt, timeouts, or whether results are cached.

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 sentence, front-loaded with the action and the data sources, with the crawler list kept compact in parentheses. Nothing is wasted, though the parenthetical enumeration leans slightly long for a single-parameter tool.

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

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

With no output schema, the description helpfully supplies the result vocabulary (allowed/restricted/blocked) and the bot identities, which is what an agent needs to interpret output. It stops short of covering edge cases like absent files or non-crawlable domains, leaving a small gap for an openWorld 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 single parameter has 100% schema description coverage ('Public domain to check, for example example.com'), so the schema carries the burden and baseline 3 applies. The description adds only marginal context by framing the input as a website whose robots.txt/llms.txt is fetched.

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 (reads) and resources (robots.txt, llms.txt) plus what it produces (allowed/restricted/blocked status per crawler). This clearly separates it from the sibling robots_txt_generator, which writes rather than inspects.

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: the agent can infer you call it to audit crawler access for a domain. There is no explicit when-to-use/when-not statement, no mention of prerequisites (e.g., that the domain must be publicly reachable), and no named alternative.

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 bar is lower. The description adds the meaningful detail that the result is a 'simple annualised rate' derived from start/end headcount, but it does not state the exact formula, which headcount figure is the denominator, or how period_months drives annualisation.

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

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

A single tightly packed sentence with the core operation front-loaded and zero filler. Nothing in it is redundant or 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?

With no output schema, the description should say more about what is returned (percentage? two figures, raw and annualised?) and the formula basis. It covers inputs reasonably but leaves the agent guessing at the return value and the role of period_months.

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 only 25% (only 'separations' is documented), so the description must compensate. It does convey that headcount is taken at start and end and that the result is scoped to a period, but it never explains period_months, its 1–12 bounds, or the 1-month default that governs the annualisation.

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 ('Calculates') plus a precise resource ('employee attrition or customer churn rate') and names the inputs it consumes. It is clearly distinguishable from siblings like growth_rate or period_change, though it does not call out any 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?

Usage is only implied by the input requirements (separations plus start/end headcount); there is no statement of when to prefer this over growth_rate or period_change, and no prerequisites or exclusions. Adequate but 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 readOnly/idempotent/non-destructive, and the description adds the key behavioral nuance beyond them: this does not book anything, it only returns a link, and the offer is free and 30 minutes. It stops short of saying whether the link is personalized or reusable, which is a minor residual gap given annotations cover the safety profile.

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

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

Two sentences, zero filler, with the return value front-loaded and the usage constraint second. Nothing repeats the title or annotations.

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 zero-param, non-destructive read tool with no output schema, the description covers what is returned (a link) and the size/duration of the call. Only marginal details — link validity, whether it is per-user — are absent, which is acceptable at this 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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. It correctly implies a parameterless call.

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

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

States a specific verb and resource (returns the booking link for an upGrowth strategy call) with the concrete qualifiers 'free' and '30-minute'. Since every sibling is a growth/metric calculator, this is instantly distinguishable as the only action/link-returning tool.

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

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

'Use only when the user asks to speak with upGrowth' is an explicit trigger and an explicit exclusion in one clause — the agent knows both when to call it and when not to. No plausible alternative tool competes for this intent, so no alternative routing is needed.

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 that it also returns revenue and target-profit units, but omits formatting behaviour (currency display) and the edge case where variable_cost_per_unit ≥ price_per_unit makes break-even undefined — relevant since the schema only constrains price to be > 0.

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

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

A single front-loaded sentence with no filler; the dense list of inputs and outputs is appropriate for a calculator. Slightly harder to scan than a short two-sentence split between inputs and outputs, but nothing is wasted.

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

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

With no output schema, the description bears the burden of describing return values; it names three outputs but not their shape (flat object? per-currency strings? rounded?), and gives no guidance on invalid input combinations. Adequate but with clear gaps for a 5-parameter financial 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 40%, so the description must compensate: it names fixed costs, price, variable cost per unit and target profit, and clarifies that contribution margin is a derived output rather than an input. That is useful, but it doesn't state units (per-period? absolute?), how currency affects results, or that target_profit is optional.

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 ('Calculates') plus the exact outputs (break-even units and revenue, units for target profit) and the inputs driving them. 'Break-even' is self-distinguishing from siblings like unit_economics or max_affordable_cac, though the description never names an alternative 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 / when-not-use guidance and no mention of how this differs from adjacent finance tools such as unit_economics or growth_projection. Usage is only inferable from the tool's 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate that safety profile. It adds only the domain scope of revenue and gross-profit ROI, without explaining formula behavior, edge cases, or return behavior. There is no contradiction with 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 definition is a single, front-loaded sentence with no filler. It states the calculation and the relevant scope immediately.

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 annotations and high schema coverage carry most of the necessary context, but with no output schema the description should say more about what ROI values are returned. It also omits formula details and does not describe the one schema parameter lacking a description, attributed_revenue, beyond the word 'revenue'.

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 80%, which sets the baseline at 3. The description's phrase 'on revenue and on gross profit' loosely maps to attributed_revenue and gross_margin_pct, but it adds no syntax, defaults, or constraints beyond what the schema already documents.

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 uses a specific verb, 'Calculates ROI,' and a specific resource, 'marketing campaign or channel.' It also scopes the calculation to revenue and gross profit and names example channel types, making the purpose clear. It does not explicitly differentiate itself from nearby siblings such as roas_check or seo_roi.

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 by listing campaign/channel contexts and two ROI bases, but it gives no explicit when-to-use guidance. It also does not mention exclusions or direct the agent to alternatives like roas_check or seo_roi.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds that it 'counts exactly, which assistants often get wrong' — a useful reliability claim — but discloses no return format, character-limit behavior, or how missing keywords are handled. With annotations carrying safety, this is 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?

Two tightly-packed sentences: first enumerates the metrics front-loaded, second makes a single credibility point. No filler, no repetition of the title.

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

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

For a read-only analysis tool with full schema coverage and no output schema, the description is nearly complete — it lists all outputs an agent would need. Minor gap: it doesn't state that secondary_keywords are optional or that missing keyword just omits that section, though the schema implies optionality.

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

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

Schema coverage is 100%, so the schema does the heavy lifting and baseline would be 3. The description adds meaning beyond the schema by explaining what 'keyword' placement and density are computed against and implying secondary_keywords are counted alongside the focus keyword. Slight credit above baseline for clarifying the focus-keyword concept.

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 the exact resource (pasted text) and enumerates the specific metrics produced: word/sentence/paragraph counts, reading time, Flesch ease, long sentences/paragraphs, headings, and focus keyword count/density/placement. It's clearly distinguishable from sibling tools like meta_tags_builder or seo_roi, which do different SEO work.

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 makes usage implied by stating 'Analyses text the user pastes' — this signals it's for user-supplied content rather than URLs. However, there's no explicit when-to-use vs. alternative guidance, such as distinguishing it from acos_check or other content-related checks, and no stated exclusions.

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 and the bar for the description is lower. The description usefully adds that the calculation is configurable (optional discounting, LTV-to-CAC ratio), but says nothing about precision, currency conversion behavior, or what the returned figure represents. 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?

A single well-packed sentence with the verb and domain front-loaded and the optional features trailing. No filler and nothing redundant with the schema. It is dense enough that a reader must parse carefully, but every clause carries information.

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

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

With no output schema and seven parameters, the description should say more about what comes back — the LTV figure, whether the LTV:CAC ratio is returned, currency handling, and the discounting convention. It signals these capabilities exist but leaves the agent guessing about the result shape. Adequate for invoking the tool, incomplete for interpreting it.

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

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

Schema description coverage is only 43%, so the description carries real weight here, and it does: it names average order value, purchases per year, lifespan, margin, optional discounting and the LTV-to-CAC ratio, which accounts for six of the seven parameters conceptually. Only 'currency' (a display-only, defaulted field) is left unaddressed, and no units or formula for the discount rate are given.

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

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

The description opens with a specific verb and resource ('Calculates customer lifetime value') and narrows the domain to repeat-purchase businesses such as D2C and ecommerce. It enumerates the input drivers (AOV, purchase frequency, lifespan, margin) plus optional extensions, so the tool's function is unambiguous. It does not explicitly contrast itself with adjacent siblings like unit_economics, max_affordable_cac or ecommerce_metrics, so it stops short of full differentiation.

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?

Applicability is implied by 'for repeat-purchase businesses such as D2C and ecommerce', which tells the agent the model assumes recurring purchases rather than one-off or subscription contexts. However, there is no explicit when-to-use statement, no exclusion (e.g. 'not for SaaS/subscription churn models'), and no named alternative such as max_affordable_cac for pure CAC work. Usage must be inferred.

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. The description adds that it performs calculations and can derive sessions needed for a revenue target, but it does not explain how optional inputs affect the result or what happens when sessions/customers are omitted.

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 that enumerates the metrics without filler. Every phrase contributes to identifying the calculation outputs.

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?

This is a calculation tool with six parameters, no output schema, and only partial parameter documentation in the description. It names the metrics but does not explain return shape, edge cases, or how optional parameters change the available outputs, leaving meaningful gaps for an agent to 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 moderate at 67%, with currency, sessions, customers, and target_revenue documented while revenue and orders rely on their names and required status. The description adds some meaning by mentioning the sessions-to-target calculation, but it does not map parameters to specific metrics or clarify the effect of optional 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?

The description states a specific verb (calculates) and enumerates concrete ecommerce metrics, so the tool's purpose is clear. It does not explicitly distinguish itself from related siblings such as unit_economics or break_even, which prevents 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 description provides no guidance on when to use this tool, when not to use it, or which sibling tool to choose instead. It only lists what is calculated, leaving usage context entirely 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 covered. The description adds that it works across platforms and accepts either engagement counts or base metrics, but it never says whether the result is a percentage or ratio, how missing metrics are treated, or what the `posts` parameter does to the calculation.

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

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

A single front-loaded sentence with no filler; the platform list and metric/base lists each carry information. It is efficient, though the two parallel enumerations pack a lot into one clause and could be split for scannability.

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-parameter calculator with no output schema and read-only annotations, an agent has enough to make a correct call on the main path (supply counts plus base_value and base_type). What's missing is the `posts` parameter's role and the output unit, which for a metric calculator is a meaningful gap.

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

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

Schema description coverage is only 43%, and the bare schema leaves likes, comments, shares and saves entirely undocumented. The description compensates partially by naming those four metrics and the four base types, which is real added meaning over the enum alone. However, it never explains the aggregation rule (sum vs. average), omits the `posts` parameter that the schema describes as 'number of posts the totals cover', and gives no unit guidance for the output.

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 (calculates) and resource (engagement rate) plus the platforms and input metrics it covers, so the tool is immediately identifiable. It does not explicitly distinguish itself from numerically adjacent siblings like growth_rate or roas_check, but the noun 'engagement rate' is distinct enough that an agent won't confuse 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?

Usage is only implied: an agent infers you call this when you have raw like/comment/share/save counts and a follower/reach/impression/view denominator. There is no explicit when-to-use statement, no prerequisites, and no named alternative for related needs.

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 covered. The description adds genuinely useful behavioral context the annotations do not: the specific data source (upGrowth Growth Moves research), the coverage window (January–September 2026), and the per-record payload (leader, date, source link). It does not say what happens when no matches are found or whether the Sep 2026 cutoff is a hard dataset limit.

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 resource and scope, then the filter dimensions, then the return contents. No filler and no restated annotations.

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

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

With no output schema, the description usefully compensates by listing the fields each move contains. Minor gaps remain: behavior on zero results, whether limit=14 is the entire dataset cap, and whether filters are combinable are all left 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%, including defaults, enum values and per-parameter examples, so the baseline of 3 applies. The description only restates the three filter dimensions and adds no interpretation beyond what the schema already documents (e.g., whether filters combine with AND semantics or how keyword matching works).

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 concrete verb and resource: returns documented 2026 growth moves by Indian companies from upGrowth research, with the filter dimensions named. It is clearly a research/dataset lookup rather than a calculator, though it never explicitly distinguishes itself from numeric siblings like growth_rate, growth_projection or ytd_growth.

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 described filters (sector, company, keyword) and the date-bounded dataset, so an agent can infer when a lookup is appropriate. There is no explicit when-to-use/when-not statement and no pointer to an alternative tool for related growth metrics.

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 computation, so the safety bar is low. The description adds genuine value by disclosing the concrete outputs produced (per-period rows, doubling time, time-to-target), which matters since 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?

A single tight sentence that front-loads the operation and model, then enumerates outputs with zero filler.

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

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

With no output schema, the description usefully explains the return shape, and the computation model is unambiguous. The main residual gap is routing guidance relative to sibling growth/forecast tools, which the description never addresses.

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 only 40%, but the description reinforces the compound-per-period interpretation of growth_rate_pct and the optional target_value, which adds real meaning over the schema. It does not cover period_type semantics (month/quarter/year) or the periods upper bound, so it partially compensates for the gap.

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 (projects forward) plus the exact model (compound growth per period), and names the concrete outputs: per-period values, doubling time, target horizon. This clearly distinguishes it from siblings like growth_rate (single rate), ytd_growth, and period_change.

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 described outputs; there is no explicit statement of when to pick this over growth_rate, period_change, or ppc_forecast, and no mention of prerequisites or limits (e.g., the 120-period cap). An agent must infer the choice from the math being described.

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 tool as read-only, idempotent, and non-destructive, so the safety profile is clear. The description adds that it computes both total and compound growth per period with examples, but does not describe edge cases, formula details, 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?

A single, front-loaded sentence with no wasted words. The examples are compact and directly support 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 read-only calculator with full schema coverage and annotations, the description is largely sufficient. It does not explicitly mention CMGR despite the title including it, but the month/quarter/year examples imply the mapping, and no output schema means return values need not be explained.

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 four parameters including the period_type enum. The description adds examples like 'month on month, quarter on quarter or year on year (CAGR)' but does not add syntax or constraints beyond the schema.

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

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

The description states a specific verb ('Calculates') and resource ('total growth and compound growth per period') and clarifies the inputs with examples. It is clear what the tool computes, but it does not explicitly distinguish itself from siblings like period_change or ytd_growth.

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 'between a start and end value' and the period examples, but there is no explicit guidance on when to use this tool versus alternatives such as period_change or growth_projection. No exclusion criteria are given.

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 fully covered by structured data, and the description correctly stays consistent with a pure calculation. It adds that the tool is an 'estimate' producing monthly and yearly figures, which is useful output context given there is no output schema, but it does not disclose the calculation model, how currency affects results, or how the two rate methods are combined.

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

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

A single well-packed sentence with the verb and output scope front-loaded, so an agent can decide quickly. The closing clause about cost per engagement adds length without adding a usable input, 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?

With eight parameters, two required, no output schema and only lightweight annotations, the description does a fair job: it names the rate bases and says the result is monthly and yearly income. It leaves the agent guessing about currency defaulting behaviour, how the two rate modes interact, and how average engagements factor in, which is a real gap for a calculator 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 every one of the eight parameters is already documented, including the either/or relationship between rate_per_post and rate_per_1000_followers. The description mirrors that at a high level but adds no syntax, defaults, or unit detail beyond the schema — baseline 3 applies. The mention of 'cost per engagement' is not backed by any parameter, which is a minor source of confusion rather than added meaning.

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

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

The description opens with a specific verb and resource ('Estimates monthly and yearly Instagram brand-deal income') and enumerates the rate bases (per post, per story, per 1,000 followers), which makes it distinguishable from siblings like youtube_earnings or ad_budget_planner. It stops short of naming the sibling alternative, and the trailing phrase 'the cost per engagement a brand pays' points at an input that does not exist in the schema, slightly muddying the scope.

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 choose this over alternatives (notably youtube_earnings, which shares the earnings-calculator role), and no prerequisites or exclusions. The use case is only implied by the phrase 'brand-deal income'.

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 agent knows this is a safe, deterministic, offline computation. The description reinforces this by describing a pure back-calculation and discloses the 3:1 default ratio. It stops short of describing the shape of the result (single number, per-currency formatting), which the missing output schema leaves to inference.

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

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

A single dense sentence with the core operation front-loaded ('works back from customer lifetime value') followed by the outputs and the default ratio. No preamble and no wasted clauses.

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, no-output-schema calculation tool, the description conveys the input concepts (LTV inputs, target ratio, optional lead conversion) and the outputs conceptually (max CAC, max cost per lead). Given 100% schema coverage and strong annotations, a 4 is warranted; only the concrete return format is left implicit.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds a small amount of meaning by tying the target ratio to the '3:1 default' and flagging that the lead metric is optional, but it introduces no syntax or modeling detail beyond the structured fields. 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 calculation: deriving the maximum affordable CAC (and optionally cost per lead) from LTV and a target ratio. An agent can immediately tell this is a unit-economics calculator rather than a general metric tool. It does not explicitly distinguish itself from siblings like customer_lifetime_value or unit_economics, but the verb+resource is unambiguous.

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

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

The use case is implied by the framing (working back from LTV to a CAC ceiling), and the mention of an optional lead calculation signals a variant. However, there is no explicit when-to-use guidance, no statement of prerequisites, and no pointer to the closely related siblings (customer_lifetime_value, unit_economics, break_even) that an agent would need to choose correctly.

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 tool as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond that: it discloses the calculation basis (uses the MDR % the user gives) and states that it does not look up provider rates, which is meaningful for an agent expecting external data retrieval.

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

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

Two tightly written sentences with no wasted words. The purpose and outputs are front-loaded, and the rate-lookup caveat follows naturally.

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?

Despite having no output schema, the description lists the return values (MDR fee, GST, total cost, effective rate, net settlement), which gives the agent enough to understand the response. The input basis is also clarified, so there are no significant gaps for this 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?

Schema description coverage is 100%, so the schema already documents all six parameters in detail. The description does not add syntax or constraints beyond noting that the MDR percentage is user-provided, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (calculates) and resource (MDR charges on card or payment gateway sales), then enumerates the exact outputs: MDR fee, GST on that fee, total cost, effective rate, and net settlement. This is far more specific than a generic calculator and clearly distinguishes the tool from unrelated siblings such as roas_check or break_even.

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 by naming the domain (card or payment gateway sales) and clarifies that the MDR percentage is user-supplied rather than looked up. However, it gives no explicit when-to-use guidance, no alternatives, and no exclusions beyond the rate lookup caveat.

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 safety is covered. The description adds genuine behavioral value by disclosing that the output includes character counts and truncation warnings, which an agent could not learn from the annotations or 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?

A single front-loaded sentence that names the verb, the artifact, and the extra diagnostics with zero filler. Nothing in it is redundant with the title or wasteful.

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 describing the return value, and it does partially by mentioning character counts and truncation warnings. It stops short of stating the container shape (HTML string versus a diagnostics object), which would be the last 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 seven parameters including the page_type enum and the optional twitter_handle are already documented in structured form. The description only restates the tag categories at a high level and adds no syntax, format, or constraint 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?

Uses a specific verb ('Builds') plus a concrete resource ('HTML head tags') and enumerates the tag families covered: title, meta description, canonical, Open Graph, Twitter card. This is enough to distinguish it from nearby generators like schema_generator and robots_txt_generator, though it never names those siblings 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?

The purpose strongly implies when to use it (when you need a complete head-tag block for a page), but the description gives no explicit trigger conditions, prerequisites, or alternatives such as schema_generator or content_seo_check. Usage is inferred 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value by specifying the change is 'simple' percentage change (i.e., not CAGR or compounded), but it omits the key edge case for this operation — what happens when previous_value is zero.

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

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

One front-loaded sentence that leads with the computation. The trailing clause ('including sales or revenue growth and percentage increase or decrease') is largely redundant restatement of 'percentage change' and could be cut.

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?

Simple, well-annotated, fully described schema — little is needed. But with no output schema, the description should state the return convention (percentage points like 25 vs a fraction like 0.25, and whether a decrease is negative), which is exactly the ambiguity that causes misuse of a change 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 coverage is 100%, so both numeric inputs and the 'comparison' enum are already documented, including that the enum is label-only. The description only restates 'between 2 values' and adds no ordering, sign convention, or scaling 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 ('calculates') and resource ('simple percentage change between 2 values') and enumerates the comparison types it covers (YoY, MoM, QoQ, WoW). An agent knows exactly what computation happens, but the description never distinguishes this from siblings like growth_rate or ytd_growth, which plausibly overlap.

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 through example scenarios ('sales or revenue growth', 'percentage increase or decrease'). There is no explicit when-to-use, no exclusion, and no routing away from growth_rate, ytd_growth or growth_projection, which are the most likely confusions in this sibling set.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds value by enumerating what the model returns (useful since there is no output schema). It does not disclose what happens when optional inputs (gross_margin_pct, value_per_conversion) are omitted — presumably profit/ROAS/break-even outputs degrade or disappear — nor whether results are monthly or annual.

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

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

A single dense sentence that front-loads the verb and the input contract, then lists outputs. No filler, though the output enumeration is long relative to the near-total absence of usage guidance — the space allocation is slightly off.

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, listing the computed metrics is necessary and present. But for a 6-parameter financial model the description leaves key gaps: the meaning of omitted optional inputs, the time period of the forecast (monthly implied only by the parameter name), and how it differs from sibling forecasting/ROAS tools.

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 67%, and the description only names three inputs (budget, CPC, conversion rate), ignoring currency, gross_margin_pct and value_per_conversion entirely. The optional two are the ones that change which outputs are computed, so their role deserves a sentence and the default INR currency is never mentioned. The description adds little beyond what the schema's own field descriptions already say.

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

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

States a specific verb ("Forecasts") with a concrete resource (paid search or social budget) and enumerates the outputs produced: clicks, conversions, CPA, revenue, ROAS, profit, break-even CPA. An agent can tell this is a modeling/calculator tool rather than a live-data read. It does not, however, distinguish itself from overlapping siblings such as roas_check, ad_budget_planner, break_even or max_affordable_cac.

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 stated inputs (budget, CPC, conversion rate) — an agent can infer this is a what-if projection rather than a measurement. There is no explicit when-to-use guidance and no mention of the sibling tools it overlaps with (ad_budget_planner, roas_check, max_affordable_cac), which is a real risk given the crowded calculator family.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds that it produces a verdict on whether the campaign covers its product cost, but it does not describe the shape or semantics of that verdict or how currency affects the numbers. Given annotations carry the safety burden, this is adequate rather than rich.

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

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

One front-loaded sentence that names the computation, the derived metric, and the conclusion. No filler, no repetition of the title.

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

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

With no output schema, the description must convey what comes back, and it does name both computed values plus a coverage verdict. It stops short of explaining the verdict's exact wording, formatting, or the relationship between the two returned ROAS figures, which leaves a small gap for a tool whose only output signal is prose.

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

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

Schema coverage is 100%, so all four parameters are already documented in the schema, including the INR default. The description maps the inputs to their roles ('break-even ROAS implied by gross margin'), which adds slight meaning beyond the schema but no format or edge-case guidance.

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

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

The description states a specific verb-and-resource pair: it computes ROAS and break-even ROAS from named inputs and adds a coverage verdict. That distinguishes it from sibling metrics tools like acos_check or campaign_roi by formula, though it never names those siblings 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?

Usage is implied by the formula (ROAS inputs in, break-even comparison out), but there is no explicit guidance on when to pick this over acos_check, campaign_roi, or break_even. An agent must infer the choice from the input vocabulary.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description rightly spends its words on the crawler-to-category mapping and the hard guarantee that Googlebot is never blocked — genuine behavioral context a caller cannot infer from structured fields. Minor ambiguity: 'Writes a robots.txt file' sits in slight tension with readOnlyHint=true, since it presumably returns file content rather than persisting it.

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

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

One front-loaded sentence, no filler, with the categories separated by a clean colon-list. The crawler parentheticals make it dense, but every name earns its place by disambiguating the three enum values.

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 five parameters are optional and there is no output schema, so the description should say what comes back (raw robots.txt text? lines per bot?). It covers inputs and policy semantics well but leaves the return shape and the read-vs-write ambiguity unaddressed.

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

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

Schema coverage is 100%, so baseline is 3, but the description earns above baseline by naming which concrete crawlers each enum value governs (GPTBot vs OAI-SearchBot vs ChatGPT-User), meaning the agent understands the blast radius of each allow/block choice rather than just the field label.

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 ('Writes a robots.txt file') and enumerates the exact scope: three crawler categories, private paths, sitemap. The generative verb also cleanly separates it from the sibling checker `ai_crawler_access_check` without needing to name it.

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 description (produce a robots.txt policy) but there is no explicit when-to-use, when-not-to-use, or pointer to the access-check sibling. The one real constraint given, 'Never blocks Googlebot', is a behavioral guarantee 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it checks Google-required properties for the chosen type and returns a ready-to-paste script tag, though it does not describe error behavior when required fields are missing.

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 tightly written sentences with no filler. The supported types and the validation/output behavior are front-loaded, and every sentence contributes useful 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?

Given the tool's complexity, nested data parameter, and lack of an output schema, the description is nearly complete: it explains the supported types, the validation against Google's required properties, and the return format as a ready-to-paste script tag. The only minor gap is that it does not explain how missing required properties are handled.

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

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

Schema description coverage is 100%, so the input schema already documents the two parameters in detail, including the nested data fields for each schema type. The description lists the supported schema types but does not add syntax or format guidance 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 states a specific verb and resource: it builds schema.org JSON-LD for a page. It enumerates the supported schema types (FAQ, local business, organization, article/blog post, product, person, breadcrumb), which makes the tool's scope immediately distinguishable from sibling tools like meta_tags_builder.

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 makes the usage context clear: generate structured data markup for a page, with supported content types listed. It does not explicitly name when not to use the tool or point to an alternative sibling, but the domain is clear enough for an agent to select it confidently.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds that the calculation is monthly and also yields a break-even traffic gain, but says nothing about determinism, rounding, currency handling, or how gross margin changes the result.

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

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

A single dense sentence that front-loads the verb, scope, and inputs with no filler. It is arguably over-compressed — the break-even clause is tacked on at the end without structure — but nothing is wasted.

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

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

For a closed-form calculator with full schema coverage and safety annotations, the description covers what is computed and roughly what comes back (ROI plus break-even traffic gain). With no output schema, a little more on the shape of the return value and the effect of gross_margin_pct would have completed it.

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

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

Schema description coverage is 100%, so every parameter (including months, currency, gross_margin_pct) is already documented. The description only echoes the required inputs and adds no syntax, unit, or default information 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?

States a specific verb ('Estimates') and a specific resource ('monthly return on an SEO investment'), and enumerates the drivers (visits gain, conversion rate, value per conversion, cost), which distinguishes it from generic ROI/ROAS siblings. It does not name any sibling explicitly, so the differentiation is only implicit.

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 pick this over campaign_roi, roas_check, break_even, or unit_economics, and no stated preconditions or exclusions. The only implicit cue is the word 'SEO', leaving the agent to infer selection from the tool 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the agent knows this is a pure, side-effect-free computation. The description adds no behavioral context beyond that: it does not say whether the brand value is included in the total denominator, whether all values must share the same metric/period, or what form the result takes.

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

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

A single front-loaded sentence that leads with the verb and resource before listing scope. Every clause carries information; there is no filler or repetition of the title.

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

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

For a four-parameter computation with no output schema, the description should say what comes back (a percentage share, presumably) and confirm how the denominator is formed. It covers the input domain well but leaves the result shape entirely 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 only 25% (only 'metric' is documented), so the description must partially compensate. 'Brand against competitors' and 'on any metric' imply that brand_value and each competitor's value are counts measured on that same metric, which helps. However, it never addresses the 20-competitor cap, the non-negative constraint, or the required-vs-optional split.

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 ('Calculates share of voice') and immediately scopes it ('for a brand against competitors'), then enumerates supported metric domains (AI citations, search impressions, ad impressions, social mentions, press coverage). No sibling tool computes share of voice, so an agent can distinguish it from the other calculators 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 'on any metric' phrasing implies broad applicability but never states when to choose this over alternatives (e.g. roas_check, engagement_rate, acos_check) or when it is inappropriate. Usage is inferable from the purpose statement rather than explicitly guided.

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 closed-world, so the safety profile is fully covered. The description adds nothing beyond that: no formulas (e.g. whether LTV uses gross margin and churn), no rounding/unit handling, no behaviour on degenerate inputs such as very high churn. Adequate but not value-adding.

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

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

A single front-loaded sentence that names the tool's outputs before its inputs, with no filler or redundant restatement of the title.

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

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

For a stateless calculator with no output schema, the description correctly enumerates the returned metrics, which is the key missing piece an agent needs. The remaining gap is methodological: the exact LTV and payback formulas are unspecified, so an agent cannot predict edge-case output values.

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 with units, ranges and examples. The description's phrase 'from spend, new customers, revenue per customer, gross margin and churn' merely restates the parameter set and adds no semantic detail such as period alignment between spend and new customers.

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 plus an explicit enumeration of the four metrics produced (CAC, LTV, LTV:CAC, CAC payback in months), which is far more concrete than the title alone. It is implicitly separable from siblings like customer_lifetime_value and max_affordable_cac because it bundles all four metrics from one input set, but it never states that distinction.

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 nature of the tool: an agent infers it is for computing unit economics from a spend/customer/ARPU/margin/churn snapshot. There is no statement of when to prefer it over customer_lifetime_value or max_affordable_cac, no prerequisites, and no exclusions.

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 that the estimate is a calculation with two alternative formula paths, but says nothing about return shape, rounding, or whether inputs are validated/clamped.

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

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

A single front-loaded sentence with the resource, the purpose, and both input paths; no filler and no restatement of the title.

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

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

With no output schema and six parameters, the description leaves the agent guessing what comes back (a single revenue figure? a breakdown?) and in which currency relative to the input currency. Adequate for invoking the tool, but thin for interpreting the result.

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

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

Schema coverage is 83%, so the per-parameter docs (RPM, CPM, fill rate, currency default INR) already carry most of the load. The description still adds genuine value by grouping the parameters into coherent modes — pageviews+page RPM vs pageviews+ads_per_page+CPM+fill_rate — a pairing the schema only hints at with 'Use this or cpm'.

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 ('Estimates display ad revenue for a website or blog') and names the two calculation paths, which distinguishes it from siblings like youtube_earnings or instagram_earnings only implicitly via 'website or blog'. Clear but does not explicitly contrast with the nearest 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?

The phrase 'or from ad impressions per page, CPM and fill rate' implies two alternative input modes, so an agent can infer which mode to pick. But there is no explicit when-to-use/when-not guidance, no mention of prerequisites, and no pointer to alternatives such as ad_budget_planner.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the calculation model (the 55% long-form creator share and the RPM-vs-CPM branch). However, it never says what the response contains — no mention of the earnings figure, watch-hours result, or gap to the Partner Program threshold — so the returned shape is opaque.

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

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

One dense sentence that front-loads the primary outcome (earnings) before the secondary one (watch hours). Every clause carries information, though the parenthetical formula makes it noticeably harder to scan.

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

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

There is no output schema, so the description is the only place the return values could be described, and it does not describe them. It also doesn't explain that watch hours depend on avg_view_duration_minutes or what the YPP threshold comparison yields. Adequate to call, insufficient to predict the result.

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

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

Schema description coverage is 100%, so each of the 7 parameters is already documented, including 'Use this or cpm' and the currency default of INR. The description reinforces the cpm/rpm relationship and introduces the 55% share constant, but adds little parameter meaning the schema does not already carry.

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

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

States a specific verb ('Estimates') and a precise resource ('YouTube ad earnings' and 'watch hours'), with the two input paths (RPM, or CPM x monetized playback % x 55% share) named. It is clearly distinct from the nearest sibling, instagram_earnings, but never names or routes to any alternative tool 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?

Usage is implied through the two calculation paths ('RPM from YouTube Studio' vs 'CPM, monetized playback % and 55% share'), which tells the agent which inputs to supply together. There is no explicit when-to-use, when-not-to-use, or comparison against instagram_earnings or website_ad_revenue.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description usefully adds that the calculation supports two input shapes and emits a full-year run rate, but it does not say what happens if both input modes are supplied, if monthly arrays are uneven, or what the response 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?

A single front-loaded sentence that states the comparison, the accepted inputs, and the extra output. Nothing redundant and nothing buried.

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

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

With no output schema, the description should say what the tool actually returns beyond 'a simple full-year run rate' – the growth figure and its shape are unstated. All five parameters are optional, and the description does not explain which combinations are valid, leaving a gap for a calculator with mutually exclusive input modes.

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

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

Schema coverage is 100%, so the baseline is 3. The description does add a little meaning by framing this_ytd_total/last_ytd_total as one alternative and the monthly arrays as another, but it does not clarify constraints such as matching lengths or that months_elapsed is what enables the run rate.

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?

placeholder

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 mention of YTD comparison and the two accepted input modes (monthly values or YTD totals), so an agent can infer the scenario. There is no explicit when-to-use or when-not, and no pointer to growth_rate or period_change for non-YTD comparisons.

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