Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Idea Harvest

idea_harvest
Read-onlyIdempotent

Sweep top-grossing and top-free App Store charts across categories and storefronts to find proven and rising app ideas, open niches, and new entrants.

Instructions

Sweep top-grossing and top-free charts across every App Store category and storefront to find proven and rising ideas.

Use when: Phase 0 idea generation (about 1.5 minutes for the default sweep). Not for: evaluating one idea (use idea_evaluate) or a single chart (use aso_top_grossing). Failed feeds are listed, never read as no apps. Returns: {ok, chart_proven, rising_newcomers, clusters: [{genre, open_niche}], failed_feeds} (untrusted_content).

Input Schema

NameRequiredDescriptionDefault
feedsNoChart feeds to use, e.g. ['topgrossing', 'topfree']; omit for both.
limitNoChart entries fetched per genre and storefront (default 100).
genresNoCategory names to sweep, e.g. ['health', 'productivity']; omit for all 24 charted categories.
countriesNoList of two-letter storefront codes, e.g. ['us', 'gb', 'de']; omit for the default set.
max_resultsNoMaximum entries per result list (default 50).
exclude_termsNoName/seller substrings to drop from results (e.g. your own apps).
newcomer_monthsNoApps released within this many months count as rising newcomers (default 12).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.5
    • addedInput schema / properties / countries / description
      Added value: +"List of two-letter storefront codes, e.g. ['us', 'gb', 'de']; omit for the default set."
    • addedInput schema / properties / exclude_terms / description
      Added value: +"Name/seller substrings to drop from results (e.g. your own apps)."
    • addedInput schema / properties / feeds / description
      Added value: +"Chart feeds to use, e.g. ['topgrossing', 'topfree']; omit for both."
    • addedInput schema / properties / genres / description
      Added value: +"Category names to sweep, e.g. ['health', 'productivity']; omit for all 24 charted categories."
    • addedInput schema / properties / limit / description
      Added value: +"Chart entries fetched per genre and storefront (default 100)."
    • addedInput schema / properties / max_results / description
      Added value: +"Maximum entries per result list (default 50)."
    • addedInput schema / properties / newcomer_months / description
      Added value: +"Apps released within this many months count as rising newcomers (default 12)."
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower; the description still adds runtime cost (~1.5 min for the default sweep), the failure semantics ('failed feeds are listed, never read as no apps'), and flags output as untrusted_content. Only gap is no mention of rate limits or coverage bounds on the open-world sweep.

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

Conciseness5/5

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

Four tightly packed lines, front-loaded with purpose, then when/not-for, then failure semantics and return shape. Every sentence carries distinct information.

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

Completeness5/5

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

An output schema exists, yet the description still enumerates the return keys and flags untrusted_content, and it discloses the failure-mode behavior an agent needs before trusting empty results. Nothing required to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema; the description's 'every App Store category and storefront' only loosely gestures at the genres/countries filters. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb (sweep) and resource (top-grossing and top-free charts) plus explicit scope (every App Store category and storefront), and names the sibling tools it must not be confused with (idea_evaluate, aso_top_grossing). An agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Explicit 'Use when' pins it to Phase 0 idea generation, and 'Not for' names the two alternatives with the condition that selects each. Nothing is left to inference.

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

Deploy Server

Other Tools