list_appsList all Appskyline apps the authenticated user has access to. Returns a Markdown table of id, name, default locale, and the per-store ids (iOS App Store, Google Play, Microsoft Store) when set.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| apps | Yes | ||
| status | Yes | ||
| truncated | Yes |
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.
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.