ASOClimb

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

Annotations already declare this is a non-read-only, non-idempotent, open-world write. The description adds real side-effect disclosure beyond that: adding an app triggers discovery and auto-tracks keywords and competitors when auto_track is on. It stops short of describing duplicate/re-add behavior, which matters given idempotentHint=false.

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

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

Two short sentences, front-loaded with the core action and followed by the side effect. The second sentence is slightly compressed ('Discovery then auto-tracks...'), but no sentence 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?

There is no output schema, and the description does not say what is returned (app record, id, discovery results) or what happens when the app is already tracked. For a six-parameter mutation with non-idempotent semantics, these are meaningful gaps, though the rich schema and annotations cover most of the rest.

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

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

Schema description coverage is 100%, with enums and defaults documented for store, platform, language and auto_track. The description only restates bundle_id/package name and the auto_track effect, adding little beyond the schema, so the baseline 3 applies.

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

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

States a concrete verb and resource ('Track an app by bundle id... or package name'), and clarifies the identifier differs by store. It is distinguishable from siblings like add_competitor and list_applications, 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?

Usage is only implied: an agent can infer this is the entry point for registering a new app before keywords/competitors can be tracked. There is no explicit 'use this when...' guidance, no mention of checking list_applications first, and no note about prerequisites such as GOOGLE_PLAY_SOURCE beyond what the schema says.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it doesn't say what happens on a duplicate bundle id (non-idempotent), whether metadata collection starts immediately, or whether quota is consumed by the open-world lookup.

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 zero waste. It is arguably too terse rather than padded, so brevity here is not a structure defect.

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

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

For a simple two-parameter mutation with full annotations and no output schema, the essentials are present. Missing is the post-call behavior an agent would want — duplicate handling and whether a competitor fetch is triggered — which keeps it at minimum-viable rather than 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% with only two required parameters, both documented (application id, competitor bundle id or package name), so the schema carries the semantics. The description adds no extra meaning such as accepted bundle id formats or platform prefixes beyond what the property descriptions state.

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 (track) and resource (a competitor app), scoped to one of your applications, and the mutation nature matches the tool name. It does not distinguish itself from siblings like list_competitors or remove_competitor, so an agent must infer the inverse relationship.

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

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

There is no guidance on when to use this versus list_competitors or remove_competitor, no prerequisite that the application must already exist, and no note on limits or duplicate handling. The agent only knows the generic case where it wants to track something.

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

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

Annotations already declare readOnly/openWorld/idempotent, and the description adds real context on top: it performs a live fetch ('reads ... now') against the store, evaluates supplied extras, and persists nothing. It does not cover latency, rate limits, or failure modes for an external store fetch, which keeps it below 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?

A single tightly-packed sentence front-loads the scope ('Check any App Store or Google Play listing, tracked or not') before the mechanics, and 'Stores nothing' lands as a useful closer. The colon clause is dense with three stacked ideas, but nothing is truly wasted.

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

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

For a 10-parameter tool with no output schema, the description never says what the 'metadata checks' actually return (which checks, what findings or fields). The store/field mapping is covered well, but an agent cannot anticipate the result shape at all.

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 90%, so the baseline is 3, but the description adds genuine meaning: it explains *why* subtitle and keywords must be supplied (only the public title/description are read) and which values are yours to provide. It still doesn't clarify how `candidates` differ from `keywords` 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?

Specific verb+resource: 'Check any App Store or Google Play listing' plus what it acts on (public title/description and supplied subtitle, keywords, terms) and that it runs metadata checks. It implicitly separates itself from stored-metadata siblings via 'tracked or not' and 'Stores nothing', but never names get_metadata / simulate_metadata / compare_metadata_draft, so the differentiator is inferred rather than stated.

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?

'tracked or not' explicitly widens the use case beyond apps already in the account, and 'any subtitle, keyword field or terms you supply' tells the agent when to pass optional fields. It gives clear context but no exclusions or named alternatives, so an agent must still guess why it would pick this over simulate_metadata.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive comparison. The description adds useful behavioral context: it compares field by field against the live listing and re-simulates against current rank observations, which clarifies that results reflect current data rather than a static snapshot.

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

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

The description is a single, front-loaded sentence with no filler. Every clause contributes to explaining the comparison basis.

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

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

Given the simple one-parameter schema, read-only annotations, and absence of an output schema, the description provides sufficient context for correct invocation. A note about the return format would improve completeness, but the core comparison behavior is clear.

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 is one required parameter, draft_id, and schema description coverage is 100%. The schema itself explains that it comes from list_metadata_drafts, so the description appropriately leaves parameter details 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 gives a specific verb-resource pair: comparing one saved draft field by field against the live listing. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling simulate_metadata 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?

Usage is implied by the phrase 'One saved draft compared...' but the description does not state when to choose this over simulate_metadata or list_metadata_drafts. It gives enough context to infer the use case without explicit 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 flag readOnlyHint=false and openWorldHint=true, but the description adds the concrete side effect that matters: track=true creates tracking entries for candidates and up to five competitors within the plan. That is real value beyond the boolean flags. It stops short of covering re-run/idempotency behaviour (idempotentHint=false), which would matter for a mutation-capable 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 dense sentences, zero filler, with the core action and the output composition front-loaded ahead of the conditional track behaviour. Every clause carries information.

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

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

With no output schema, the description usefully enumerates what discovery returns and explains the mutation side path, which is most of what an agent needs. Remaining gaps — quota consumption, duplicate-tracking on repeat runs, and how this differs from the sibling gap/opportunity tools — are moderate rather than fatal.

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

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

Schema description coverage is 100%, so all three parameters are already documented in structured form. The description restates the track flag's meaning and adds the competitor cap, but says nothing about max_keywords or application_id beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb and resource — 'Run keyword discovery for an application' — and enumerates what discovery yields (title seeds, store suggestions, outranking app titles), so the agent knows the output shape. It does not distinguish itself from near-neighbours like expand_keyword_gap, get_keyword_gap or track_keyword_opportunities, so sibling differentiation is left implicit.

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

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

The description gives usable in-tool guidance on the track flag: false means preview, true means commit tracking. But it never states when to choose this tool over the many related siblings (track_keywords, list_keyword_opportunities, get_keyword_gap), so the routing decision is inferred rather than explained.

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 it is non-read-only, open-world, non-idempotent, and non-destructive. The description adds important context beyond that: it spends one autocomplete request per prefix and one keyword inspection per inspected term from monthly allowances, and returns the refreshed gap. It doesn't detail side effects on stored data, but the quota-cost disclosure is valuable.

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

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

Two tightly packed sentences, front-loaded with the action and mechanism. Every sentence earns its place by explaining process and quota impact without waste.

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

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

For a three-parameter tool with full schema coverage and no output schema, the description gives a complete picture of how it works and what it returns ('refreshed gap'). It could be slightly richer about what the refreshed gap contains, 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%, so defaults and limits are already documented. The description reinforces the prefix-default behavior ('words from the competitor's title') and ties inspected terms to cost, but adds no syntax or format details 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?

Names a specific action (widen a competitor's keyword gap) and describes the exact mechanism: store autocomplete plus keyword inspection. An agent can distinguish this from siblings like get_keyword_gap (read-only view) or run_autocomplete (single lookup) 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?

States the tool's context clearly: expanding a competitor's gap using title words or provided prefixes. However, it does not explicitly say when not to use it or name alternatives like get_keyword_gap for simply viewing the current gap.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds useful scoping context — results are monthly (month-to-date) and tied to the key's workspace — but says nothing about return shape or freshness of the numbers. With annotations doing the heavy lifting, a 3 is appropriate.

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

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

A single front-loaded sentence with no filler. It is perhaps too terse given the absence of an output schema, but every word 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?

With no output schema and no parameters, the description carries the burden of conveying what is returned; it names the fields conceptually (plan, limits, usage) but not their structure or units. Adequate to select the tool, thin for interpreting the response.

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

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

Zero parameters, so there is nothing for the description to document; baseline applies. The description correctly implies no inputs are needed by describing only account-level output.

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

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

The description enumerates a specific resource set (plan, limits, month-to-date usage) and scopes it to 'the workspace behind this key', so an agent knows exactly what data comes back. It does not distinguish this from siblings like get_capabilities or get_dashboard, which keeps it from a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent must infer from the name alone that this is the tool for quota/plan checks before attempting other calls.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is clear. The description adds worthwhile context by disclosing that the response bundles tracked keywords, competitors and listing snapshots, which annotations do not cover. It stops short of describing payload size, pagination or error behavior for a missing id.

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 short, front-loaded sentence with no redundant clauses. It is technically a sentence fragment missing a verb, which keeps it from being a model of structure, but every word 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 one-parameter read-only getter with full schema coverage and annotations covering safety, this is nearly sufficient: the description tells the agent what comes back. With no output schema, it could say more about the shape or volume of the returned data, but the core information an agent needs to call it correctly is present.

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 application_id parameter is documented with its source ('from list_applications'). The description adds no further meaning about the parameter, so the baseline of 3 applies when the schema does the work.

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 identifies a specific resource (one application) and enumerates the related payload it returns (tracked keywords, competitors, listing snapshots). 'One application' implicitly distinguishes it from list_applications. However, it is a noun phrase with no explicit verb, so the action is inferred from the name rather than stated.

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 call this tool versus list_applications or get_app_score_history, and no prerequisites or exclusions are mentioned. Usage is only implied by the name and the required application_id parameter.

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 state readOnlyHint=true, idempotentHint=true, closed-world, and non-destructive, so safety is covered. The description adds only the scoping detail 'across all its keywords over a window'; it says nothing about ordering, aggregation, or how the history is presented.

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

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

A single sentence with no filler, and the application-wide scope is stated early. The terseness contributes to ambiguity, but structurally it is efficient.

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 operation is low-complexity and the schema is fully documented, so the essentials are present. However, for a 'history' tool with no output schema, the description should better explain what is returned or how observations are ranked over the window.

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

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

Schema coverage is 100%, with both application_id and days fully documented including the default and max. The description adds little beyond 'over a window' and does not clarify whether days affects ranking scope or history depth.

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 verb ('Rank') and resource ('observations for an application across all its keywords over a window'), but 'Rank observations' is vague and does not clearly convey that this retrieves score history over time. It also fails to distinguish itself from the sibling get_keyword_rank_history, which sounds closely related.

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 alternatives such as get_keyword_rank_history, get_dashboard, or get_application. The window parameter is mentioned only indirectly through 'over a window,' with no conditions or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful scope about the categories of capability returned, but does not describe the return format, pagination, or any auth/caching behavior. With annotations carrying the safety burden, this is an adequate but not rich 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?

The description is a single compact sentence fragment that front-loads the core subject. It is appropriately sized for a simple zero-parameter capability lookup, though it could start with a clearer verb to improve scannability.

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

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

For a zero-parameter, read-only capability endpoint with no output schema, the description supplies the essential content categories an agent would want to know. It stops short of describing the exact return structure, but the annotations and simple shape make the definition sufficiently complete 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?

The tool takes zero parameters, so there are no parameter semantics to document. Baseline 4 applies for a parameterless tool with full schema coverage.

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

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

The description identifies the specific resource — stores and data sources served by this deployment — and names the key subcategories (Google Play status, chart catalogs, autocomplete sources). It lacks an explicit verb like 'List' and does not differentiate itself from sibling tools such as get_dashboard, but the purpose is clear enough to distinguish from most siblings.

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

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

The description states what the tool returns but gives no explicit guidance on when to use it, when not to use it, or which sibling tools are alternatives. An agent must infer that this is a discovery/preflight tool for checking deployment coverage.

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

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

Annotations already disclose that this is not read-only, not idempotent, and not destructive. The description adds useful behavioral context by saying it 'Records today's observation,' clarifying that the call has a write side effect and returns live rank plus stored daily history.

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, no filler. The core result is front-loaded, followed by the recording side effect.

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

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

For a two-parameter tool with no output schema and annotations covering safety hints, the description broadly explains the return (live rank plus stored history). However, it omits collection semantics and does not detail the history format or how repeated calls affect stored observations.

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

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

Schema coverage is only 50%: application_id has a basic description, while collection has only enum values. The description implies an application scope but does not explain the free/paid/grossing collection parameter or its default/effect.

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 resource and scope: an application's position in its own category chart, plus stored daily history. It distinguishes this from generic top-chart tools by emphasizing 'one of your applications,' though it does not name a sibling explicitly.

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

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

It gives no explicit when-to-use guidance or alternatives. A reader can infer this is for checking a tracked app's category rank rather than broader top_charts, but the description does not route between siblings such as top_charts, list_top_chart_categories, or get_app_score_history.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and determinism are covered without the description. The phrase 'from your tracked observations' adds useful context that results are limited to currently tracked competitors rather than arbitrary domains — but nothing about result shape, ordering, or volume.

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 the scope qualification front-loaded and no filler. It is efficient, though the brevity arguably trades away information the agent would benefit from.

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

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

This is a simple one-parameter read with no output schema and full annotation coverage, so the bar is low, but the description does not indicate what a returned keyword record contains or whether results are paginated. Adequate to invoke, thin for interpreting output.

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 is a single required parameter with 100% schema description coverage, so the schema carries the burden and baseline 3 applies. The description adds no detail about where competitor_id comes from (e.g., list_competitors) or what happens with an untracked id.

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 resource (keywords) with a clear scope qualifier (where a competitor ranks, drawn from tracked observations), which distinguishes it from the app-scoped siblings like list_keywords or get_keyword_gap. It stops short of naming an explicit alternative, so it is clear but not maximally 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?

There is no statement of when to use this tool versus get_keyword_gap, expand_keyword_gap, or list_keywords — all of which sit adjacent to competitor keyword analysis. The agent must infer the selection rule from the sibling names alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds real behavioral content beyond that: it enumerates the four report sections the caller receives and explains the edge-case semantics of a null 'change' mover (entered with previous_rank null, exited with current_rank null), which an agent could not derive from annotations or the empty schema.

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

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

Two tight sentences with the payload contents front-loaded and the null-mover caveat second. The caveat sentence is dense and slightly cryptic in phrasing, but every clause carries information an agent would otherwise have to guess.

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 schema to explain and no output schema (so return values are the description's responsibility), the description does the essential job by listing the four dashboard sections and flagging the null-change mover case. It could say more about the scope of 'totals' or the ordering/shape of 'movers', but nothing critical for a correct call 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, so the baseline is 4. The description does not need to document any inputs and correctly spends its words on output contents and interpretation 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?

The description names the resource (workspace dashboard) and enumerates its four contents — totals, movers, alerts, scheduler status — which lets an agent tell this aggregate overview apart from the granular siblings like get_scheduler_health, list_alert_events and get_account_usage. It stops short of explicitly stating that it is the roll-up entry point, but the payload listing is concrete enough to identify the 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?

There is no statement of when to call this versus the overlapping siblings (get_scheduler_health for scheduler status, list_alert_events for alerts, get_account_usage for totals). The overview use case has to be inferred from the enumeration of contents; no exclusions, prerequisites, or alternatives are offered.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-obvious behavioral context: results are limited to this workspace's tracked keywords and its own keyword inspections, which tells the agent the gap is not a global market comparison. It stops short of noting any result caps or pagination.

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, then the returned fields, then the data-source caveat. Dense but every clause carries information; the only mild cost is that the second half packs a lot into one sentence.

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

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

No output schema exists, but the description enumerates the return payload (both ranks, modeled traffic, difficulty, opportunity score, shared and only-you lists), which compensates well. It is nearly complete for a one-param read tool; only result limits/ordering are unstated.

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

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

With a single parameter at 100% schema coverage, the schema already explains competitor_id and its source (list_competitors). The description adds only the constraint that the competitor must be a tracked one, which is mild added meaning beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('Keyword gap against one tracked competitor') and then pins down the exact scope: terms the competitor ranks top-30 for where your app does not. The 'one tracked competitor' framing implicitly separates it from list_keyword_gaps and expand_keyword_gap, so an agent can tell what this returns 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 phrasing 'against one tracked competitor' and 'Terms come only from this workspace's tracked keywords' implies when the tool is appropriate, but no sibling is named and there is no explicit when-not-to-use or alternative routing (e.g., vs list_keyword_gaps or expand_keyword_gap). Usage is inferable 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds that the response includes a 'full breakdown,' which indicates a detailed record, but it does not explain what that breakdown contains or any other behavioral traits.

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

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

The description is a single front-loaded sentence with no redundant wording. Every part of it contributes to identifying the resource and its scope.

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

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

For a simple get-by-id tool with rich annotations, the description is minimally adequate. However, there is no output schema, and 'full breakdown' is vague about what is returned, while the relationship to sibling tools such as inspect_keyword and list_keyword_inspections remains unexplained.

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

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

The single parameter inspection_id is fully documented in the schema as 'Inspection id.' The description does not add any meaning, format guidance, or constraints beyond what the schema already provides, so the baseline score of 3 is appropriate for high schema coverage.

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

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

The description clearly states that this tool fetches one stored keyword inspection with its detailed breakdown. It establishes a specific verb-resource relationship and singular scope, but it does not explicitly distinguish itself from sibling tools like list_keyword_inspections or inspect_keyword.

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 'One stored inspection' implies retrieval by a known identifier, which gives some usage context. However, it does not state when to use this tool rather than list_keyword_inspections or inspect_keyword, nor does it mention any preconditions or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing that observations are sampled daily and which four metrics come back, but it says nothing about history depth, gaps, or null metrics.

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

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

A single tight sentence with the resource front-loaded and zero filler. It is arguably too compressed — unexplained jargon like 'KEI' and no return-shape clause — so brevity costs a little clarity.

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 is the only place return-shape information could live, and it only gives a bare metric list. For a time-series tool an agent needs to know the row granularity, window default, and whether missing days are omitted — only the first is hinted at.

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 both parameters carry descriptions, so the schema does the heavy lifting. The description's 'daily' hints at how the days window translates into rows, but it adds no format or constraint detail beyond that.

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

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

Names a specific resource (rank history) and enumerates the metrics returned — daily rank, traffic, difficulty, KEI — scoped to 'a tracked keyword'. That distinguishes it from list_keywords and inspect_keyword, though it is a noun phrase rather than stating the retrieve verb 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 call this versus sibling lookalikes such as get_keyword_inspection, inspect_keyword, or get_category_rank. The only implicit cue is 'tracked keyword', which hints it applies to already-tracked keywords but never says so or names an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds genuinely useful context beyond that: the data blends live store values with the draft flagged as current, and includes computed checks and keyword coverage. It says nothing about auth requirements, error behavior when the app is untracked, or payload size.

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 a single sentence with no filler, but that sentence is a dense run-on noun phrase with nested parentheses that takes effort to parse. Front-loading the returned resource is good, yet the enumeration order and parenthetical clauses obscure the primary purpose.

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

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

With no output schema, the description must convey the return contents, and it does so item by item (listing, limits, checks, keyword coverage, drafts). The remaining gap is that 'checks on the live copy' is unspecified and there is no indication of result shape or whether missing data is omitted or null.

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?

Only one parameter (application_id) exists and schema description coverage is 100%, so the schema already carries the parameter burden. The description adds no semantics about the id (format, whether it is a store id or internal id, or what happens for an invalid id), 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 enumerates exactly what the tool returns for a tracked application: the live listing, store character limits, live-copy checks, keyword coverage, and saved drafts. That is a clear resource definition, but it is delivered as a noun phrase with no verb and never distinguishes it from near-siblings like check_listing_metadata, compare_metadata_draft, or get_application.

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

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

There is no explicit when-to-use guidance and no mention of alternatives, even though the sibling list contains several overlapping metadata tools (check_listing_metadata, compare_metadata_draft, list_metadata_drafts). The agent must infer that this is the aggregate read for one application from the description's content alone.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real context beyond that: what the payload contains (heartbeat state, tracked vs observed-today coverage, last 24 runs scoped to this workspace) and that coverage is per-workspace and per-day. It stops short of stating freshness/caching or what an unhealthy state looks like, which holds it at 4.

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

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

A single front-loaded sentence that names the primary question (is the job running?) before the supporting details (counts, run history). No filler, no repetition of the title or annotations.

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

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

With no output schema, the description must carry the return-shape burden and does so by enumerating heartbeat state, coverage counts, and the last 24 runs. It does not specify timezone/semantics of 'today' or how heartbeat state is encoded, leaving a minor gap for a zero-param read 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?

Zero parameters, so the baseline of 4 applies. The description correctly does not invent parameter behavior and instead spends its words on what the no-arg call returns.

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 noun+scope: whether the hourly observation job is running and how much of this workspace it has covered today, plus heartbeat state and run history. No sibling tool covers scheduler/observation-job health, so it is unambiguously distinct from the keyword/metadata/chart siblings.

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

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

The diagnostic nature of the tool is implied by 'health' and the heartbeat framing, but there is no explicit when-to-use or when-not-to-use guidance. In practice a zero-parameter tool has little room for misuse, which keeps this at minimum-viable rather than low.

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 the quota cost per call and the persistence side effect ('stores the result'), which explains why readOnlyHint=false and idempotentHint=false — repeated calls consume allowance again. It does not mention whether an existing inspection is overwritten or how depletion is signalled, but the cost and write behaviour are the key traits an agent needs.

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

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

A single tight sentence with the outputs front-loaded and the cost/persistence note trailing. Dense but every clause carries information; slightly telegraphic in the parenthetical breakdown, but 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?

For a five-parameter, three-required tool with a fully documented schema and no output schema, the description covers what it returns and its cost/persistence behaviour. The missing piece is the explicit routing versus the stored-inspection siblings, which matters in a 40-tool surface.

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

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

Schema coverage is 100% with descriptions on all five parameters, including store/platform interplay and the GOOGLE_PLAY_SOURCE deployment requirement, so the schema carries the semantics. The description adds only the 'autocomplete demand' breakdown concept and no additional parameter meaning, matching 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?

Names a specific verb and resource ('Live keyword inspection') and enumerates what it returns: top apps, traffic/difficulty/KEI scores with breakdown, related keywords. The 'Live' qualifier implicitly contrasts with the stored/cached siblings get_keyword_inspection and list_keyword_inspections, but those siblings are never named, so an agent must infer the distinction.

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

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

The cost statement ('Spends one keyword inspection from the monthly plan allowance') signals that this is the expensive, fresh-data path and implies get_keyword_inspection is the cheaper read of stored results, but it never states that alternative or a when-not-to-use condition. Usage is implied through cost rather than declared.

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 safety is covered. Beyond that the description adds almost nothing: it doesn't say how far back 'recent' reaches, whether results are paginated or capped, or what an 'alert event' contains, even though there is no output schema to fill that gap.

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 a single unpunctuated noun phrase, so there is zero waste, but it is under-specified rather than concise. A few more words about the time window and return shape would have cost little and earned their 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?

With no output schema, a four-word description must carry the burden of explaining return values, and it doesn't say what a rank alert event is, how many are returned, or over what period. For a tool whose entire value is the shape of its output, this is a meaningful gap.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies; the only caveat is the implied non-parameterized 'recent' window, which is a behavioral rather than a parameter concern.

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 fragment 'Recent rank alert events' names a specific resource (rank alert events) and implies a listing, so an agent can guess this returns a feed of rank-change notifications. But it omits a verb and any notion of scope or window, and it does nothing to distinguish itself from the many other list_* siblings such as list_keywords or list_competitors.

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 call this versus any sibling, no prerequisites, and no statement of what the agent should do instead for related data. The word 'recent' hints at a default time window but never defines it, so usage 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 readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral content is "latest listing facts," which hints at the returned payload but doesn't specify freshness, volume, or whether untracked apps are excluded – modest added value against an already-complete 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?

A single front-loaded sentence with no filler. The scope qualifier ("tracked in this workspace") and the payload hint arrive before any wasted clause.

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

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

For a zero-parameter, read-only list tool with complete annotations, this is close to sufficient. The one gap is that no output schema exists, so "latest listing facts" is the only cue about what comes back – a slightly more concrete return description would close 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Nothing in the description misleads about inputs.

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

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

States a specific verb and resource ("List the applications") scoped to "this workspace," which separates it from get_application (single record) and add_application (mutation) in the sibling list. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the verb 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?

Usage is only implied by the verb "List" – an agent can reasonably infer this is the enumeration entry point, but the description never says when to prefer it over get_application, list_competitors, or the other list_* tools. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description contributes nothing beyond that — no scope, no retention window, no ordering, no pagination. No contradiction with the annotations, but no added value either.

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

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

Four words is not conciseness but under-specification — there is no front-loaded verb or scope statement for the agent to act on. Nothing is wasted, but almost nothing is said.

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

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

For a zero-param read-only list tool the annotations cover safety, but with no output schema the description should at least indicate what the history contains and roughly what comes back. It says nothing about return shape or scope, leaving the agent to guess.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 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 fragment "Stored autocomplete observations" names a resource but has no verb and essentially restates the title "List autocomplete history." An agent cannot tell from this alone whether it retrieves past autocomplete runs, caches, or suggestions, nor how it differs from the sibling run_autocomplete.

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 whatsoever on when to use this versus run_autocomplete or any other sibling. No prerequisites, no exclusions, no context of any kind.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is fully covered. The description adds the scope behavior (application vs workspace) but does not elaborate on return format, pagination, or ordering. Given the rich annotation coverage, a 3 is appropriate.

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

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

The description is a single well-formed sentence with zero waste, and it front-loads the resource and scope. Nothing is repeated unnecessarily and the size is appropriate for a simple one-parameter read tool.

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

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

For a simple read-only list tool with one optional parameter, full schema coverage, and comprehensive annotations, the description is nearly complete. Its only gap is not describing the returned competitor fields or ordering, but without an output schema this is a minor 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 coverage is 100% and the single parameter is documented as 'Filter by application id.' The description adds meaningful default semantics by indicating that without an application ID the result covers the whole workspace. This is a small but genuine addition beyond the schema, meriting a 4 rather than 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?

The description clearly identifies the resource (competitors tracked) and the two scopes (a specific application or the whole workspace), which lets an agent distinguish it from write siblings like add_competitor and remove_competitor. It does not explicitly name competing read alternatives such as get_competitor_keywords, so it falls short of full sibling differentiation.

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

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

The parenthetical '(or the whole workspace)' implies that omitting application_id returns workspace-wide competitors, which is useful usage context. However, the description gives no explicit when-to-use guidance, no exclusions, and no named alternatives for related reads.

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

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

The annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation, so safety behavior is covered. The description adds useful scope and return-content context by saying it covers every tracked competitor and returns five best gap terms per competitor, but it does not explain ordering, pagination, or how gap terms are determined.

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

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

The description is a single, front-loaded sentence with no filler. It communicates scope and return content efficiently without repeating the tool name or title unnecessarily.

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

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

For a simple one-parameter listing tool with no output schema, the description is largely complete: it identifies which competitors are covered and what each result contains. It could be stronger by clarifying how many competitors may appear or how the five best gap terms are selected, but it is sufficient for an agent to understand the tool's purpose.

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 is one required parameter, application_id, and schema description coverage is 100%, so the schema already carries the parameter documentation burden. The description only implies that the tool operates on an application and adds no extra semantics about the identifier format or constraints.

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 resource and scope: a keyword-gap summary for every tracked competitor of an application, including each competitor's five best gap terms. It is more specific than the title alone and distinguishes this overview tool from narrower siblings like get_keyword_gap, though it does not explicitly name those alternatives.

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

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

Usage is implied by the phrase 'summary for every tracked competitor,' which suggests an overview/browsing use case. However, the description does not explicitly say when to use this tool instead of get_keyword_gap, expand_keyword_gap, or get_competitor_keywords, nor does it state any prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the 'stored in the workspace' scoping and 'recent' framing, and leaves unexplained how many results are returned, how 'recent' is bounded, or how results are ordered.

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 a single short sentence with no waste, but it is a noun phrase rather than a complete statement of intent, so brevity comes at the cost of substance rather than being earned conciseness.

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

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

With no parameters, no output schema, and rich annotations, the description is the only place an agent can learn what a 'keyword inspection' is and what the list returns — and it supplies neither. For a discovery/listing tool in a large sibling set, this leaves a real gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is fully self-explanatory. Baseline 4 applies for a parameterless tool.

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 fragment 'Recent stored keyword inspections in the workspace' names the resource and implies a list/read operation, and 'inspections' plural distinguishes it from the sibling get_keyword_inspection. However, it never states a verb ('list') or what an 'inspection' record contains, so the purpose is only implied rather than declared.

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 call this versus the obvious alternative, get_keyword_inspection (single inspection), or inspect_keyword (creates one). The word 'recent' hints at a recency scope but gives no threshold 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 declare readOnly, idempotent, non-destructive, closed-world behavior; the description adds the important non-obvious traits that it reads no store and that status remains pending until a discovery pass. That is real value beyond the structured metadata, though pagination and return-shape behavior are not 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?

Two sentences, front-loaded with the resource and followed by provenance and status. The parenthetical source list is dense but every clause contributes to the workspace-only scope.

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 list tool with rich annotations and full schema coverage, the description supplies the key caveat: no store read and pending status. It does not describe the opportunity fields returned, which is a modest gap because no output schema exists.

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

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

The single application_id parameter is fully documented at 100% schema coverage, so the schema carries parameter meaning. The description's 'for one application' aligns with it but adds 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?

It names the resource (keyword opportunities for one application) and its data provenance, so the agent knows this is a workspace-only read rather than a store query. It does not explicitly name a sibling as the alternative, so it stops short of full sibling differentiation.

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

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

The 'Reads no store' and 'pending until a discovery pass has completed' notes imply when the tool is useful, but the description never states 'use this instead of discover_keywords' or any other explicit alternative or exclusion. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely non-obvious semantics: rank_change is a positive-gain delta, and it is null (not 0) both when there is no previous day and when the keyword entered or left the observed depth — this prevents a real misinterpretation of the returned data.

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

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

Two sentences, front-loaded with the returned field set, then a single dense but purposeful clarification of rank_change. No filler, though the parenthetical explanation of rank_change is compact enough to require a careful read.

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 naming the returned fields, and annotations cover the safety profile. However, it says nothing about pagination, ordering, default scope when no filters are supplied, or result size limits — real gaps for a zero-required-parameter list 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% — store, country and application_id are all documented in the schema, including the GOOGLE_PLAY_SOURCE prerequisite. The description contributes nothing about parameters, 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 clearly identifies the resource as tracked keywords and enumerates the returned fields (rank, traffic, difficulty, KEI, favorite flag, movement), which makes the operation unambiguous. It never names a sibling (e.g. get_competitor_keywords, list_keyword_opportunities, inspect_keyword) to differentiate scope, nor states the verb 'list' explicitly, 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 only implied by the word 'tracked', which distinguishes this from discovery/search-oriented siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent can infer the scope but must reason about it rather than being told.

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 a genuine nuance — that coverage and check counts are frozen values stored at save time rather than live computations. It omits ordering, volume, and empty-result behavior for a list operation.

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-loaded with the resource and followed by the returned-content qualifier. No filler, though it is a noun phrase without a leading verb, which slightly weakens the action framing.

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

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

With no output schema, the description carries the burden of explaining return values and does so only partially — coverage and check counts are named, but draft identity fields (name, id, timestamp) that an agent would need to chain into compare_metadata_draft are not mentioned. Adequate for a simple read, but leaves the agent guessing at the record shape.

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

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

Schema coverage is 100% with a single required application_id, so baseline is 3. The phrase 'tracked application' adds a mild semantic constraint (the id must belong to a tracked app), but nothing about format or failure behavior for unknown ids.

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

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

States the resource precisely (saved metadata drafts for a tracked application) and even names the payload content (coverage and check counts at save time). It is distinguishable from save_metadata_draft and compare_metadata_draft by the 'saved drafts' framing, though it never explicitly contrasts itself with those siblings or uses an explicit verb like 'lists'.

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 call this versus compare_metadata_draft, get_metadata, or save_metadata_draft. The need to have an application_id scopes it implicitly to a tracked app, but usage conditions and exclusions are entirely absent.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds a useful behavioral caveat that results include store-specific coverage, but it remains vague about what 'coverage' means and does not describe the return format.

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

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

The description is a single efficient sentence with the core resource and scope front-loaded. The trailing coverage clause is slightly abstract but still earns its place by hinting at result behavior.

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 list tool with no output schema, the description should do more to explain what is returned. It gestures at categories and coverage but does not clarify the output shape or what 'coverage each store can honestly answer' concretely means.

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 `store` parameter is fully documented in the schema, including the Google Play deployment prerequisite. The description adds no parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly identifies the resource as new-release collections and categories scoped to a store, which is more specific than the title alone. However, it does not explicitly distinguish this tool from the closely related `new_releases` or `list_top_chart_categories` siblings.

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

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

The description gives no explicit guidance on when to choose this tool over alternatives such as `new_releases` or `list_top_chart_categories`. The store scope implies a discovery use case, but there are no exclusions or situational cues.

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 value beyond that by disclosing the actual payload shape (topic, storefront, schema version, opportunity score and its range), which matters since no output schema exists. It does not mention ordering, empty-state behavior, or result volume.

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 clause with no filler; every element (resource plus field list) earns its place. It is a noun phrase rather than a sentence, which slightly weakens the framing but costs no words.

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, read-only list tool with no output schema, the description supplies the return-field inventory that would otherwise be missing. Ordering and empty-result behavior are the only meaningful omissions, and neither is critical 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No parameter-related content is needed or expected here.

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 identifies the resource precisely (stored niche analyses) and enumerates the fields each record carries, so an agent knows this is a retrieval of previously computed analyses rather than a new run. It implicitly separates itself from the sibling run_niche_analysis via the word 'Stored', though it never names that sibling explicitly.

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

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

There is no explicit when-to-use statement and no named alternative. An agent must infer from the single word 'Stored' that this lists existing results while run_niche_analysis creates them; that routing decision is left to inference rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as whether this requires a deployment-specific source or what the returned categories represent.

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 short sentence with no wasted words, but it is under-specified rather than effectively concise. It is front-loaded but lacks enough substance to guide selection confidently.

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

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

For a simple read-only tool with one enum parameter and annotations covering safety, the description is adequate but minimal. It does not explain the return values or how the categories relate to top_charts, though the low complexity keeps the gap modest.

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 only parameter has an enum plus a note that Google Play requires GOOGLE_PLAY_SOURCE. The description does not add anything beyond the schema, so the baseline of 3 applies.

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

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

The description identifies the resource as chart collections/categories available for a store, but it does not use a clear action verb and does not distinguish the tool from siblings such as top_charts or list_new_release_categories. An agent can infer it lists categories, but the purpose is only minimally clear.

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 instead of related tools like top_charts, get_category_rank, or list_new_release_categories. The description states what is available but gives no usage context or exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: which fields are returned (observed price, in-app purchase, audience) and, critically, that revenue is neither published nor estimated — preventing false expectations about the payload. It omits pagination/result-cap behavior, which keeps it from a 5.

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

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

Two sentences, zero filler, with the result-scope statement front-loaded and the data-limitation caveat placed second where it belongs. Nothing is repeated 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 six parameters, a fully-described schema and no output schema, the description supplies what structured fields cannot: the returned field set and the revenue-data limitation. It does not mention how to obtain category/collection ids (only the schema points at list_new_release_categories) or any result-size behavior, leaving 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?

Schema description coverage is 100%, so the schema already documents all six parameters, including the days default/max and the store enum caveat. The description's only parameter-adjacent contribution is the vague phrase "recent window," which adds no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

The description names a specific resource and scope: apps released to a storefront within a recent window, plus a distinguishing trait (chart position flags for already-ranking apps). That separates it from top_charts and search_store in spirit, but it never explicitly names those siblings and is phrased as a noun phrase rather than a verb-led statement of what the tool returns.

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

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

Usage is only implied by the scope wording ("recent window", "storefront"); there is no explicit when-to-use, when-not-to-use, or named alternative such as top_charts for established rankings or search_store for targeted lookups. An agent can infer the intent but gets no routing guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds nothing: it does not say whether historical keyword/rank data for the competitor is deleted or merely retained untracked, which is the key behavioral question for a destructive `remove` operation.

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 zero waste. It is efficient, though borderline under-specified rather than genuinely tight.

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

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

For a destructive, non-read-only mutation with no output schema, the definition should state the effect on existing tracked data and any confirmation expectations. It says nothing beyond the name, leaving the agent unable to predict consequences.

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 single parameter is documented as "Competitor id from list_competitors," which even routes the agent to the source of valid IDs. The description adds no further meaning, so the baseline of 3 applies.

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

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

"Stop tracking a competitor" names a specific verb and resource, and reads as the natural inverse of the sibling add_competitor / list_competitors. It does not name those siblings explicitly, but the operation 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?

There is no statement of when to call this instead of add_competitor/list_competitors, no prerequisites, and no caveat about when removal is inappropriate. The agent must infer usage 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?

Adds real context beyond annotations: it discloses the quota cost ('spends one autocomplete request from the monthly plan allowance') and the side effect of persisting the observation, which explains why readOnlyHint=false despite being a lookup. Nothing on error behavior or failure modes, but the cost/persistence disclosure is the key non-obvious trait.

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

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

Two sentences, zero waste, with the core function and result ordering front-loaded and the cost/side-effect note trailing. Nothing repeats the title or schema verbatim.

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

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

For a 4-parameter, fully documented schema with no output schema, the description covers purpose, result ordering, quota cost, and persistence. Only the output shape (what a suggestion record looks like) is unaddressed, which is minor for a simple list-returning tool.

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

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

Schema description coverage is 100%, so all four parameters are already documented including the GOOGLE_PLAY_SOURCE requirement and the country/language examples. The description adds only conceptual framing ('what the shopper has typed so far', result ordering) rather than new per-parameter meaning, so baseline 3 applies.

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

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

States a specific verb+resource (live store search suggestions for a prefix) and names both upstream sources (Apple search hints / Google Play suggest), which pins down the behavior precisely. It implicitly distinguishes itself from list_autocomplete_history by emphasizing 'live' and from search_store by being prefix-based, but doesn't name those siblings explicitly.

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

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

Usage is only implied: the agent can infer this is for live suggestion lookup rather than full app search or stored history, but there is no explicit 'use this when' or exclusion against search_store / list_autocomplete_history. The Google Play source prerequisite sits in the schema rather than 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 flag readOnlyHint=false, openWorldHint=true and non-idempotence, but the description adds genuinely new context: it consumes one niche analysis from the monthly plan allowance and persists the result. That cost/persistence disclosure is exactly the kind of side-effect detail annotations cannot express. It stops short of describing failure behavior when the allowance is exhausted or latency for a live open-world query.

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 with the analytical scope front-loaded and the cost/persistence caveat placed last, where it is read before committing. No filler or restatement of the title.

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

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

With no output schema, the description correctly enumerates what comes back, which is essential for a 7-parameter analytical tool. It is nearly complete; the main omission is how results are returned/stored and where to retrieve them, though 'stores the result' plus the list_niche_analyses sibling covers most of that gap.

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

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

Schema description coverage is 100% with three enums, so the schema already carries parameter meaning and baseline 3 applies. The description touches semantics lightly by referencing 'a threshold' and 'modeled market size (ranges)', but it does not explain how threshold interacts with threshold_metric or how platform is ignored for Google Play beyond what the schema says.

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

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

Opens with a specific verb+resource ('Analyze a niche from a seed keyword') and then enumerates the concrete outputs: related terms, clusters, modeled market size, success rate, concentration, keyword difficulty, and a 0-100 opportunity score. This clearly separates it from list_niche_analyses (retrieval) and from keyword-level siblings like discover_keywords.

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: 'from a seed keyword' and 'stores the result' suggest it is the compute step preceding list_niche_analyses, and the credit cost hints it is a deliberate, non-casual call. But there is no explicit statement of when to prefer it over discover_keywords, expand_keyword_gap, or run_autocomplete, and no prerequisites or exclusions are named.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description usefully adds behavior beyond that: it fills the private fields of the live baseline when is_current is set, and it consumes a metered monthly allowance. It doesn't say what happens on repeated saves or whether an existing draft with the same name is overwritten.

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

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

Two sentences, zero waste, with the core action front-loaded and the quota caveat last. Nothing is repeated from 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 9-parameter mutation with no output schema and full schema coverage, the description supplies the two things the schema can't: the live-baseline side effect and the quota cost. Remaining gaps (overwrite semantics, response content) are minor against complete parameter docs and explicit 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%, so the baseline is 3. The description does add real meaning for is_current ('fills the private fields of the live baseline') beyond the schema's 'copy live in the store today', but says nothing about the other eight parameters or the optionality of name.

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 ('Save listing copy as a named draft for a tracked application') plus an operational nuance (marking the copy live today). It is clearly distinct from read/list siblings like list_metadata_drafts and compare_metadata_draft, though it does not explicitly name an alternative.

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

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

Usage is only implied: the description tells you what saving accomplishes and that it consumes the monthly draft-save allowance, which nudges toward sparing use. It never states when to prefer this over simulate_metadata or compare_metadata_draft, or any prerequisite like having an existing baseline.

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

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

Annotations already cover read-only/idempotent/no-open-world, yet the description still adds real behavioral context: cache-first resolution, a possible single cached store check, a bounded daily allowance, and the guarantee it never consumes a monthly run. It also states execution location and that no AI or store access is needed client-side, which an agent cannot infer from the annotations.

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

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

The core purpose is front-loaded in the first sentence and the cost/execution caveats follow in a logical order with no filler. The dense parenthetical letter codes (A, R, Rt, T, Q, B, L, C, E) are cryptic in isolation and slightly bloat the first sentence, keeping it short of a 5.

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

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

With no output schema, the description does the right thing by naming what comes back (scores plus top apps and store suggestions) and by explaining the cost model for a tool that can trigger a store check. What is missing is any sense of the response shape or how the 0-100 indexes relate to the returned apps, which an agent would need to use results well.

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

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

Schema description coverage is 100%, so all five parameters are already documented; the description's contribution is limited to implying that relevance is scored against an application ('relevance to an application'), which loosely maps to application_id. It adds no format or default guidance beyond what the schema provides, so baseline 3 applies.

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

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

The description uses a specific verb ('Explain') plus a precisely scoped resource ('one keyword's Wow Keywords scores') and enumerates the four score families (popularity, difficulty, relevance, opportunity) with their sub-components, so an agent can distinguish it from report-style siblings like wow_keywords_report. It never names a sibling tool, though, so the differentiation is inferential rather than explicit.

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 'Explain one keyword' (single-keyword drill-down vs. bulk report), and the cost sentence ('answered from the cache when possible... never spends a monthly run') gives an implicit preference rule for cheap lookups. There is no explicit 'use this instead of X' routing against wow_keywords_get, wow_keywords_report, or inspect_keyword, which is the main gap given how many closely related siblings exist.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description still adds real value: it discloses the 12-result cap and that results flag already-tracked apps, which are behavioral traits not in the structured fields.

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

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

A single front-loaded sentence with zero waste; the matching basis leads and the output caveats are packed into a parenthetical.

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 with full schema coverage and annotations carrying the safety profile, the description is nearly complete: it covers scope, result cap, and tracking flag. Minor gap is that it doesn't distinguish from nearby discovery siblings, but nothing essential to 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 coverage is 100%, so all four parameters are already documented, including the GOOGLE_PLAY_SOURCE deployment note on the enum. The description adds only the 'name or keyword' framing for the term, 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 (search) and resource (a store for apps) plus the matching basis (name or keyword). It is clearly a discovery/search tool, distinguishable from mutation siblings like add_application, though it does not explicitly contrast with check_listing_metadata or get_application.

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: search a store to find apps. There is no explicit statement of when to prefer this over get_application or check_listing_metadata, and no prerequisites or exclusions beyond the schema-level note. 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 this is a non-destructive, idempotent, mutating operation, so the safety profile is covered. The description adds the set-style semantics ('mark or unmark' driven by a boolean), implying repeated calls converge, but says nothing about what favoriting does downstream or whether favoriting an unknown id errors.

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

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

A single front-loaded sentence with no filler; the verb pair and resource come first and there is no redundancy with 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 two-parameter boolean toggle whose annotations already carry mutation and idempotency semantics, the description is close to sufficient. The remaining gap is the untracked-keyword precondition and the true/false mapping, which a caller would benefit from having 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 50% and the description only implicitly maps 'mark or unmark' to the favorite boolean; it never states that favorite=true sets and false clears. The keyword_id parameter's meaning is left entirely to the schema's brief 'Tracking id.' label.

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

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

States a specific verb pair (mark/unmark) and resource (tracked keyword's favorite flag), which is distinct from sibling tools like track_keywords or untrack_keyword. Slightly less crisp because it never says what a 'favorite' affects in the UI or whether the keyword must already be tracked, but the action 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?

No statement of when to use this versus alternatives, no prerequisites, and no note that the keyword must already be tracked before favoriting. The word 'tracked' hints at a precondition but the agent must infer 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 readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered. The description still earns credit by adding two genuinely non-obvious traits: 'Coverage is a model, not a rank prediction' (sets expectations on output trust) and 'Stores nothing' (confirms no side effects or persistence). It does not mention rate limits, auth, or what the response shape looks like.

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 verb and resource, and every clause names a distinct check rather than padding. It is a single dense run-on sentence with a long enumeration, which costs some readability, but nothing is redundant with 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?

For a 7-parameter modeling tool with no output schema, the description carries the necessary burden: it enumerates what gets computed, clarifies the covered/uncovered keyword logic and the coverage score, and flags the model-vs-rank caveat. The main remaining gap is that, with no output schema, the actual response shape is only inferable from the check list.

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 already carries limits and semantics (30-char title, 100-char comma-separated keyword field, 4000-char description, up to 50 candidates). The description reinforces the role of candidates ('which tracked or candidate keywords become covered or uncovered') and notes Google Play indexes the description, but adds little syntax or format detail 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?

States a specific verb ('check...and simulate') against a specific resource ('proposed listing copy for a tracked application') and enumerates the exact checks performed (character counters, duplicate words, competitor brands, Google Play density, keyword coverage). An agent knows precisely what this does. It stops short of naming the near-identical siblings check_listing_metadata or compare_metadata_draft, so the boundary between them is not spelled out.

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: 'Check proposed listing copy' plus 'Stores nothing' signals a dry-run/validation use case, which implicitly contrasts with save_metadata_draft. But there is no explicit when-to-use, when-not-to-use, or named alternative — the agent must infer the split with check_listing_metadata and compare_metadata_draft on its own.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds only that rows carry daily movement and new-entry flags. It says nothing about rate limits, freshness of the data, or whether the Google Play source prerequisite causes failure — that constraint lives only in 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?

A single front-loaded sentence with no filler, and the distinguishing qualifiers come first. It is a noun phrase rather than a verb-led statement, which slightly weakens the lead but costs no 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?

With six parameters, no output schema, and an openWorld hint, the description is thin. It never mentions the limit/pagination cap, the language option, or the deployment-level GOOGLE_PLAY_SOURCE requirement that can make a call fail, leaving an agent to discover those from the schema alone.

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

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

Schema coverage is 83%, so the schema already documents every parameter including defaults and the collection enum. The description restates the collection options ('free, paid or grossing') but adds no syntax, format, or edge-case guidance beyond what the schema provides. Baseline 3 applies.

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

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

The description names a specific resource (top chart) and the dimensions that define it — store, country, category, and collection — and states what comes back ('daily movement and new entries'). It is clearly distinct from siblings like list_top_chart_categories or get_category_rank, though it never names those alternatives explicitly.

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

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

Usage is only implied: an agent can infer this is the tool for pulling a ranked chart rather than a single app's rank. There is no explicit when-to-use, when-not-to-use, or pointer to list_top_chart_categories as the prerequisite for the category parameter.

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 non-read-only, non-destructive, non-idempotent, open-world. The description earns credit beyond that by disclosing the 20-term cap and the partial-failure contract: rejected terms surface in `skipped` with a reason rather than being silently dropped. It stops short of saying whether re-tracking is a no-op or consumes plan quota.

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 with zero filler. The limit is front-loaded and the error-handling behavior follows immediately, which is the right priority order for an agent deciding whether to retry or split a call.

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

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

With no output schema, the description carries the return-value burden and does so for the case that matters most — partial rejection. Combined with the cap and the sourced-from hint, an agent has everything needed to call this correctly and interpret a partial result.

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

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

Schema coverage is 100%, so baseline is 3. The description adds genuine value the schema lacks: no maxItems exists in the schema, yet the description states the 20-term limit, which directly affects how an agent batches calls. It adds nothing further about application_id, which is fine given the schema documents it.

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 ('Track') plus a clearly scoped resource ('opportunity terms for an application') with an explicit ceiling of 20. The schema's 'Terms from list_keyword_opportunities' reinforces that this is the opportunity-specific variant, though the description never names the sibling track_keywords, leaving the boundary implicit.

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

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

The usage context is implied through the schema's note that terms should come from list_keyword_opportunities, which gives an agent a reasonable workflow anchor. However, there is no explicit when-to-use vs track_keywords, no statement of prerequisites such as needing an existing application, and no exclusions.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the mutation and openness profile is covered. The description adds two genuinely useful facts beyond that: the 20-keyword per-call cap and that a rank observation is produced immediately. It stays silent on the non-idempotent consequence (what happens if a keyword is already tracked) and on any credit/quota cost, which for an open-world mutation tool is the missing piece.

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 no padding, front-loading the operation, the limit, and the immediate effect. Every clause carries information.

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

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

With no output schema, the description must explain what the caller gets back, and 'immediate rank observation' only gestures at it — format, error/partial behaviour, and duplicate handling are unstated. Adequate for a simple two-parameter call, but thin for an open-world mutating tool that consumes quota.

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 contributes a constraint the schema does not: the keywords array is capped at 20 items. That materially changes how an agent batches calls, which is real added value over 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 (Track) and resource (keywords) scoped to an application, and adds the 20-keyword cap. It does not explicitly contrast with nearby siblings like track_keyword_opportunities or add_competitor, so the discrimination from siblings is left mostly to the name.

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

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

Use is implied — you call this to begin tracking keywords for an app — but there is no explicit when/when-not guidance and no mention of the alternative track_keyword_opportunities or of list_keywords for inspecting what is already tracked. An agent must infer the 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 destructiveHint=true and idempotentHint=true, so the description is not carrying the safety profile alone. It does add real value beyond them by scoping the destruction: history survives unless purge is true. It could go further on reversibility or what happens to the tracking record 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?

Two short sentences, zero waste, with the core action front-loaded and the destructive conditional immediately after. Nothing could be cut 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?

For a two-parameter mutation with no output schema, annotations covering the safety profile, and full schema coverage, this is close to sufficient. The remaining gap is minor: no return/confirmation behavior and no statement of what the untracked record leaves behind.

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's "unless purge is true" restates what the schema's own purge description ("Delete the rank history too.") already conveys, adding no syntax or edge-case detail beyond it.

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?

"Stop tracking a keyword" gives a specific verb (stop tracking) plus the resource (keyword), clearly the inverse of track_keywords in the sibling list. It stops short of naming the inverse sibling explicitly, so it lands at 4 rather than 5.

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

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

The intent is inferable from the name and the sentence, but there is no explicit when-to-use/when-not guidance and no pointer to the counterpart tool (track_keywords) or to list_keywords for obtaining the id. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description goes well beyond them: it discloses that nothing is published to the App Store or Google Play, that ranks from the run become the baseline for weekly reports, and that the call consumes the monthly draft-save allowance. Quota consumption and the baseline side effect are exactly the kind of non-obvious behavior an agent cannot 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?

Three short sentences, each earning its place: what it does, what it does not do, and what it costs. The core action is front-loaded and the safety caveat follows immediately.

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

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

For a non-idempotent mutation with no output schema, the description covers the write scope, the non-publication guarantee, the quota cost, and the rank-baseline side effect. It does not say what identifier or object the draft returns on success, which is the one remaining gap for a tool whose callers will likely need the draft id for follow-up.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including 'variant_id from wow_keywords_get'. The description reinforces the variant/run relationship but adds no format, constraint, or default details beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: save one variant of a finished Wow Keywords run as a metadata draft of the tracked application, plus the side effect of recording baseline ranks. This is clearly distinguishable from run/report/get siblings and from the generic save_metadata_draft, since it is scoped to a Wow Keywords run variant.

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?

'One variant of a finished Wow Keywords run' establishes the precondition (the run must be complete, and the unit of work is a single variant, not the whole run). It does not explicitly contrast with the sibling save_metadata_draft or state when a caller should prefer one over the other, which keeps it 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 cover readOnly/idempotent/non-destructive, yet the description still adds real value: 'spends nothing' discloses the credit/cost profile, and the note that popularity, difficulty, relevance and opportunity are modeled 0-100 indexes rather than store-reported search volume prevents serious misinterpretation of the returned numbers. It does not disclose behavior when run_id refers to an unfinished or unknown run.

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 but well-ordered paragraph: what is returned first, the metric-meaning caveat second, the safety/cost note last. Every clause carries information; 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?

There is no output schema, so the description must sketch the return shape, and it does so concretely (per-country candidates, score breakdowns, top apps, listing variants with counters/checks/coverage). Only the lifecycle gap — how to get a valid run_id and what happens for an incomplete run — 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?

With a single parameter at 100% schema coverage, the schema already explains run_id. The description only adds the constraint that the run must be finished, which is a modest semantic contribution beyond the schema's 'Run id.'

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 scope: the full result of a *finished* Wow Keywords run, broken down by country into scored candidates and listing variants. The word 'finished' implicitly separates it from wow_keywords_status, but no sibling is named explicitly, so the agent must infer the routing itself.

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?

'Finished run' implies the precondition, and 'Read-only; spends nothing' signals it is safe to poll, but the description never says to check wow_keywords_status first or what to do if the run is still in progress. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context beyond annotations: 'newest first' ordering, the exact report sections returned, and that the tool 'spends nothing,' which is cost information not captured in the annotations. It does not cover edge cases like missing reports or authentication requirements.

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 core purpose and scope, then lists report contents efficiently. Every clause earns its place, and there is no redundant or vague text.

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

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

With no output schema, the description does well to enumerate the report's contents and ordering. It also clarifies cost and read-only behavior. Minor gaps remain around what happens when no baseline or applied draft exists, but the description is nearly complete for a single-parameter report retrieval tool.

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

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

Schema coverage is 100% and the single parameter application_id is fully documented in the schema. The description mentions 'for an application,' which aligns with the parameter but adds no syntax, format, or semantic detail beyond what the schema already 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 names a specific resource ('Weekly Wow Keywords reports for an application') and enumerates what the report contains: rank changes, new top-10 terms, dropped terms, and modeled coverage. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings like wow_keywords_get, wow_keywords_status, or wow_keywords_run.

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 'reports' and 'newest first,' suggesting retrieval of historical weekly report data. However, the description never states when to choose this over wow_keywords_get, wow_keywords_status, or wow_keywords_run, nor does it mention prerequisites such as having an applied draft.

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?

With annotations only covering the generic safety profile (not readOnly, not destructive, not idempotent), the description carries real behavioral weight: it discloses that the call consumes a metered run from the monthly allowance, that repeated calls are therefore expensive (consistent with idempotentHint=false), that AI variants hit a separate AI allowance, that the result is a run id rather than data, and that execution happens server-side with no local AI or store access. That is exactly the kind of consequence-level detail annotations cannot express.

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?

Everything is front-loaded: what it does, what it costs, what it returns, and how to continue. The long first sentence is dense with distinct facts rather than padding, and each following sentence adds a separate operational fact (cost, return value, execution model) with no repetition.

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 mutating, metered, asynchronous job with no output schema, the description supplies everything needed to call and continue correctly: the run id return value, the polling target, the allowance cost, and the fact that no local AI or store credentials are required. Nothing material is left for the agent to infer.

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

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

Schema coverage is 100%, so storefronts, use_ai, store, bundle_id and application_id are all already documented, and the description largely restates them (per-country candidates, AI variants when use_ai is true). It does add one clarifying point — that rule-based variants are written regardless of use_ai — but offers no syntax, defaults or format guidance beyond the schema, so the baseline of 3 fits.

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

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

The description opens with a specific verb and resource ('Start an ASOClimb Wow Keywords run for an app') and then spells out the actual work: candidate keyword discovery per country, scoring, and rule-based plus optional AI listing variants. This clearly separates it from the sibling readers (wow_keywords_get, wow_keywords_status, wow_keywords_report) and the applier (wow_keywords_apply_draft).

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 operating context — this is the kickoff of an asynchronous job, and the agent should 'poll wow_keywords_status' afterward — plus the cost condition (one run from the monthly allowance) that governs when it's worth calling. It does not, however, say when to prefer it over the other keyword-discovery siblings such as discover_keywords or expand_keyword_gap, so there's no explicit exclusion.

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

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

Annotations already cover read-only and idempotency, but the description adds the run lifecycle states (queued, running, done, partial, failed) and the useful cost fact 'spends nothing', which is not in any structured field.

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, front-loaded with the core action, followed by the result distinction and the no-run_id fallback. Nothing is wasted.

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

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

For a one-parameter read-only status tool with a documented schema and no output schema, the description gives enough to call correctly: what it returns conceptually, the state values, and the fallback behavior. Exact response fields are not described, but that is a minor gap.

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

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

Schema coverage is already 100% and documents run_id's origin, so baseline is 3. The description earns a bump by explaining the meaningful optionality: omitting run_id returns recent runs, which the schema cannot 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 verb and resource (status/progress of a Wow Keywords run) and explicitly scopes it apart from sibling tools by noting it omits the full result, which distinguishes it from wow_keywords_get and wow_keywords_report.

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 explains the call pattern: pass run_id for one run's progress, omit it to get the workspace's recent runs. It implies the alternative (fetch the full result elsewhere) without naming that sibling explicitly.

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