SaaSCity

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds useful behavioral context by identifying the test type and the sample-ratio-mismatch diagnostic; the output schema reduces the need to explain return values.

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 states the test and lists the outputs, followed by a reference URL. There is no redundant or buried information.

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

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

For a low-complexity calculator with full schema coverage, clear annotations, and an output schema, the description supplies sufficient domain context (test type and diagnostic checks) for an agent to invoke 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?

All five parameters have schema descriptions at 100% coverage, including confidence_pct's allowed values and default. The description does not add parameter semantics beyond what the schema already provides, 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?

Names a specific statistical procedure and target (two-proportion test of an A/B result) and enumerates the outputs, making it clearly distinguishable from sibling calculators such as ARR, churn, NPS, and rule-of-40.

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

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

Provides no explicit when-to-use, prerequisites, or alternative-selection guidance. The A/B-result framing implies the intended use case, but an agent must infer it from the purpose statement rather than being routed by the description.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavioral rules: how annual plans are normalized into MRR and that one-time fees are excluded, which prevents wrong calls. Return values are covered by the existing 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?

Front-loaded with the core formula, followed by the input conventions an agent needs. The trailing link to an external calculator is mild promotional filler but occupies little space.

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

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

Return shape is handled by the output schema and inputs are fully documented, so little is missing. However, the absence of any routing guidance relative to calculate_arr_bridge keeps it from being fully complete for selection.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by tying each optional parameter to its purpose: customers yields ARPU, and monthly_growth_pct yields months to $100k/$1M/$10M ARR. That is meaning beyond the bare 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?

States a specific transformation with the exact formula (ARR = MRR x 12) plus the derived outputs, so the agent knows precisely what it computes. It does not distinguish itself from the sibling calculate_arr_bridge, which is the only remaining ambiguity.

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

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

No explicit statement of when to prefer this over calculate_arr_bridge or calculate_churn, so tool selection is left to inference. It does give input-handling guidance (count annual plans at yearly price / 12, exclude one-time fees), which is useful but is not selection 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, idempotentHint and a closed-world scope, so the safety profile is covered. The description adds real behavioral substance by disclosing the exact accounting identity being applied and the derived metrics (quick ratio, NRR/GRR) rather than leaving the computation 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?

Two sentences, front-loaded with the purpose and equation, then the outputs. The trailing calculator URL is marginal but plausible as a reference; otherwise there is 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 an output schema present, return values need not be detailed, and the description still enumerates them briefly. Five parameters at full schema coverage plus read-only annotations leave little an agent needs to know that is missing; handling of omitted optional terms is the only unstated detail.

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

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

Schema coverage is 100%, so a baseline of 3 applies, but the description goes further by placing each term in the equation with its sign — clarifying that contraction and churned ARR are subtracted and that expansion only counts existing customers. This removes the main ambiguity between contraction and churn beyond what the schema alone conveys.

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 ('Explain how ARR moved over a period') and gives the exact bridge identity, so the tool's job is unmistakable. It does not explicitly distinguish itself from the sibling calculate_arr or calculate_churn, which is the only thing keeping it off 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 period-comparison framing implies when to reach for this over a point-in-time ARR calculation, but the description never names the alternatives or states exclusions. An agent must infer the choice from the formula rather than being routed explicitly.

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 establish that this is a read-only, idempotent, closed-world calculation, so the description's main added value is the compounded-math note (5% monthly ~ 46% annually, not 60%). It does not say what happens when the optional 'period' is omitted, so the default behavior stays a mystery.

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

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

The core value proposition is front-loaded in one dense sentence with no filler. The trailing marketing URL is the only element that does not serve tool selection.

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 an output schema present, the description does not need to enumerate return values, though it helpfully names the derived outputs (monthly/annual equivalents, average lifetime) that are not obvious from the inputs. The only real gap is the unstated default for the optional period argument.

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

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

Schema description coverage is 100%, so all three parameters are documented in the schema with the enum for period. The description adds nothing beyond this: it does not explain how 'customers_at_start' relates to 'customers_lost' or what the default period is, so the baseline of 3 applies.

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

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

The description names a specific verb-and-resource pair: churn/retention over a period, plus monthly and annual equivalents and average customer lifetime. That separates it cleanly from the revenue-focused siblings (calculate_arr, calculate_arr_bridge), though no sibling is named explicitly.

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

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

There is no guidance on when to use this tool versus calculate_arr or the other calculators, and no mention of prerequisites or exclusions. The trailing link to the web calculator is promotional rather than decision-oriented.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the output includes a margin of error at 95% confidence, telling the agent what statistical result to expect beyond the score itself.

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 front-loads the metric, the inputs, and the 95% confidence detail; the second fragment is just a link. Nothing is padded, though the promotional URL is marginal value for an agent.

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

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

The tool is simple: three required numeric parameters, full schema documentation, annotations covering side-effect profile, and an output schema that presumably explains the returned score and error. The description supplies the calculation basis and output characteristic, so an agent can call it confidently with only the underlying NPS formula 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% and each of the three parameters already documents its score range (9-10, 7-8, 0-6). The description repeats those same buckets without adding format, validation, or edge-case guidance, so it adds little over the schema — the baseline 3.

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

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

States a specific verb (calculate) and resource (Net Promoter Score) plus the exact input buckets, so the agent knows precisely what is computed. It does not explicitly contrast itself with the many sibling calculators (calculate_arr, calculate_nrr, rule_of_40), though the NPS label makes the distinction self-evident.

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 or when-not-to-use guidance, no prerequisites, and no mention of alternatives. The trailing URL to a web calculator is a reference link, not invocation guidance, leaving usage entirely inferred 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, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that figures are annualised and names the MRR components, but it does not discuss edge cases, calculation assumptions, or behavior beyond the structured 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 description is a compact single sentence followed by a reference link, front-loading the metrics and inputs. It is efficient, though the external link is ancillary and not essential to invocation.

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

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

With an output schema present and 100% schema description coverage, the description only needs to frame the purpose and inputs, which it does. It omits any note about period granularity or edge conditions, but those are largely covered by the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explicitly mapping the starting, expansion, contraction, and churned MRR inputs to the retention calculation, adding conceptual meaning beyond the field names; only period is left to 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 clearly states the specific metrics computed (NRR and GRR) and identifies the input components (starting MRR, expansion, contraction, churned MRR). It does not explicitly distinguish itself from sibling calculators such as calculate_arr or calculate_churn, 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?

Usage is implied by the metric definitions, but there is no explicit when-to-use guidance, no exclusions, and no reference to alternative tools like calculate_churn or calculate_arr. The link to an external calculator is supplementary rather than a usage rule.

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

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

Beyond the readOnly/idempotent annotations, it discloses meaningful behavior: the tool also reads the homepage for deep pages, renders JavaScript when static HTML is insufficient, and explains that a verified badge makes the listing link dofollow. No contradiction with annotations exists.

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 compact sentences that front-load purpose, then detail scanning behavior, then state the meaningful consequence. There is no filler, repetition of annotations, or redundant schema 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 single-parameter, read-only tool with existing annotations and an output schema, the description covers the essential operational context: what gets scanned, the homepage fallback, and the dofollow implication. It is nearly complete, though it leaves detailed output interpretation to the output schema.

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

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

With 100% schema description coverage for the single required url parameter, the baseline is 3. The description adds the conditional homepage-reading nuance, but does not introduce format or syntax guidance beyond what the schema already provides.

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

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

States a specific verb and resource: checking whether the SaaSCity badge is live on a site. It also describes observable behaviors (reading URL, homepage fallback, JS rendering), so an agent can clearly distinguish it from siblings like check_launch_readiness or get_listing.

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 the use case: verify badge liveness on a site. However, it does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria, leaving the selection logic mostly to the agent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds genuine behavioral value beyond that: it discloses that og:image is actually fetched to confirm it loads (an outbound network side effect beyond the main URL), that it reads static HTML the way directory scrapers and link-preview bots do, and that it detects JS-empty pages. These are useful non-obvious behaviors an agent could not infer from annotations alone.

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 main purpose is front-loaded, and the description is dense with information rather than padded. The long enumeration of checks is justified because it conveys the audit scope precisely and lets an agent match it to user intent. Slightly long as a single paragraph, but every clause earns its place.

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

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

For a single-parameter tool with a rich output schema and safety annotations, the description is complete: it states the purpose, the full audit scope, the return shape (score, verdict, fix), and the reading behavior. Since an output schema exists, the description need not detail return fields, and the annotations cover the read-only/idempotent safety profile.

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

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

Schema coverage is 100% and the schema already documents 'url' as the Homepage URL with the https:// prefix optional. The description reinforces that the URL should be a homepage and implies the audit targets that URL, but it adds no new format, constraint, or meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource pair ('Audit a product homepage before launching it') and then enumerates a concrete checklist (HTTPS, noindex, meta, og:image, canonical, etc.), leaving no doubt about what the tool does. None of the sibling tools (check_badge, get_listing, submit_project, etc.) perform auditing, so the scope is clearly differentiated.

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 'before launching it' gives clear usage context and timing. However, it does not name alternatives or state explicit when-not-to-use conditions. Since no sibling tool is a close substitute, the absence of explicit exclusions is acceptable, placing this at clear-context-without-exclusions rather than full alternative routing.

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 and idempotentHint, so no safety disclaimer is needed. The description adds behavioral context beyond those: it returns only other listings in the same category and sorts them 'most upvoted first,' which an agent cannot infer from the schema or annotations alone.

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

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

Two sentences with no filler: the first defines the tool's behavior and output ordering, and the second supplies a practical use case. Every word earns its place, and the most important information is front-loaded.

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

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

The output schema is present, so return-value details are already specified. The description covers selection logic, ordering, and use case; the schema covers parameters; and annotations cover safety. Nothing essential is missing for an agent to invoke this tool 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%: both 'slug' and 'limit' have descriptive text in the input schema. The description's 'given listing' implicitly refers to slug but adds no parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific outcome: 'Other SaaSCity listings in the same category as a given listing, most upvoted first.' It makes clear the resource (SaaSCity listings), the selection logic (same category), and the ordering, which distinguishes it from siblings like search_listings, get_listing, and get_leaderboard.

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 'Useful for competitor research and positioning' provides a clear use case, but the description does not explicitly guide the agent on when to choose this tool over related alternatives such as search_listings or get_listing. The usage guidance is implied by the definition rather than stated as a decision rule.

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/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the corpus size, that results are submit URLs, and an explicit caveat about the meaning of 'unknown' values in the returned data - a data-quality trait no annotation conveys.

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

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

Two front-loaded sentences: filters first, output and caveat second. Every clause carries content and nothing is repeated from the schema. It is dense but not padded; the only cost is that the long first sentence packs a lot before the agent reaches the important 'unknown' caveat.

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 9 optional params, an output schema, and full annotations, the description covers enough: what is searched, what is returned, and how to interpret ambiguous values. The remaining gap is routing guidance against related siblings (recommend_launch_directories, get_launch_directory) in an otherwise crowded tool family.

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

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

Schema coverage is 100%, so baseline is 3. The description still earns a bump by explaining that link_type and pricing filters can yield 'unknown' results and what that means, which is semantic meaning the enum definitions ('dofollow = verified followed link') do not fully carry on their own.

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

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

The description names a specific verb (filter/find) and resource (startup, SaaS and AI directories) and quantifies the corpus at 1,667 entries, plus states the output (submit URLs). It stops short of distinguishing itself from the sibling recommend_launch_directories, so an agent must infer the split (raw filter vs. recommendation) from names 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?

It gives useful usage semantics for the result set - unverified link type/price should be treated as unknown rather than free/dofollow - but never says when to choose this over recommend_launch_directories, get_launch_directory, or check_launch_readiness. Usage is implied by the filter list 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 cover readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds behavioral detail by noting that input can be a domain or any URL, and that the human verdict may not exist ('where one exists'). This goes beyond the structured annotations without contradicting them.

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 sentences with no filler. The core action is front-loaded, followed by a compact attribute list and a practical use case, making every sentence earn its place.

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

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

Given a single well-documented parameter, an output schema, and annotations covering safety and idempotency, the description provides all needed context: what data is returned, how to identify the directory, and why to use the tool. Nothing critical is missing.

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

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

Schema coverage is 100% and the domain parameter's description is fully self-explanatory with examples. The description repeats 'by domain or URL' but adds no new semantic information beyond what the schema already provides, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Look up one directory') and enumerates the exact data returned (Ahrefs DR, dofollow/nofollow, price, badge swap, submit URL, human verdict). This clearly differentiates it from siblings like find_launch_directories (plural) and recommend_launch_directories by emphasizing singular lookup and the vetting use case.

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

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

The description gives an explicit usage context: 'Use it to vet a directory before paying for a listing.' This tells the agent when to invoke it, but it does not name alternatives or state when not to use it, so it misses the full exclusion guidance required for a 5.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds concrete behavioral detail: it returns the next 12 Mondays, remaining free-slot counts, and full/not-full status. It explains exactly what kind of data the caller will receive, even though the output schema is available.

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

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

Two short, information-dense sentences. The first states the core output, and the second states the practical use case. Every word earns its place, with no repetition of the title or 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 parameterless, read-only, idempotent tool with an output schema, the description is complete. It covers what the tool returns)Skip and why an agent would call it, leaving no missing behavior that the agent needs to invoke 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?

There are zero parameters, so the input schema already fully covers the calling contract. The baseline for a parameterless tool is 4; the description adds no unnecessary parameter commentary, which 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 clearly identifies the resource: SaaSCity's launch-week queue over the next 12 Mondays, and specifies what the tool reports (free slots left and full weeks). This is a direct, unambiguous statement of the tool's function and distinguishes it from siblings like get_launch_directory.

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 final sentence gives an explicit use case: telling a founder when a free listing would go live. It does not name alternative tools or state when not to use it, but for a zero-parameter read-only queue listing, the intended context is clear.

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 and idempotentHint, so the safety profile is covered. The description adds that results are 'most upvoted' and filterable by period/category, but it does not disclose pagination behavior, tie-breaking, or any other operational detail beyond the schema.

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

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

The description is one focused sentence that front-loads the resource and immediately states the filtering dimensions. There is no filler, repetition, or ambiguity-added wording.

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

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

For a read-only tool with zero required parameters, full schema coverage, an output schema, and safe annotations, the description is largely complete. A minor gap is that it does not reference sibling tools like get_launch_weeks to help with launch week semantics, but this is not essential 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%, and each parameter already has descriptions, defaults, and enums where applicable. The description adds only a light gloss — 'last 30 days' for the month period and optionality for category — which meets the baseline but does not substantially exceed the schema's own documentation.

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 — 'SaaSCity's most upvoted launches' — and the exact scope dimensions: current week, last 30 days, all time, and optional category. This clearly distinguishes the leaderboard tool from sibling search/list tools like search_listings or get_listing.

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

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

The description gives a clear context for use: retrieve ranked launches by selecting a period and optionally a category. It does not explicitly name alternatives or state when not to use it, but the scope is unambiguous enough that an agent can decide appropriately.

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 openWorldHint=false, so the agent knows it's a safe, read-only call. The description adds that it retrieves a 'live' listing, implying the listing must be live, and it specifies the exact fields returned and the slug format, which provides useful behavioral context beyond the annotations. The description does not contradict 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 description is a single sentence, concise and front-loaded with 'One live SaaSCity listing by slug', immediately stating the purpose and parameter. It lists the return fields efficiently without excessive detail. It's slightly dense but earns its length.

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, single-parameter tool with a rich output schema and annotations covering safety, the description is complete: it specifies the input (slug), the output fields, and the nature of the data ('live'). It doesn't mention pagination or error cases, but those are less critical given the tool's simplicity and the annotations.

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%, as the schema fully describes the 'slug' parameter, including its meaning and format. The description also mentions the slug is the last part of the URL, which adds a little context, but since the schema already covers it, the description adds minimal extra 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 clearly states the tool fetches a single SaaSCity listing by slug, and enumerates the fields returned. It distinguishes from siblings by specifying 'One live listing' and 'by slug', though it doesn't explicitly contrast with search_listings or get_leaderboard, so it's clear but not fully differentiated.

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 when you need a specific listing's details by slug, but it doesn't explicitly state when to use this versus search_listings (e.g., for filtering or searching) or get_leaderboard. It says 'One live ... by slug', which implies direct access, but no explicit guidance on alternatives or 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/idempotentHint/openWorldHint=false, so safety is covered. The description adds non-obvious behavior: these are 'real prices' with enumerated entitlements, and crucially that payment is human-only on the claim page, meaning the agent cannot transact on the user's behalf.

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 resource and then the tier list. The parenthetical bundle of entitlements is information-rich rather than filler, though the sentence is long enough to be slightly hard 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?

No parameters and an output schema exists, so return-shape detail is unnecessary. The description covers what the offers are, what each tier grants, and the human-payment constraint — enough for an agent to call it and use the result 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?

The tool takes zero parameters, so the schema carries no semantics to add. The description correctly spends its words on the returned offer structure instead.

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

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

States a specific resource (SaaSCity listing offers) and enumerates the concrete tiers it returns (free queue, Quick Pass, Premium) along with what each buys. It is clearly distinguishable from get_listing/search_listings, though it never names the sibling that would be the wrong choice.

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 rather than stated: an agent is expected to call this to learn pricing/perks before or alongside submit_project. The line 'Only a human can pay, on the claim page' usefully bounds what the agent can do, but there is no explicit when-to-use, when-not-to-use, or alternative named.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered and the description needn't repeat it. The description adds genuine value by enumerating the full status state machine and noting the two distinct response shapes per mode. However, it never addresses the zero-required-parameter design — what happens if both parameters are supplied, or neither — which is the main behavioral ambiguity for a caller.

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, the core purpose front-loaded, and the two access modes split cleanly across the second and third clauses. Slightly telegraphic phrase fragments ('Where a SaaSCity submission stands') 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 an output schema present and read-only idempotent annotations, most of the burden is already carried elsewhere, and the description covers the domain states. The gap is the optional/optional parameter design: it never says whether the modes are exclusive or what is returned when no identifier is given, which an agent needs in order 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 coverage is 100%, so the baseline would be 3, but the description goes further by mapping each parameter to a different result: claim_token yields a claim-funnel state, slug yields live-listing attributes (launch week, badge, link type, points). That mode-to-output mapping is meaning the schema alone does not convey.

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

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

States a specific resource and operation: it reports where a SaaSCity submission stands, and enumerates the possible states (unclaimed, expired, in review, rejected, archived, live). It is clear what the tool returns, though it does not name sibling tools it might be confused with — notably get_listing, which it partially overlaps with in the slug mode.

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 the two modes: use claim_token to track a claim through the funnel, use slug to inspect a live listing. There is no explicit when-to-use statement, no guidance on choosing this over get_listing or check_launch_readiness, and no exclusion cases.

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 by structured data. For a pure deterministic calculator the remaining behavioral question is rounding and output precision, which the description does not address; the URL adds no runtime context an agent needs to invoke correctly.

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 tight sentence that front-loads the computed outputs, followed by an optional reference link. The phrasing is slightly elliptical ('Selling price, profit and margin from...') but nothing is 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?

An output schema exists, so return values need not be explained, and the tool is a stateless deterministic calculation with one required parameter. The only material gap is not stating precedence when both price and markup_pct are supplied.

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

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

Schema description coverage is 100%, so the three parameters are already fully documented and the baseline applies. The description restates the same cost/price/markup_pct pairing without adding format details, ranges, or precedence rules (e.g. which wins if both 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 names the exact quantities computed (selling price, profit, margin, markup) and the two input combinations that drive them, which is concrete enough to distinguish it from siblings like calculate_arr or calculate_churn. It is a sentence fragment with no verb, so it reads slightly as a label list, but the 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 two operating modes ('cost and a markup percent' vs 'cost and a selling price') tell an agent which input combination to supply, but that same guidance is already in the schema ('give this or markup_pct'). There is no statement of when to prefer this tool over a sibling or what happens if both price and markup_pct are provided.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's marginal job is to add behavior. It does add one genuinely useful fact: every pick carries a human-written verdict, including negative ones for sites not worth paying for. Beyond that it largely enumerates fields (DR, link type, price) that an output schema already exposes.

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 value proposition and closing with the routing advice; every clause earns its place. The field enumeration in the middle is the only mildly redundant part.

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, zero-required-parameter recommendation tool with a full schema and an output schema, nothing an agent needs to call it correctly is missing: what it returns, how it is ordered, and where to go next are all stated.

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

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

Schema coverage is 100% and the enum values are documented inline, so the schema carries parameter meaning. The description adds the ordering/grouping behavior ('launch day first, evergreen after') but nothing about how free_only or product_type change the result set. 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: curated 'launch directories for a product type', plus the organizing principle (grouped by when to submit). It explicitly separates itself from find_launch_directories, so an agent can pick between the two without reading either schema.

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

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

'Start here; use find_launch_directories to go wider across all 1,667 sites' gives both the default choice and the named alternative with the condition that selects it. No when-to-use inference is required.

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

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

Annotations already establish this as a read-only, idempotent, closed-world calculator. The description adds useful behavioral context: the exact Rule of 40 formula and the fact that extra metrics appear only when their supporting inputs are supplied. It does not contradict 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 description is front-loaded with the formula, then the additional metrics, and ends with a reference link. Every sentence earns its place with no fluff.

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 annotations covering safety semantics, an output schema covering return values, and 100% schema description coverage, the description is largely complete. The main gap is not explaining which optional input combinations unlock each additional metric, though the schema compensates for that.

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 every parameter, including which optional fields feed which metric. The description reinforces the required inputs and names the optional metrics, but it does not add detailed parameter-to-output mapping beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states the exact metric computed (Rule of 40 = revenue growth % + profit margin %) and names the additional optional SaaS metrics it can return. This is specific enough to distinguish it from sibling calculators such as calculate_arr or calculate_churn.

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 implicitly indicates usage through the metric name and the conditional 'when their inputs are given' phrasing, but it gives no explicit when-to-use guidance, prerequisites, or contrast with sibling calculation tools. 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 readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the search criteria and return fields, but does not disclose additional behavioral details such as pagination behavior or any operational limits. This is adequate but not rich beyond 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 description is compact and front-loaded with the core action, followed by return value hints and a use case. It is not bloated, though the enumeration of returned fields is somewhat redundant given the output schema exists. Still, each sentence contributes meaningfully.

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 search tool with full parameter documentation, an output schema, and safety annotations, the description supplies enough context to understand what the tool does and when it is useful. It does not explicitly address all sibling overlaps, but that is not necessary for basic 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 the schema fully documents all five parameters, including enums, defaults, and constraints. The description's mention of 'keyword and/or category' maps to query and category, but adds little beyond what the schema already provides. The baseline of 3 applies.

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

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

The description clearly identifies a specific verb ('Search'), a resource ('products listed on SaaSCity'), and the main filter dimensions ('keyword and/or category'). It is understandable on its own, but it does not explicitly differentiate itself from sibling tools like get_listing or find_alternatives, 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 description gives a concrete use case: market research ('what else exists in this space?') before a launch. That provides clear contextual guidance, though it does not state when not to use this tool or name an alternative, so it lacks explicit 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?

Goes well beyond the annotations by disclosing that nothing is submitted, published, or charged until the human submits the form, that every listing gets human review, that submission is free, and which domains are refused. These are exactly the side-effect and eligibility facts an agent needs before invoking a mutating tool, and they do not contradict the non-destructive, non-idempotent annotation set.

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

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

The core behavior and the claim-URL handoff are front-loaded in the first two sentences, and the following sentences each add a distinct, decision-relevant fact (no side effects until form submit, human review, free, domain exclusions). No filler or restatement of the name.

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

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

For an 8-parameter mutation tool with an output schema and full annotation coverage, the description supplies the remaining critical context: the asynchronous human handoff, the fact that the call itself is a no-op, review latency implications, cost, and eligibility refusals. Return values are covered by the output schema, so nothing essential 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 every property has a description with lengths and the category enum, so the schema already does the heavy lifting. The description adds no parameter-level detail — the mention of picking a launch Monday is a human step, not an input field — so the baseline 3 applies.

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

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

States a specific verb and resource (list a product on the SaaSCity launch directory) and immediately clarifies the mechanism: it creates an inert draft and returns a claim URL rather than publishing anything. This cleanly separates it from siblings like get_submission_status, get_listing, and check_launch_readiness, which read rather than initiate a submission.

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?

Describes the usage flow in detail — the agent creates the draft, then a human opens the claim URL, fills the prefilled form, picks a launch Monday, and submits — which makes the human-in-the-loop boundary unmistakable. It also states preconditions (no free subdomain hosts, no domains with an existing listing) but never names an alternative sibling tool or says explicitly when not to call this one.

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 openWorldHint=false, so the safety profile is covered. The description adds that results are in seconds and covers multiple time periods, which is useful behavioral context, but it does not discuss rate limits, auth, or response format beyond the output schema's coverage.

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 sentences, front-loaded with the core result and dimensions, and includes a reference link without wasted words. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained. The description is complete enough for a simple read-only calculator by stating the output units and time periods, though it could briefly note the expected input range.

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 availability_pct is fully documented in the schema. The description adds only an example value (99.9%) and does not provide additional semantics beyond what the schema already supplies, 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 calculation: allowed downtime for a given availability target, broken down by day, week, month, quarter, and year. It is clear what the tool does, although it does not explicitly differentiate itself from sibling calculator tools like calculate_arr or calculate_churn.

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 versus alternatives, nor does it mention prerequisites or exclusions. Usage is only implied by the phrase 'Allowed downtime ... for an availability target'.

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