Free Agent Tools

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: the output shape (risk tier, platform, matched policy phrases with explanations, next-step checklist) and the explicit limitation that it is heuristic and will not draft appeals or recommend replacement accounts.

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

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

Three sentences, front-loaded with the action and input, then the return values, then the caveat. Every clause carries information; nothing is restated from the schema 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?

With no output schema, the description carries the return-value burden and does so fully (risk tier, platform, phrases plus explanations, checklist). Input handling and the tool's epistemic limits are both stated, so an agent can call it and interpret results without further guessing.

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

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

Schema coverage is 100% and the param description already covers length and PII scrubbing, so the baseline is 3. The description goes slightly further by constraining what kind of text belongs in the field — suspension/disapproval/policy notices from four named platforms — which helps the agent decide whether a given string is valid input.

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 (paste/analyze notice text) plus resource (Google Ads / AdSense / Merchant Center / Meta policy notices) and a concrete output (HIGH/MED/LOW risk card). No sibling tool is anywhere near this domain, so the distinction 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?

Names the exact input situations (suspension, disapproval, or policy notice) and enumerates the four platforms, which tells the agent when this applies. It also draws a hard boundary — heuristic only, never suggests replacement accounts or files appeals — but does not name an alternative tool or say when not to use it.

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 safety is covered. The description adds the genuinely useful behavioral fact that this is a two-step tool whose output depends on whether answers are supplied, which the annotations do not convey.

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

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

Two tight sentences, front-loaded by mode, with zero filler. Every clause carries information about either input or output.

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 a single optional parameter, the description covers both return shapes and the accepted slug values, which is nearly everything an agent needs. It stops short of detailing the result format of the 'most constrained bottleneck' output, but that gap is minor.

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

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

Schema description coverage is 100% and the single parameter is fully documented as 'one slug per question.' The description restates the valid slug set, which is already enumerated in the schema, so it adds little beyond the structured data. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource for both modes: it returns the five quiz questions when called without answers, and the most constrained bottleneck when called with them. That is far more than a restatement of the name. It does not, however, distinguish itself from close siblings like ai_infrastructure_bottlenecks or viral_attention_quiz.

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

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

It effectively tells the agent when each mode applies: call with no answers to fetch the questionnaire, call with answers to score it. That is clear contextual routing, but there is no explicit when-not guidance and no named alternative among the sibling tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive/non-openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context that annotations cannot: the response includes example public companies, and it pre-empts misuse with "these are not investment picks," managing expectations about output content.

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

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

Two dense sentences, front-loaded with the scope enumeration and closed with the disclaimer. Every clause carries information; nothing is padded or repeated from the schema.

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

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

For a single optional-enum, read-only explanation tool with no output schema, the description adequately conveys scope, the default behavior, and the nature of the returned content. The absence of any return-structure hint is a minor gap, but the domain framing is sufficient for correct invocation.

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

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

Schema coverage is 100% and the enum values are self-describing, so the baseline is 3. The description adds value beyond the schema by explaining the omitted-slug default (all six categories) and by expanding terse enum labels into parentheticals ("memory (HBM)", "space (sites, backhaul)").

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 ("Explains") and a precise resource ("physical constraints on the AI buildout beyond chips"), then enumerates the six covered areas (compute, memory/HBM, optics, power, space, servers). An agent immediately knows the content domain, though it never explicitly contrasts itself with the similarly-themed ai_bottleneck_quiz sibling.

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

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

The only usage instruction is "Omit slug for all six," which tells the agent how to invoke the default case. There is no explicit guidance on when to reach for this tool versus alternatives, and no stated exclusions, so usage is implied rather than spelled out.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds real context beyond that: what the score is broken down into (per-guideline reasons and a per-feature nativeness read) and an expectation-setting disclaimer that Apple is the final decider, not the tool.

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

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

Two compact sentences, front-loaded with the target audience and the guidelines being scored. The trailing disclaimer is short and earns its place by capping liability expectations.

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

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

With no output schema, the description carries the return-value burden and does state what comes back (reasons and a nativeness assessment). It could say more about the score scale or output shape, but for a read-only analysis tool this is close to complete.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, which sets the baseline at 3. The description restates the stack domain but adds no new meaning for 'features' (the minItems 1 / maxItems 3 constraint) or the name/description fields.

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 ('scores rejection risk') and resource (App Store Guidelines 4.2, 4.3, metadata) plus the exact input domain (Capacitor, WebView, PWA-shell, React Native, AI-generated iOS apps). No sibling tool overlaps this namespace, so the agent can route here unambiguously.

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

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

Clearly scopes when the tool applies by enumerating the app stacks and origin types it targets, which doubles as the trigger condition for calling it. It does not state when not to use it or name alternatives, but none of the siblings are plausible substitutes.

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

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

Annotations already declare a safe, idempotent, closed-world read operation, so the safety profile is covered. The description usefully adds that results come in low/mid/high scenarios and that a partner share can be applied, but it does not explain what the returned figures represent or how the scenarios are derived.

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 estimation target front-loaded and the optional partner-share modifier at the end. Nothing is wasted, though the phrase 'in low / mid / high scenarios' is slightly ambiguous about whether scenarios are inputs or 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?

With no output schema, the description carries more of the burden for explaining results, and it only gestures at the return (buyers, revenue, three scenarios) without saying what each scenario contains or how partnerShare affects the numbers. Adequate for a read-only calculator but leaves the output shape underspecified.

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

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

Schema description coverage is 100%, so every parameter (buyRate, contacts, reachable, orderValue, partnerShare) is already documented with defaults and ranges. The description only echoes partnerShare and orderValue at a high level, adding no syntax 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?

Specific verb ('Estimates') plus a concrete resource (buyers and revenue from one offer to past customers), with scenario framing that clearly marks it as a calculator. It is easily separable from sibling calculators like price_headroom_check or thirty_day_cash_check, though it 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?

The description says what is computed but gives no when-to-use context, no prerequisites, and no indication of when this model is or is not appropriate versus the other estimate/calculator siblings. Usage must be inferred entirely 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 readOnly, idempotent, closed-world safety, so the description is free to focus on output semantics: HIGH/MED/LOW rating, signals, and myths to drop. It adds real context via the anti-hype stance and the explicit non-goal. Missing detail on how the answers map to the rating, but the safety profile is covered.

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

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

Three tight sentences, front-loaded with what the tool does and what it returns. The '$10k/month' framing reinforces intent rather than padding, though it borders on positioning rhetoric rather than invocation guidance.

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

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

With no output schema, the description correctly carries the return-value burden (rating plus signals and myths) and states the scope boundary. An agent has enough to invoke correctly; only the rating derivation and per-parameter mapping remain unstated.

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

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

All seven parameters are fully described in the schema with enums (100% coverage), so the schema does the heavy lifting. The description only alludes to 'seven multiple-choice answers' without adding meaning to any individual field. 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 and resource: a seven-question reality check on faceless/AI YouTube plans that returns a HIGH/MED/LOW expectation and risk rating. This distinguishes it from generic siblings like viral_attention_quiz, though it never names a specific alternative. The scope is clear and concrete.

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 closing phrase 'Not a ban prediction' usefully excludes a nearby misinterpretation, and the framing implies usage for people planning faceless/AI channels. But it gives no explicit when-to-use or how to choose between it and siblings such as viral_attention_quiz or ads_policy_notice_risk_check.

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 carries little weight here. Since there is no output schema, the description's listing of returned figures adds real value, but it says nothing about currency handling beyond 'any currency' or how defaults are applied.

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 opens with the target audience and then lists outputs. The OTA brand parenthetical ('Booking.com, Expedia, Agoda...') is somewhat expendable, but overall it is tight with no filler.

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

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

With no output schema, the description compensates by enumerating the return values, which is what an agent most needs here. Combined with 100% schema coverage and clear read-only annotations, nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so all seven parameters are already documented with types, bounds, and defaults. The description references shift, commission, and net savings but adds no syntax, units, or format detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description names the audience (hotels, ryokan, guesthouses, B&Bs) and enumerates the computed outputs (yearly room revenue, OTA commission, HIGH/MED/LOW commission share, net savings from shifting to direct), so its purpose is unambiguous. No sibling overlaps this calculation domain, so explicit differentiation isn't needed, though the verb 'calculates' is only implied.

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 audience framing — a hotel evaluating OTA commission burden uses this — but there is no explicit when-to-use statement, no prerequisites, and no named alternative among the sibling tools. The context is derivable but not stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. With no output schema, the description adds real value by disclosing what the call returns (cities with regions, peak months, stay areas; months with season and crowd level; traveler types).

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 sentence with the verb front-loaded and no filler. The stacked parentheticals make it slightly dense to parse, but every clause enumerates distinct returned content.

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

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

For a zero-parameter, non-destructive list tool with no output schema, the description covers both the returned content groups and the downstream consumer. Little of consequence is missing.

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

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

The tool takes zero parameters and the schema is an empty object, so baseline 4 applies. There is nothing for the description to compensate for.

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 ('Lists') and enumerates the exact resources returned: supported cities with regions/peak months/stay areas, months with season/crowd level, and traveler types. It also names the sibling it feeds (japan_trip_plan), which helps distinguish it, though it does not contrast with the many other siblings in the namespace.

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 'for japan_trip_plan' implies this is a prerequisite discovery call, but it never states when to use it (e.g., 'call before japan_trip_plan to learn valid inputs') or any exclusions. Usage is inferable rather than explicit.

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 genuinely useful context beyond that: the output is typical seasonal patterns rather than live data, and it discloses the shape of the result set including ranked stay areas and booking links.

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 enumerates the payload, followed by a short qualifier that prevents a major misinterpretation. The content-heavy list is front-loaded and every clause carries information, though the enumeration is somewhat breathless.

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 carries the burden of describing return values, and it does so thoroughly — items, warnings, crowd level, weather, ranked stays, and search links. Combined with annotations covering safety, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and all three parameters are documented, so the baseline is 3. The description mentions that stay areas are ranked for the traveler type, but the schema already states this, so it adds no new parameter semantics.

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

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

The description names a specific resource and enumerates the exact contents returned (stay areas, festivals, crowd level, weather, warnings, booking links) scoped to a city and month. It reads as a concrete travel-planning generator, but it never distinguishes itself from the close sibling japan_trip_options, leaving the agent to infer the boundary.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The trailing 'Typical seasonal patterns, not live data' implicitly signals that this is for planning rather than real-time lookups, but usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the list is exhaustive/static ("every covered paid tool") and each entry carries setup effort and a "main catch", which tells the agent the payload includes tradeoffs, not just names.

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 verb first and the payoff (open-source swap) immediately after. The long parenthetical vendor enumeration is informative but drags the sentence out; it could be trimmed without losing meaning.

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 input parameters and no output schema, the description carries the burden of conveying the return shape, and it does list the expected fields per entry (swap, repo, license, setup effort, catch). It stops short of saying how many entries or how current the data is, which leaves a small 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. Schema coverage is 100% and the empty object schema is self-explanatory.

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 ("Lists") plus a precisely scoped resource: every covered paid tool with its open-source swap, GitHub repo, license, setup effort, and main catch. Naming the concrete vendors makes it trivially distinguishable from siblings such as saas_self_host_savings or price_headroom_check.

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 states what the tool returns but never says when to reach for it versus the closely related saas_self_host_savings sibling, nor any prerequisites. An agent must infer usage purely from the name and content list.

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

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

Annotations already declare the safe, idempotent, closed-world read profile, so the burden is lighter. The description adds genuine interpretive behavior beyond annotations by disclosing the close-rate thresholds (80%+ / ~30% / <25%) that drive its judgment.

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

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

Front-loaded with the guiding question, then the logic and outputs in one dense sentence with no filler. The parenthetical thresholds lengthen it slightly but each adds decision value.

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

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

With no output schema, the description correctly spells out the three returned results, and annotations cover the safety profile while the schema covers all five parameters. Nothing critical for correct invocation is missing, though tie-in to sibling tools is absent.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns an extra point by giving operational meaning to closeRate via its threshold bands. It still says nothing extra about price, netMargin, customersLost, or newPriceMultiple beyond the schema text.

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

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

The description names a concrete analytical job and enumerates its three outputs (suggested price range, profit multiple of a price rise, break-even customer loss), which no sibling calculator does. An agent can tell exactly what this computes 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 framing 'Is the business underpriced?' implies the use case, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling business calculators. Usage is only inferable.

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

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

Annotations already establish readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the return shape (repo, license, caveat, savings, break-even months, verdict tiers) and the hosting/rate assumptions behind the numbers, though it does not mention any input constraints on the spend map.

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

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

Two dense sentences, front-loaded with the required input before the returned metrics. Every clause carries information, though the inline id enumeration makes it heavier than necessary when the schema already lists them.

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

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

With no output schema, the description correctly compensates by naming the returned fields and verdict categories, and the parameter schema fully documents all three inputs. Only the missing sibling differentiation keeps it short of complete.

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

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

Schema coverage is 100%, including the enum of allowed tool ids and the defaults for hourlyRate (50) and hostingPerMonth (20). The description repeats the id list but adds no syntax or formatting meaning 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 action (accept monthly spend per paid tool) and a concrete computed result (open-source swap, yearly savings, setup hours and cost, break-even, verdict). The enumerated tool ids and the SWITCH/MAYBE/KEEP output make the resource 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?

No guidance on when to use this versus alternatives such as list_open_source_saas_alternatives, which sits right next to it in the sibling set. The condition for choosing the savings/payback calculation over a plain alternatives listing is left entirely 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 this a safe, read-only, idempotent evaluation. The description adds genuine behavioral context beyond that: it discloses what gets returned (weakest factor, how to fix it, red flags) and the scoring thresholds that drive the verdict, plus a scope disclaimer.

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

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

Three tight sentences, front-loaded with the scoring rubric and decision bands. The returns sentence is warranted because no output schema exists; the disclaimer earns its place. Minimal waste overall.

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

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

With no output schema, the description correctly steps in to summarize return values (weakest factor, fix, red flags) and the verdict logic. It is complete enough to call correctly, though it could say more about how the rubric maps to the returned fix guidance.

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 seven parameters are already documented with ranges and defaults. The description names the four scored factors and indicates the three booleans feed 'pain / money / willingness-to-suffer checks,' adding modest meaning but no syntax or scoring detail beyond the schema.

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

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

States a specific verb ('Score') on a specific resource ('business idea') and enumerates the exact dimensions (Margin, Operations, Advantage, TAM) plus the decision bands. This clearly distinguishes it from analytical siblings like price_headroom_check or thirty_day_cash_check.

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 communicates what the scoring means (FUND/FIX/FLEE bands) and its educational nature, which implies usage, but never states when to reach for this tool versus the many sibling evaluators. There are no explicit conditions or named alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the interpretation thresholds (2x+ SELF-FUNDING, 1-2x BREAK-EVEN, under 1x CASH-HUNGRY) and, critically given the absent output schema, what is returned ('the gap to 2x and tips').

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

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

Three short sentences, front-loaded with the core comparison, then the scoring bands, then the return. Every sentence contributes; only the interpretive band list is a slight expansion, but it is high-value here.

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

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

For a three-parameter read-only calculator this is nearly self-sufficient: it explains the computation, the thresholds, and the return payload despite there being no output schema. Units/currency for the monetary inputs are the one notable omission.

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 cac, cash30 and cogs30 are already documented in the schema. The description uses the same terms ('acquisition cost', '30-day cost to serve') without adding format, unit, currency, or default guidance. The baseline of 3 applies when the schema carries the load.

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 object: it compares 30-day cash collected against acquisition cost plus cost to serve. It also names the resulting metric bands, so the purpose is unambiguous. It does not differentiate itself from sibling calculators (e.g. price_headroom_check), so it stops short of a 5.

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

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

The framing ('Do customers fund growth?') implies when the tool is relevant, but there is no explicit when-to-use statement, no prerequisite data requirements, and no named alternative among the many sibling calculators. Usage is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds genuine context beyond them: the content is educational and deliberately not an investment signal, which prevents misuse in a trading context. It does not, however, describe the shape or volume of the returned pattern list.

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 compact sentence with an enumerated parenthetical that front-loads the subject matter, followed by the two short scoping clauses (filter, educational disclaimer). No filler, though the parenthetical list is slightly long and could be trimmed.

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

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

For a one-parameter, read-only, no-output-schema tool, the description covers purpose, content of each result ('signal to watch and the lesson'), and the caveat about interpretation. It is nearly complete; the only gap is routing relative to viral_attention_quiz.

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?

With a single optional parameter and 100% schema description coverage, the schema already carries the semantics ('Optional platform filter, e.g. TikTok or X.'). The description only repeats 'Optional platform filter' without adding values, matching behavior, or defaults, so baseline 3 applies.

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

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

The description names a concrete resource (patterns of how attention spreads) and enumerates the concrete forms it covers (TikTok sound reuse, quote-post piles, stitch chains, group-chat forwards), plus what each entry contains ('the signal to watch and the lesson'). That is enough for an agent to know what comes back, but it never distinguishes this from the sibling viral_attention_quiz, so sibling differentiation is missing.

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: 'Educational; attention is not an investment signal' hints at the setting (informational/educational queries rather than financial analysis), but there is no explicit when-to-use, when-not-to-use, or pointer to viral_attention_quiz as the alternative for interactive/scored output.

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

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

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description earns credit by disclosing what each mode returns (six questions vs. tilt plus short explanation), which is genuinely useful since there is no output schema; it does not mention answer-count validation or pagination-style concerns, but for a read-only quiz that is minor.

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

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

Two tight sentences, each covering one mode, with the no-answers case front-loaded. 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 one-optional-parameter, read-only quiz with no output schema, the description covers both the input expectation and the return shape adequately. It could go slightly further on what the 'tilt' categories mean or how many answers are expected, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100% and the single optional parameter is already documented ('One tilt per question') with its enum values in the schema. The description restates the enum ('chaser, inventor, reader') and the per-question cardinality, adding little beyond structured data, so the baseline 3 applies.

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

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

The description states a specific behavior with two clear modes: returning six quiz questions when called without answers, and returning a computed 'tilt' plus explanation when called with answers. This is a precise verb+resource statement, though it does not explicitly distinguish itself from the sibling 'viral_attention_patterns', which an agent might reasonably confuse it with.

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

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

It clearly defines the two invocation conditions ('Without answers...' vs 'With answers...'), which tells the agent exactly when each code path applies. It stops short of naming alternatives or stating exclusions relative to sibling quiz/scoring tools, so it is clear context rather than full routing guidance.

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