appskyline

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description explicitly explains the non-idempotent behavior: calling with the same term twice creates two keyword rows. It also states that the 'tracked set' is modified. This gives the agent useful behavioral context that goes beyond simply labeling the operation as destructive or non-idempotent.

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 extremely efficient: two sentences, no redundancy, and the core action and critical caveat are front-loaded. Every sentence adds meaning, with the non-idempotence warning coming right after the action.

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 description is complete for an agent to understand safety and correctness implications: it warns about duplication, confirms mutation, and references the tracked set. The presence of a full schema with 100% parameter coverage and an output schema avoids the need to describe return formats or optional parameters. Minor missing context is that 'explicit confirmation' is not sourced, but that is more of an external workflow step.

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. The description adds only light semantic detail about 'the same term' behavior, which reiterates the searchTerms concept. There is no need for additional parameter explanation, placing it at baseline.

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

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

The description uses a specific verb-resource pair ('Add a new tracked keyword to an Appskyline app') and clearly differentiates itself from siblings like delete_keyword and list_keywords through the action 'add' and the object 'tracked keyword'. It is immediately obvious what the tool does and how it differs from related tools.

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 'after explicit confirmation' provides a necessary operational condition, and the context of adding a tracked keyword implies when it should be used. However, it does not explicitly mention when not to use it or name alternatives such as list_keywords or update_keyword-like operations, leaving some 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 provide destructiveHint and idempotentHint, but the description adds materially more: it declares the deletion is permanent, it translates idempotency into a concrete no-op behavior for already-deleted ids, and it explicitly scopes the impact — no regard to what is destroyed (future snapshots) and what is preserved (historical search rows). This is rich, decision-relevant context far beyond the structured fields. No contradiction with annotations exists.

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

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

Three sentences, each earning its place: the first states the core action and key input, the second resolves the idempotency expectation, and the third clarifies side-effect boundaries. The critical permanence and no-op behavior are front-loaded near the beginning, and there is zero redundant or filler wording.

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

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

For a simple single-parameter tool with an existing output schema and annotations covering the destructive/idempotent profile, the description supplies everything an agent needs to call it and predict the outcome: permanence, idempotency, and the exact effect on current vs historical data. No material information 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%, with the id parameter clearly documented as 'Keyword id to delete,' so the schema already carries the full parameter burden. The description's phrase 'by id' reinforces the parameter but does not add new semantic meaning, such as id format, provenance, or how to look up a keyword id via sibling list tools.

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 ('delete'), a specific resource ('tracked Appskyline keyword'), and the identifying mechanism ('by id'), making the operation unambiguous. It is immediately distinguishable from sibling tools like add_keyword, list_keywords, and get_keyword_overview because it is the only purely destructive keyword operation in the set.

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 conveys clear usage context by explaining the practical consequence of the operation: it stops collecting ranking snapshots while preserving historical search rows. This tells the agent precisely what effect to expect when tracking needs to be removed. It does not explicitly state when-not-to-use or name alternatives, but no true alternative delete tool exists among the siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by disclosing the return format (Markdown) and the fields included (name, locales, per-store ids, creation/edit times), which is useful and not contradictory to 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?

One sentence with no filler, front-loaded with the core action first, then concise return details. Every word contributes value.

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

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

This is a simple get-by-id tool with comprehensive annotations, full parameter documentation, and an output schema present. The description covers the purpose, scope, and return representation, so an agent has enough to invoke this tool correctly.

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

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

The input schema already describes the single parameter (appId) with 'App id (uuid)', and schema coverage is 100%. The description's 'by id' wording reinforces but does not add new semantic information beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Fetch'), a precise resource ('a single Appskyline app'), and the lookup key ('by id'). It clearly distinguishes from sibling tools that list, summarize, or analyze apps, so an agent can identify what this tool does without ambiguity.

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

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

The description makes the use case clear: retrieve one app's metadata by app ID. It does not explicitly exclude alternatives like list_apps or show_app_overview, but the singular-by-id framing provides sufficient context for when to choose this tool.

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, and non-destructive behavior. The description adds a useful behavioral nuance: 'Metric names differ per store because each store reports its own set.' This goes beyond the schema and helps set expectations. No contradiction with the annotations.

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

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

The description is compact and front-loaded, with two sentences that earn their place. However, the phrase 'aggregate days' is slightly awkward and potentially redundant alongside 'the most recent daily rows', which keeps it from being perfect.

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 rich annotations and the presence of an output schema, the description supplies sufficient actionable context for a safe read-only call. It also adds the store-specific metric caveat. Explicit sibling differentiation would make it fully complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description loosely reinforces the 'date window' concept and the one-app/one-store scope, but it does not add meaning beyond the schema's parameter descriptions.

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 action and resource: it 'Summarize downloads, installs, uninstalls, crashes and other engagement totals' for one Appskyline app over a date window. It also describes the typical output: aggregate values, recent daily rows, and top territories. It does not explicitly name sibling alternatives, so it stops short of a 5.

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

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

The description gives clear context: one app, one store, a date window, and store-reported engagement metrics. It does not explicitly list when not to use this tool or point to alternatives, but the scenario is clearly scoped.

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 signal read-only, idempotent, and non-destructive behavior. The description adds value by specifying that the response is a Markdown table of date, rank, and total results scanned, and by clarifying that the timeseries is stored as day-by-day snapshots. No contradiction exists.

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

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

The description is two sentences with no filler. It front-loads the core behavior and then gives a concrete, useful statement of the return format. Every sentence earns its place.

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

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

Between the description, annotations, and output schema, an agent has enough information to call this read-only history tool effectively. The main gap is that the description mentions app, term, and country but omits store as a required dimension, which is a minor contextual 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?

The input schema has 100% description coverage, so the baseline is 3. The description restates the app/term/country dimensions but adds little param-specific meaning beyond the schema, and it does not mention the required store parameter in the prose.

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 precise action: retrieving a historical ranking timeseries for an app, term, and country across snapshots. It clearly differentiates itself from a single-point current-rank lookup and names the data source and content of the response.

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 clearly establishes that this is the tool for historical, day-by-day ranking data, which is enough to point an agent toward this tool when a timeseries is needed. It does not explicitly route away from get_keyword_rank or other sibling tools, but the historical framing is a clear context signal.

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 read-only, idempotent, and non-destructive; the description adds valuable behavior beyond these: data comes from a shared cache and that missing/stale terms trigger a billable live upstream call. This is a non-obvious side effect agents need to know before calling.

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

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

Two sentences with no filler. The first sentence states the core function and constraints; the second delivers critical batching/billing guidance. Everything earns its place and is front-loaded.

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

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

With an output schema present and annotations covering safety profile, the description fully covers when and how to invoke the tool. The billing/cache side effect and batch guidance are the only extra context needed, and both are present. Nothing an agent needs to call correctly is missing.

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

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

Schema description coverage is 100%; all three parameters have descriptions. The description reinforces limits (50 terms, one country) and adds behavioral guidance for the terms parameter (batch terms to avoid live lookup charges), which is meaningful value beyond the schema.

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

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

The description states a specific verb ('Look up') and a specific resource (keyword search-volume overview, including monthly search volume, keyword difficulty, CPC, and competition level), with explicit limits (up to 50 terms, one country). This clearly differentiates it from sibling tools like get_keyword_history or list_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?

Offers clear usage context: batch terms rather than calling once per keyword, because missing/stale cache entries trigger a live, billable upstream lookup. It does not explicitly name alternative sibling tools for related lookups, so it falls short of a 5, but the cost and batching guidance is concrete and useful.

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 behavior, so the description does not need to repeat that. It adds meaningful behavioral context by clarifying that the result is limited to the scanned substring of top results and by defining the exact output phrasing, including the 'not in top N' case.

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 tightly written two-sentence passage. It front-loads the core purpose and then gives an exact output format example. There is no fluff or repetition of schema fields.

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 behavior is fully specified for an agent: the lookup scope is clear, the result interpretation is provided, and annotations cover safety. The existing input schema and output schema allow a new agent to call this tool without ambiguity. No extra edge cases seem material enough to require mention.

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 each parameter has a description. The tool description adds value by explaining the output in terms of 'scanned results', but it does not add substantial parameter-level semantics beyond the schema; the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Look up'), a precise resource (current keyword ranking of a specific app), and the exact scope (store and country). It also distinguishes itself from sibling tools like get_keyword_history or get_keyword_overview by calling out 'current' ranking and the output format, so the agent can select it appropriately.

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

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

The description implies when to use the tool — checking a current ranking for a keyword — but it does not explicitly name alternatives or state when not to use it. The sibling list is not referenced in the description, leaving the agent to infer the distinction between current ranking and related get_keyword_overview/get_keyword_history tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read. The description adds useful context beyond those flags by emphasizing 'public store listing' and noting that the description/release notes are truncated. No behavior contradicts 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 description is a single, information-dense sentence with no filler. It front-loads the action and scope, lists the returned fields compactly, and ends with the practical use case. Every part contributes to selecting the correct 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?

Given the rich input schema, explicit annotations, and presence of an output schema, the description completes what is needed: it specifies the intended scope, field set, and use case. The agent can call the tool correctly with just storeId and store, and knows it gets public listing data even for untracked apps. No critical information 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 input schema already describes every parameter in full, including enums, length limits, and examples. The description reinforces that storeId is the store-native identifier, but does not materially add semantics beyond what the schema provides. With 100% schema coverage, the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Fetch the public store listing for any app by its store-native id.' It clearly states what data is returned (title, developer, rating, price, version, release dates, genres, truncated description), and distinguishes itself by covering 'any app' rather than only apps tracked in Appskyline, which sets it apart from sibling tools.

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 clear usage context: use this tool when you need a store listing for any app via its store-native id, including competitor apps. The phrase 'not just apps tracked in Appskyline' implicitly contrasts with app-specific tools, and 'useful for competitor research' signals the intended scenario. However, it does not explicitly name sibling alternatives or state when not to use this tool.

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, so the behavioral baseline is covered. The description adds meaningful context beyond those annotations: it explicitly says Appskyline never downloads from or uploads to the store, clarifying the operation is cache-only. There is no contradiction between the description and annotations.

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

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

The description is compact and front-loaded: the first sentence establishes what the tool reads and which fields it returns; the second sentence reinforces the read-only, no-store-I/O behavior. There is no filler, and every phrase earns its place given the rich annotations and 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 read-only tool with a detailed annotation set and a complete schema, this description is close to fully sufficient. It tells an agent what the operation returns, that it is safe and cached. The only small gap is that it doesn't specify what happens when the optional locale parameter is omitted—whether all locales are returned or the call fails—although this is partially inferable from the schema description.

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

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

All three parameters already have useful schema descriptions, and the store parameter has an enum, so the description does not need to carry much parameter documentation. The description adds context about per-locale data and the Apple 100-character limit, but it adds little to the semantics of appId or store specifically. A baseline of 3 is therefore 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 states the verb ('Read') and the specific resource: store-listing metadata Appskyline has synced for one app. It goes further by enumerating the fields returned, such as per-locale name, subtitle, keywords with Apple's 100-character limit, promo text, release notes, version, and review state. It does not explicitly distinguish itself from the sibling get_store_listing, but the focus on 'synced metadata' and 'read-only' makes the core purpose unmistakable.

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

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

The description implies this tool should be used when you want read access to store-listing metadata Appskyline already synced, not for live store interactions. However, it never names alternatives such as get_store_listing, list_keywords, or search_store_results, nor does it state conditions for when one sibling should be preferred over another. Usage guidance is largely implicit.

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

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

Annotations already indicate this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations by specifying that the output is a Markdown table and exactly what fields are included, plus the access-scope constraint. This is more than the annotations alone provide.

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

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

The description is two well-structured sentences with no wasted words. The core purpose is front-loaded, and the return format is given in a compact, precise manner.

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 list tool with rich annotations and an output schema, the description is complete. It covers scope, access semantics, return format, and the specific fields returned, leaving no practical gap for an agent to invoke it correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. The input schema already fully documents this with no properties. The baseline of 4 applies here because no additional explanation is needed.

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 action ('List all Appskyline apps'), a clear scope ('the authenticated user has access to'), and the expected output format. It is easily distinguishable from sibling tools like get_app (which retrieves a single app) and list_keywords (which lists 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?

The description clearly conveys when to use this tool: when you need the full set of apps available to the authenticated user. It does not explicitly name alternative tools or exclusion criteria, but the context is clear enough for an agent to choose it over the more specific sibling tools.

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

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

Beyond the annotations that already indicate read-only, idempotent, non-destructive behavior, the description adds useful behavioral detail: review text is truncated, results are ordered by recency, and a preconfigured service account is required. It does not contradict any annotation and provides meaningful extra context for how the tool behaves.

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 three concise sentences with no filler: the first states the action and scope, the second gives the key prerequisite, and the third explains pagination. Every sentence contributes information the agent needs.

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?

Combined with a fully documented schema with 100% parameter coverage and a rich output schema, the description covers the key context: what resource it reads, what fields are included, what is required before calling, and how to paginate. It does not explain default behavior of maxResults or potential error conditions, but those are not essential for this simple read-only listing tool.

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

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

The input schema already documents all parameters with 100% coverage, so the description does not need to repeat them. The mention of pagination with a returned page token aligns naturally with the token parameter, but it adds no new formatting or value beyond the schema. 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 opens with the specific verb 'List' and the resource 'most recent Google Play user reviews', then enumerates the exact returned fields: star rating, review text, app version, device, language, and developer reply status. This level of specificity clearly differentiates it from sibling tools, none of which deal with Play reviews.

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 prerequisites are stated directly: a Google Play service account configured for the app is required, and pagination is explicitly indicated via the returned page token. This gives clear call-pattern guidance, though it does not name alternatives or exclusion cases. Since no sibling tool could perform the same task, the guidance is adequate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying that results come back as a Markdown table and enumerating the columns returned. It does not contradict any annotation.

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

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

The description is two short, direct sentences with no filler or repetition. The main action is front-loaded, and the output-format sentence adds concrete value without bloating the description.

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 operation with a required appId, a pagination schema, and an output schema present, the description is functionally complete. It could be slightly stronger by adding an explicit note that this returns only the current tracked keywords and not historical or aggregated overview data, but that gap is shared with usage guidance.

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

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

The schema covers all three parameters with descriptions (appId, skip, and limit), so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already provides, meaning the schema carries the heavy lifting 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 clearly states the verb 'List' and the resource 'tracked keywords for an Appskyline app', and it specifies the exact output format (Markdown table with id, term, language, country, bid). It does not explicitly differentiate itself from the sibling keyword-related tools like get_keyword_overview or get_keyword_history, but the basic listing purpose is unmistakable.

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

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

The description implies that this tool is for viewing the currently tracked keyword set, and provides no explicit guidance about when to prefer it over sibling tools such as get_keyword_history or get_keyword_overview. It is adequate but does not name alternatives 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 readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable context beyond these: the search is live, results are not saved as a snapshot, and the output is a Markdown table with specific fields. This makes the behavior understandable without contradicting 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 description is two well-structured sentences. The core behavior, scope, major constraint, and return format are all front-loaded with no filler or repetition of schema/annotation details.

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, idempotent search tool with a full input schema and an output schema, the description covers what the tool does, which stores it queries, the live behavior, and the response shape. There are no significant gaps that would prevent correct invocation or result interpretation.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description does not add new semantics for store, term, num, lang, or country beyond what the schema already states, but it does clarify the output format (rank, id, title, score, developer), which gives some context for what parameters influence.

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

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

The description states a specific verb ('Run'), a precise resource ('live ranked search'), the four stores supported, and the key constraint ('without storing a search snapshot'). This clearly distinguishes it from sibling tools like get_keyword_rank or list_apps, so an agent can tell what it does without inspecting the schema.

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

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

The description gives useful context: it is a live, ranked, non-persisting search across four named stores. The phrase 'without storing a search snapshot' implicitly tells agents not to use this for historical keyword-rank lookups, but it does not explicitly name alternatives or state when-not-to-use 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 signal readOnly=true, idempotent=true, and destructive=false, so the description only needs to add value beyond those. It adds meaningful behavioral context: the app must be known, output is interactive overview, and keyword display is capped at 50. No contradiction with 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?

Two sentences, no filler, and the operational context is placed first: what app is rendered, when to invoke the tool, and what the output contains. Every sentence contributes.

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

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

The tool has a single fully-documented parameter, strong annotations, and an output schema. The description adds the key contextual facts not present in structured data (known app requirement, interactive rendering, 50-keyword cap), so nothing essential is missing for correct invocation.

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

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

Schema coverage of appId is 100%, so the schema already documents the parameter. The description meaningfully adds that appId should come from a prior listing step or from a user-supplied known app id, which helps the agent understand where the value comes from. This goes beyond a bare restatement of the schema.

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

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

The description clearly states the action ('Render an interactive overview'), the target resource ('a known Appskyline app'), and the actual content shown ('store identities and up to 50 tracked keywords'). This distinguishes it from sibling tools like get_app, get_store_metadata, and get_keyword_overview, which are narrower or more detailed.

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 explicitly says to use this tool after listing apps or when the user provides an Appskyline app id. This gives a clear activation context. It does not explicitly list when not to use it, but the stated conditions are sufficiently discriminating for an agent.

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