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 cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: it enumerates returned fields (within/over, estimatedSimplifiedDutyJPY, channel, cashDeclarationRequired, warnings, assumptions, rulesAsOf), states the rules' effective date, and explicitly frames the result as an educational estimate subject to the officer's decision.

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?

Purpose is front-loaded, but the body is a single sprawling block that crams rules, rates, output fields, and caveats together without structure. Given the domain's complexity much of it earns its place, but the density hurts scanability.

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 21-parameter tool with no output schema, the description compensates by describing the return shape and the rules' scope, so an agent knows what inputs matter and what comes back. Nothing essential 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%, so the baseline is 3. The description goes further by supplying the rate schedule that gives the alcoholType/hnbType enums meaning (¥800/L whisky, ¥15/stick cigarettes, 15% other goods) and notes precedence ('Allowance goes to the highest-rate drink first'), which aids correct parameter use.

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

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

States a specific verb+resource+scope ('Japan Customs per-person duty-free allowance when entering Japan') and clearly occupies a distinct niche from siblings like japan_luggage_check, japan_tax_free_refund_check, and japan_visa_fee_check. An agent can identify it without opening the schema.

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

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

Gives a clear usage trigger ('call this instead of guessing') and warns that many guides show stale pre-2021 tobacco limits, implying when this tool is the right choice. It doesn't name an alternative sibling or state exclusions explicitly, so it falls short of 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?

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds material context on top: the data snapshot date (2026-10-16), the sources (Japan Tourism Agency case list and official facility pages), the residence-not-nationality rule, the full return field set, and a not-advice 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?

It front-loads the core concept (residence-based, not nationality-based) and the snapshot date before the facility enumerations. The per-facility price lists and status buckets are long but double as the inventory of accepted place ids, so they earn most of their space; the title restating the question is mildly redundant.

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

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

With 8 all-optional parameters and no output schema, the description compensates by enumerating the returned fields (headline, yourTier, yourPriceJPY, totals, warnings, sources) and the filtering modes. An agent has everything needed to build a correct call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real interpretation beyond the schema — notably that tier assignment hinges on registered residence (city/prefecture/Japan) rather than nationality and that foreign residents with a Japanese address pay resident prices. That materially changes how an agent should populate city, prefecture and residence.

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 subject (Japanese resident vs non-resident dual pricing) plus the exact mechanism and scope (which facilities are live, announced, under review, dropped). It is clearly distinguishable from siblings like japan_tax_free_refund_check or japan_customs_allowance_check, which cover different traveller-money topics.

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?

'Omit places to list all (filter with status / area)' and 'Training data likely predates these prices; call this instead of guessing' give clear context for when and how to reach for the tool. It stops short of naming alternative sibling tools or drawing explicit boundaries against them, so it is clear but not exhaustive.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real context beyond them: it is rule-based with no live fetch, its knowledge cutoff is stated, and the response shape (verdict, urgency enum, doNow/dont, modifiers, sources) is spelled out. The 'always relay official instructions' caveat is a useful behavioral disclosure.

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?

Purpose is front-loaded in the first clause, but the body is one enormous sentence enumerating every alert type, level name, colour and renamed category. Much of that inventory is genuinely useful coverage, yet the density hurts scannability and the return-value list could be tightened.

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 full burden and does so: it enumerates the input forms accepted, the rule sources and cutoff, the full response structure, and the urgency taxonomy. An agent has everything needed to call it and interpret the result.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including the lang enum and the alert-id source URL. The description reinforces that text may be Japanese or English and that an alert id can substitute, but adds no new semantics and never mentions the 'situation' parameter. 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 ('Decode the text of a Japanese emergency alert ... or an alert id') and immediately scopes the rule sources (JMA / Cabinet Office / J-ALERT / MoE as of 2026-10-17). No sibling tool overlaps, and the title plus first sentence make the domain unmistakable.

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

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

Gives a clear trigger ('Give text or alert') and an explicit exclusion via 'No live data: it explains the alert the user already has', plus 'call this instead of guessing' when training data predates the 2026 renaming. It never names a concrete alternative tool, so it stops short of the 5 bar, but the when/when-not boundary is unambiguous.

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 read-only/idempotent/non-destructive, and the description goes well beyond them: it discloses that this is an unofficial estimate unaffiliated with Japan Post, that size limits, customs and prohibited items are NOT checked, that country acceptance can be suspended, that SAL is suspended entirely, and that the 2027 surcharge on zones 3/4 goes to ¥0 — all caveats an agent could not infer from structured fields.

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

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

Front-loaded with the core purpose and price-cutover date, which is good, but it is a dense wall of parenthetical detail and sample fares (US 500 g ¥3,900 → ¥7,400; 2 kg ¥7,900 → ¥10,300) that partially duplicates what the tool's own return values will supply. Much earns its place, but the mass of numeric examples is heavier than selection requires.

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 fully by explaining the return shape (current and revised price, weight band, yen and % change, price on shipDate, tracked/available/suspended flags, cheapest options, band shift, discount, notes, sources, disclaimer). For a 7-param, multi-service quoting tool this is complete enough to call 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 is 3, but the description meaningfully enriches it: it enumerates what each zone contains (1 China/Korea/Taiwan … 5 Central & South America/Africa), clarifies that shipDate selects the price table, and explains the items-based 2027 same-time discount (10% at 10–49, 13% at 50+).

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 (quote/check postage) and resource (Japan Post international mail prices) with explicit temporal scope: as-of-2026-10-19 rates plus the 2027-02-01 revision. The sibling list contains many japan_* checks (customs, visa, tax-free, luggage), and this one is unambiguously the postage tool.

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

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

Gives a clear trigger: call this instead of guessing when the query is about mailing cost, and notes training data predates the 2026-10-09 announcement. It also explains the shipDate cutover (up to 2027-01-31 current, from 2027-02-01 revised). It doesn't explicitly name an alternative sibling to use for non-postage questions, so it stops short of 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is lighter. It adds real context: the data revision date (2025-10-01), that it is an estimate rather than an official quote, and the specific return contents. It omits any rate-limit or failure-mode notes, keeping it from a 5.

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

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

It is long but densely front-loaded: the core verdict and price purpose lead, the detailed rules and revision date follow, and no sentence is filler. The heavy parenthetical nesting slightly hurts scannability, so not a 5.

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

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

There is no output schema, so the description carries the full burden of describing returns, and it does — verdict, Yamato size class, prices, send-by date, recommendation, official sources. For a 12-param, optional-heavy calculator, nothing an agent needs to invoke or interpret it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by supplying domain meaning the schema lacks: the 161–250 cm reservation band with its ¥1,000 unreserved fee, the 250 cm / 30 kg prohibition, the ¥100 drop-off discount, and that Yamato bills on the larger of size or weight class.

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 (a bag's outside size/weight → Shinkansen oversized-baggage rule + Yamato TA-Q-BIN price) and states the exact scope it covers (which lines, which size bands). An agent can distinguish it immediately from siblings like japan_customs_allowance_check or japan_tax_free_refund_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?

It gives clear triggering context — 'call this instead of guessing' and a warning that many sites and Yamato's own English page show stale prices — which tells the agent when this tool beats its own knowledge. It does not explicitly name a sibling alternative or a when-not-to-use condition, so it stops short of 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?

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, and the description adds substantial behavior beyond them: the exact return shape (objective_issue / need_more_info / no_objective_blocker, never an approval prediction), the disclaimer that ISA does not publish income thresholds, that permission is discretionary, and the ¥200,000 fee. This is rich disclosure for a read-only advisory 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?

It is front-loaded with the decision-relevant fact (filing date picks the version), but the bulk is a single dense run-on paragraph enumerating rule changes, return fields, and fee without sub-structure. Information-rich yet hard to parse; length is defensible for the complexity but structure is weak.

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 19-parameter tool with no output schema, the description carries the full burden and does: it explains the returned summary/band/guideline/earliestDate/filingWindow/checks/absences, the rules-as-of dating, and the educational-not-legal disclaimer. An agent has enough to call it and interpret the result.

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

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

Schema description coverage is 100%, so the schema already documents all 19 parameters, making the baseline 3. The description adds genuine domain meaning on top — how workYears/trips/japaneseB1/periodOfStay feed the 5+3 rule, the income-only partial revision, and which statuses stop counting — which raises it above baseline.

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

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

The description states a specific verb+resource: it resolves which 永住 guideline version applies to a filing date and computes the time requirement, with earliestDate. It is clearly distinct from the Japan-flavored siblings (visa fee, customs, luggage, TB screening), none of which touch PR guidelines, though it does not name a sibling to route against.

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

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

It gives a direct usage directive — 'Training data likely predates the 2026-10-01 revision; call this instead of guessing' — and scopes itself as an 'Educational guide, not legal advice.' It supplies clear context for when to invoke but offers no explicit when-not-to-use or alternative-tool 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 readOnly, idempotent, non-destructive, closed-world behavior. The description adds meaningful context beyond them: rules are deterministic and dated, and the output is explicitly 'not tax advice'. It does not describe return format or error behavior, but with this annotation coverage the added domain caveats are the right contribution.

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 tool's core computation, then a compact caveat sentence. Dense but every clause (threshold, caps, deadline, regime, anti-hallucination warning) earns its place 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?

Covers the full decision surface an agent needs — eligibility, refund cap, deadline, and old-vs-new regime selection — for a read-only tool with no output schema, so return-format detail is not required.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning: the ¥5,000 tax-exclusive per-store/day eligibility threshold, the 10%/8% refund caps, and the per-store/day grouping that governs the receipts array — content not fully present in the schema.

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

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

States a specific verb+resource with precise scope: computing Japan tourist tax-free refund eligibility under the 2026-11-01 regime, listing per store/day eligibility, refund caps, 90-day deadline, and regime selection. An agent can distinguish it immediately from japan_customs_allowance_check and japan_dual_pricing_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?

Gives clear context for use and an explicit directive ('call this instead of guessing', because training data describes the obsolete old system). It also frames regime selection by purchase date, though it does not explicitly name sibling tools or exclusion conditions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description usefully supplements them by enumerating what is returned – verdict, reasons, timeline, X-ray window and validity, documents, filterable Panel Clinic list, notes, sources, rulesAsOf – which matters since there is no output schema. It also warns that training data may predate the Indonesia start date. It stops short of describing pagination or error behavior.

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?

It is front-loaded with the governing rule and as-of date, and nearly every clause carries regulatory information. But it is a single dense wall of text with no segmentation, and the lengthy exemption catalogue plus repeated date lists are harder to scan than a structured layout would be for a 10-parameter tool.

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

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

With no output schema, the description carries the return contract and does so thoroughly: effective dates, exemption categories, timeline, document requirements, Panel Clinic filtering, sources, and a clear 'educational guide, not legal or medical advice' caveat. Nothing an agent needs to call and interpret this checker 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 already 100%, so the baseline is 3, but the prose adds interpretive rules the schema does not spell out: the 180-day X-ray validity (90 after close contact), that validity is checked only at COE filing, that a COE filed before the mandatory date needs nothing at the visa stage, and the residence-outside-target-country exemption logic. These clarify how xrayDate, applicationDate, closeContact and residenceCountry should be read.

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 opening sentence names the exact regime (JPETS) and states the decision it answers – whether a TB Clearance Certificate is needed for a COE or visa – and later explicitly names the return contract ('Returns verdict (required / not_yet_required / exempt / not_required)'). An agent can separate this from siblings like japan_visa_fee_check or japan_customs_allowance_check without opening a schema.

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

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

The description exhaustively defines the domain of applicability (target nationalities, stay length, visa categories, exemptions) which implicitly tells the agent when the check is relevant, and adds the useful 'call this instead of guessing' note about stale training data. However, it never explicitly routes against alternative tools or states when NOT to invoke it; applicability is inferred from the policy content rather than given as usage 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, 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 readOnly/idempotent/destructive=false, so safety is covered; the description goes further by labeling itself a 'deterministic, dated table', disclosing the pre-2026-09-30 exception (¥6,000/¥5,500/¥10,000), and disclaiming that it is 'not legal advice'. It stops short of describing date-boundary edge cases or how multi-year projections 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?

Front-loaded with the core fee table and the date rule before the supporting detail, with no filler sentences. The dense parenthetical price list and the 'Returns ...' clause read as a run-on block, but nearly every token conveys a distinct fact.

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 itself, enumerating fee, online processing fee, headcount total, revenue-stamp combination, per-year/multi-year cost, online saving, and ISA sources. Combined with the date-exception rule and staleness warning, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by tying fee amounts directly to the granted-period parameter (1 year vs. 5 years), explaining the online surcharge tied to the method enum, and noting the old-fee cutoff that governs applicationDate — the schema only states these mechanically.

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 with scope: residence permit / visa renewal and status-change fee lookup for applications from 2026-10-01, with concrete figures (¥33,000 counter, ¥27,000 + ¥330 online, ¥200,000 PR). An agent can immediately distinguish it from the other japan_* siblings (customs, luggage, tax-free, TB screening), none of which price immigration fees.

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

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

Explicitly routes the agent here: 'call this instead of guessing' and warns that training data still says ¥4,000/¥6,000, which is exactly the failure mode this tool prevents. It also bounds applicability to application dates, but never states when-not to use it or which sibling to prefer for adjacent questions (e.g. trip planning vs. fee lookup).

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them by disclosing the exact return payload (discount, price to pay, cap, effective %, eligibility verdict with reasons, next sales opening, site and call center, rulesAsOf, sources) and a critical caveat that results are estimates and budgets can run out. That is rich behavior the annotations cannot carry.

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 discount itself, then eligibility rules, then outputs — logical ordering with no filler sentences. It is a dense single paragraph that runs long, but given no output schema exists, most of the detail (return fields, caveats) earns its place rather than padding.

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

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

With no output schema, the description must carry return semantics — and it does, enumerating the exact verdict values (eligible / not_eligible / not_yet_open / sold_out / unchecked), accompanying reasons, and provenance fields. Date/channel eligibility rules and the estimation caveat round out everything an agent needs 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 adds cross-parameter meaning the schema does not: how nights/product determine the ¥20,000/¥30,000/¥35,000 caps, how the cap applies per person per trip, and that bookings before sales start are never discounted. That interaction context lifts it above the baseline.

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

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

States a specific verb (check/compute savings + eligibility) on a specific resource (Kyushu Fukko Ouenwari 2026 travel discount), naming the exact prefectures, caps and discount percentages. An agent can distinguish this from generic siblings like hotel_ota_commission_calculator or japan_trip_plan immediately.

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 lines give clear context — 'Newer than most training data — call this instead of guessing' — which tells the agent to prefer this over inference. However it never states when-not to use it or names an alternative sibling, so it sits at clear-context-without-exclusions 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.

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 the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, yet the description still adds meaningful behavior: it discloses that scoring is a deterministic, transparent rubric rather than an AI opinion, lists the exact rubric dimensions, and specifies the returned artifacts including an OG-image share URL. No auth or rate-limit caveats are given, but none appear relevant for a pure-compute roast.

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-loads the input instruction, then the output contract, then the rubric, then the disclaimer, so an agent can stop reading early if it only needs the input format. The second sentence is dense with comma-separated output items but every clause carries distinct information; nothing is redundant padding.

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

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

There is no output schema, so the description must carry the return-value burden, and it does: judges, scores, roast lines, verdict options, the one change, issues/strengths, and share URL are all enumerated. Combined with full schema coverage and the annotation safety profile, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and all three parameters (pitch, stage, category) are documented at the schema level, including the stage difficulty ramp and the crypto/blockchain softening. The description's rubric list references terms like 'blockchain' and 'X for Y' but adds no parameter-level format or syntax detail beyond the schema, so the baseline 3 is appropriate.

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

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

Names a specific verb and resource ('roast a startup pitch') and enumerates the exact deliverable: five named judges, 1-10 scores, roast lines, a verdict from a fixed set, the single highest-leverage change, and a share URL. It is readily distinguishable from siblings like score_business_idea_moat or ai_bottleneck_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?

The description tells the agent what to paste ('one to five sentences') and scopes expectations with 'For fun and practice, not investment advice', which is an implicit when-to-use signal. However, it never names an alternative sibling (e.g. score_business_idea_moat) or states when this tool should not be chosen over those, so usage guidance remains implied 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 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.