delete_keywordPermanently delete a tracked Appskyline keyword by id. Idempotent — deleting an already-deleted keyword is a no-op. This stops collecting new ranking snapshots; historical search rows in the *-searches collections are not affected.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Keyword id to delete |
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| keywordId | Yes |
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.
Add one secure layer between your agents and this server.
Most tools map to clearly distinct resources and actions, such as listing apps, getting keyword history, fetching store listings, and searching store results. A couple of adjacent getters, particularly show_app_overview vs get_app and get_store_metadata vs get_store_listing, could be confused, but their descriptions are strong enough to keep an agent on the right path.
Tool names follow a uniform verb_noun pattern throughout: add_, delete_, get_, list_, search_, show_. Resources such as app, keyword, store, and overview are consistently placed after the verb, making the set predictable and easy to reason about.
Fourteen tools serve the ASO and store-insight domain well without feeling bloated. The count covers app discovery, keyword tracking, store metadata, engagement summaries, live store search, and reviews, so each tool earns a place.
The core workflows are well covered: list apps, get app details, track and delete keywords, check current rank and historical rank, look up search volume and difficulty, read store listings, and pull Google Play reviews. Obvious gaps are an update-keyword operation and App Store review listing, but most primary use cases do not hit dead ends.